Minimizing System Dump File Size When Disk
Space Is Insufficient
In
certain system configurations, it might be impossible to preserve
the entire contents of memory in a disk file. For instance, a large
memory system might not be able to supply enough disk space for
a full memory dump. If your system attempts to save all of memory
but the dump file is too small to accommodate the entire dump, the
System Dump Analyzer utility (SDA) might not be able to analyze
the dump.
On VAX systems, insufficient dump space would also prevent
the Crash Log Utility Extractor (CLUE) from being able to analyze
the dump.
Table 3 Comparison of Physical and Selective System Dump Files
Type
Available Information
Unavailable Information
Physical dump (also
known as full dump)
Complete contents
of physical memory in use, stored in order of increasing physical
address and error log buffers.
Contents of paged-out memory
at the time of the crash.
Selective dump
System page table, global
page table, system space memory, error log buffers, and process
and control regions (plus global pages) for all saved processes.
Contents of paged-out memory at the time
of the crash, process and control regions of unsaved processes,
and memory not mapped by a page table.
To direct your system to save selective system dumps, set
bit 0 of the system parameter DUMPSTYLE. System parameters and their
values are in an appendix of the HP OpenVMS System Management Utilities Reference Manual. For information about
how to change system parameter values, see
Modifying System Parameters with AUTOGEN.
Compressed dumps On Alpha and I64 systems, if you set bit 3 of the DUMPSTYLE
system parameter, OpenVMS writes the physical or selective system
dump in a compressed format. (The exact amount of the compression
depends on system use, but the typical compressed dump is about
60 percent of its original size.) If you use compressed dumps, AUTOGEN
sizes the system dump file at 2/3 of its uncompressed size.
Dump off system disk (DOSD) If you set bit 2 of the DUMPSTYLE system parameter and meet
all the other requirements, OpenVMS writes the system dump to a
disk other than the system disk. For details, see
Writing the System Dump File to an Alternate Disk.
Understanding the Order of Information in
a Selective System Dump The following lists show the order in which information is
written to selective dumps on VAX, Alpha, and I64 systems.
On
VAX systems, information is written to selective dumps in the following
order:
System page table
(SPT)
System space (including process page tables, page
frame number (PFN) database, and global page table (GPT) )
Global pages that appear in the working set of any
process
Processes resident at the time of the crash:
Current process
on crash CPU
Predefined processes (hardcoded into BUGCHECK)
Current processes on other CPUs
Other processes resident at the time of the crash,
in order by process index
On Alpha and I64 systems, information is written to selective
system dumps in the following order:
Page table (PT)
space for shared addresses (S0/S1/S2)
S0/S1 space
S2 space
Any system space pages (P1, S0/S1, S2) that have
been replicated for performance reasons, where the contents of the
replicated page is different from the original
Memory map pages for Galaxy shared memory regions,
if appropriate
Key processes:
Current process
on crash CPU
Swapper
Current processes on CPUs that have failed to record
their crash state
Current processes on other CPUs
Site-specific priority processes (see next section)
HP-defined priority processes (hardcoded
into BUGCHECK):
On Alpha, I64, and VAX platforms, no process is dumped twice.
For example, on Alpha and I64 systems, if the current process is
the Swapper, it is dumped only once.
Similarly, on Alpha and I64 systems, no global page is dumped
twice. Therefore, if a page in the working set of a key process
is dumped in the "Key global pages" section, it is not dumped again
later just because it is also in the working set of a non-key process.
Fine-Tuning
the Order That Processes Are Written in Selective System Dumps (Alpha
and I64) On Alpha and I64 systems, a set of processes, known as key
processes, are dumped immediately following PT, S0/S1,
and S2, including transition pages that link back to the process. The system manager
can designate additional processes to be treated as key processes.
These processes have priority over other processes in a dump, thus
ensuring that the selected processes are successfully written when
the dump file is too small to contain all processes.
To
designate the order of processes in a dump, use the SYSMAN DUMP_PRIORITY
commands:
DUMP_PRIORITY
ADD -- to add processes to the list of those to be dumped early
in the dump.
DUMP_PRIORITY LOAD -- to
update the in-memory copy of the list. Note that the DUMP_PRIORITY LOAD
command is automatically run during system startup.
You can add new processes and update the in-memory copy of
the list at any time the system is running. Therefore, if a process
is hung, the system manager can designate the process as a priority
process and then force a crash.