HP-UX System Administrator's Guide: Overview HP-UX 11i v3 (B3921-90011, September 2010)

• If your server uses virtual partitions (vPars), the dump might not be compressed but the
dump process will proceed.
• If more than one crash occurs in close succession, it might not be possible for HP-UX to
compress the dump.
Compressed Save versus Noncompressed Save
System dumps can be very large, so large that your ability to store them in your HP-UX file
system area can be taxed.
The boot time utility called savecrash can be configured (by editing the file /etc/
rc.config.d/savecrash) to compress or not compress the data as it copies the memory image
from the dump devices to the HP-UX file system area during the reboot process. This has system
recovery time implications in that compressing the data can take longer if the saving occurs as
foreground processing (for example, when HP-UX is trying to quickly evacuate a dump device
that is also used for paging). So, if you have the disk space and require that your system be back
up and running as quickly as possible, configure savecrash to not compress the data.
Using a Device for Both Paging and Dumping (System Recovery Time)
It is possible to use a specific device for both paging (swap space) and as a dump device. However,
if system recovery time is critical to you do not configure the primary paging device as a dump
device. From the savecrash(1M) manpage:
• “By default, when the primary paging device is not used as one of the dump devices or after
the crash image on the primary paging device has been saved, savecrash runs in the
background. This reduces system boot-up time by allowing the system to be run with only
the primary paging device.”
Another advantage to keeping your paging and dump devices separate is that paging will not
overwrite information stored on a dump device, no matter how long the system has been up or
how much activity has taken place. Therefore, you can prevent savecrash processing at boot
time (by editing the file /etc/rc.config.d/savecrash). This can save you a lot of time at
boot time by allowing you to save the memory image after the server has been returned to service.
After the server is up and running you can run savecrash manually to copy the memory image
from the dump area to the HP-UX file system area.
Partial Saves
If a memory dump resides partially on dedicated dump devices and partially on devices that
are also used for paging, you can choose to save (to the HP-UX file system) only those pages that
are endangered by paging activity. Pages residing on the dedicated dump devices can remain
there. If you know how to analyze memory dumps, it is even possible to analyze them directly
from the dedicated dump devices using a debugger that supports this feature.
Before sending your memory dump to someone else for analysis you must move the dumped
pages from the dedicated dump devices to the HP-UX file system. You can then use a utility
such as pax or tar to bundle them up for shipment.
Crash Information Integrity
Use this section if your most important criterion is to make sure you capture the part of memory
that contains the instruction or piece of data that caused crash. The factors you have to consider
here are:
• Full Dump versus Selective Dump
• Dump Definitions Built into the Kernel
• Using a Device for Both Paging and Dumping (Crash Integrity)
82 Major Components of HP-UX