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

Likewise, if at the time of a crash you know what caused it (and therefore do not need the system
dump) but have previously defined a full or selective dump an operator at the system console
at the time of a crash can override those definitions and request that no dump be performed.
Concurrent Dumps
On servers with very large amounts of memory, the process of writing memory contents to disk
can take a very long time. If you have multiple devices configured to receive the memory dump
you can configure HP-UX to split the task of dumping memory and write to the multiple devices
in parallel. This process is called dump concurrency and is configured using either the kernel
tunable dump_concurrent_on (see dump_concurrent_on(5)), or the crash-processing configuration
command crashconf (see crashconf(1M)).
NOTE: Concurrent dump performance improvements are not likely to occur on systems with
only one instance of any of the crash dump resources (for example, only one dump device or
only one core). And, concurrent dump performance improvements are currently supported only
on HP Integrity servers.
Compressed Dumps
Following a system crash, the HP-UX operating system can use this feature to compress data
from memory before it writes the data to the dump device. Compression decreases the volume of
crash data, making the dump times faster.
By reducing the time required to store the entire dump the recovery period is shorter and your
system can be returned to service much sooner. Dump compression provides a greater time
saving on systems that have large amounts of memory.
Dump compression is not forced, it is only a user request that will be honored if possible.
At the time of a system crash the dump subsystem examines the state of the system and its
resources to determine whether it is possible to use compression. Depending on the resources
available, HP-UX determines dynamically whether to dump using compressed or
uncompressed format.
(For example if the processor that is processing the crash fails to assign a sufficient number
of processors to do the compression, the dump will not be compressed. A recursive crash,
such as a panic during the processing of a previous dump, also causes the system to dump
using uncompressed format.)
For selective dumps that exclude unused pages, you can expect the dump to take about
one-third the time of uncompressed dumps on the same server. This interval includes the
time required to run the savecrash program and write the dump to its final storage location
on the HP-UX file system. A dump that previously took 3 hours to complete should now
take only about an hour.
You can use the crashconf command (see crashconf(1M)) to disable or enable compressed
dumps. (Compression is configured into the kernel by default.) During a crash event you
can also choose to override the previously defined dump compression setting.
Normally, there is no benefit in disabling compression unless the initial (compressed) dump
is corrupt and you want to attempt an uncompressed dump on a subsequent crash event.
Compressed saves (to the HP-UX file system area) are only possible with sequential dumps.
Using the command crashutil, you can convert the compressed dump file to any of several
dump formats for storage and analysis. See the manpage crashutil(1M) for detailed
information on how to do this and what dump formats are available.
A compressed dump file requires less disk storage space and creates a smaller tar file that
takes less time to copy to tape or transmit for analysis, for example via ftp)
Start-up and Shutdown 81