swap and dump

[Alan Shearer_1]

Hi All,

With 11.23 if I have a system that has:

- lvol2 set as swap and dump when system is built
- some new swap volumes added in different vg with priority of 0

If the system crashes, performs a dump, on reboot it starts writing it out to crash. Now given my priority is 0 for the additional swap I added, is this sufficient to negate the risk of my dump getting overwritten before it is transferred to crash?

Also, will there be any delay imposed on the system returning to operational status because my dump area is still a swap area, albeit a lower priority?

Any guidance much appreciated.

[Torsten.]

Only one area is used for dump, see

# lvlnboot -v

[Alan Shearer_1]

Hi Torsten,

I'm only using one area for dump; your response seems to miss the point of my question completely - unless I'm missing something you're saying?

[Patrick Wallek]

Yes, there will still be a delay, if CRASHCONF_ENABLED is set to 1 in /etc/rc.config.d/crashconf.

I that case, the crash dump will be copied from the dump area to /var/adm/crash on system boot.

Now, if you are comfortable that you have enough swap area and that you crash dump will not get overwritten, the you can set CRASHCONF_ENABLED to 0. This will then allow your system to boot faster, BUT you must remember to manually copy the crash dump from the DUMP area when the system is up and running again with the 'savecrash' command.

[Alan Shearer_1]

Patrick,

This was the kind of answer I was looking for.

What I want to do is use lvol2 for swap and dump. So from what I understand setting the priority of my new swap devices, will move any swapping activity away from the local disk to the SAN, whilst not risking any dumps being written over before they are copied. On the proviso that when re-booted the system doesn't eat all it's SAN swap and the lvol2 swap before the dump is copied, which should be v unlikely.

Considering this further - would the dump data be overwritten when significant processes have started that the swap area has been reserved or is it only overwritten when vhand/swapper actually deactivates processes and moves data to the swap areas?

I missed the parameter to stop dump being written to crash on boot when I was reading and thinking on this subject.

So I think what I'm considering should be ok.

[Patrick Wallek]

As long as the swap is just being RESERVED for use, but not actually used (ie. you are not actually paging out) then you should be OK.

For more details on the crash configuration, if you have already read this, have a look at the 'crashconf' man page.

[Paul McCleary · Accepted solution]

Hi Alan,

You can have multiple devices for dump if you require, they can be specified in fstab and activated with crashconf -a.

Memory is now split into classes to enable selective dumps; I think I've only had to change this on the odd occasion from the default.

You can use crashconf -v to estimate what dump sizing you might need - obviously check this whilst your apps are up and busy. I think 25% of RAM is normally a good sizing. Though I've seen 12GB dumps on 192GB systems, so see what yours is.

I have gone with the setup you're proposing, we also had some additional dump volumes in our additional swap vg. The priority setting worked well for swap allocation. I left it set to copy the dump before system finishes booting, so I can't comment on that side of things.

Hope this helps,
Paul

[VK2COT]

Hello,

Here is the method we recommend (applicable if you have access to extra disks or LUNs)!

a) Set primary swap to be 4 GB only. Nothing more and nothing less. Make sure that
primary swap (on internal disk) is mirrored
(RAID-1).

Primary swap SHOULD not be used for dump!

Allocate the dump space elsehwere (ideally,
the size of RAM or, at least 75% of RAM).
Dump space should not be mirrored.

Of course, dump spaces can also be spread across multiple disks.

b) Add aditional swaps into LUNs on SAN
(or extra internal disks if you are lucky
to have them).

That way, the swap space is perfecly interleaved across different disks.

c) Disable CRASHCONF_ENABLED (set to 0 in /etc/rc.config.d/crashconf).

Also, enable parallel dumps and compression.

In that case, after the crash, you do not need to wait for the crash dump to be copied
from the dump area to /var/adm/crash on system boot. You can do it later on. Your first priority is to return the server to users!

Once the server is up and given back to
users, you can run the crashdump export manually.

Why this is good:

a) If you use old engineering rule that
primary swap should be 1x or 2x RAM (which is
really an obsolete rule), then purchasing
additional RAM breaks the "rule" and it
is not easy to resize primary swap
without downtime (Ignite recovery).

b) If you use multiple swaps of 4 GB each,
you achieve excellent performance if swap
is every used.

c) Likewise, if you add more RAM and want to
extend swap, you simply add other 4 GB areas
on different LUNs or disks (never have multiple swap areas on same physical disk).

d) In case of crash, you do not need to wait for dump to be exported into /var/adm/crash
(or wherever you set it up).

You can do it later on. Hence, much faster
system recovery after a crash.

This becomes very important issue especially if you deal with servers that have large amount of RAM.

Cheers,

VK2COT

[Alan Shearer_1]

Hi VK2COT,

Thankyou very much for your response.

Your approach does seem logical, is easily extendable and obviously works well for you. However, you make no mention of swap priorities and don't really seem to give consideration to which disks/SAN LUNs swap volumes reside on.

As I stated, I'm using 11.23 so parallel dump is not available to me - unless anyone knows otherwise?

With selective dumps I'm not sure 75% of memory is a good sizing, especially for systems with >100GB of memory.

Thanks Again,

Alan.

[VK2COT]

Hello,

I forgot to mention:

All those 4 GB swap volumes have the SAME
priority. That way, they are used as in a
striped fashion (each chunk taken from
different LUN). Consider it to be like
a striped logical volume...

The LUNs are typically selected from disk groups that are NOT used by server applications and because they come from the
same SAN they typically have similar
performance characteristics (generally much faster than internal disks).

HP-UX 11.23 does not support parallel dumps
but does support compression:

# COMPRESS: Whether you want the kernel
# and crash image files to be compressed.
# Compression option can be:
# 0 - don't compress
# 1 - compress
# 2 - don't care (default)
# If defaulted, savecrash will choose based
# on the physical memory size and available # disk space. Compressing will take longer
# for savecrash to complete.
# COMPRESS=2

As I said, having dump space match RAM size
is best. If not possible, at least 75% of it
with compression would do quite well.

The worst thing that I see so much around is large single swap space on boot disks.
When and if swap starts being used,
the I/O performance goes terribly wrong.

Or even worse, I saw several production sites
having two or more swap spaces with same priority on boot disks!?

The magic in life is not to plan for good days, but for bad ones.

Any design of swap/dump will work fine if
there are no crashes and RAM problems.
The problems occur when swap really starts being used (for whatever reason).

The saying goes "a friend in need is a friend indeed" :)

Cheers,

VK2COT

[Alan Shearer_1]

Closed