![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
If your system does not require the page file for storing system crash dumps, you can move it off the system disk. However, you should keep one page file on the system disk, if possible, so that you can boot the system if another disk holding the page files becomes unavailable. The swap file can also be moved off the system disk.
The DCL command SHOW MEMORY/FILES displays information about the page and swap files existing on your system, including file names, sizes, and the amount of space used. For example:
$ SHOW MEMORY/FILES
System Memory Resources on 12-MAY-1996 11:54:20.06
Paging File Usage (pages): Free Reservable Total
DISK$PAGE:[SYSEXE]SWAPFILE_IPL31.SYS;2 79992 79992 79992
DISK$PAGE:[SYSEXE]PAGEFILE_IPL31.SYS;1 23263 -370027 249992
Note that the number displayed in the column labeled "Reservable" can be a negative number. Processes can reserve more space than is available because it is unlikely that all the reserved space will be used for paging at one time.
When you install or upgrade the operating system, AUTOGEN automatically calculates appropriate sizes for your system; these sizes are based on your hardware configuration and your system parameters. However, you can manually calculate the sizes for these files. The following sections describe how to determine appropriate sizes for the system page, swap, and dump files.
Sufficient space in the system dump file is critical to saving a complete crash dump. The AUTOGEN command procedure calculates an appropriate size for your system dump file. However, if you want to manually calculate the system dump file size, use the following formula, which calculates the file size required to hold a physical dump.
For SYSDUMP.DMP
On VAX systems, use the following formula:
size-in-blocks(SYS$SYSTEM:SYSDUMP.DMP) = size-in-pages(physical-memory) + number-of-error-log-buffers * blocks-per-buffer + 1
On Alpha systems, use the following formula:
size-in-blocks(SYS$SYSTEM:SYSDUMP.DMP) = size-in-pages(physical-memory) * blocks-per-page + number-of-error-log-buffers * blocks-per-buffer + size-in-pages (physical memory)/512 + 2
| size-in-pages | Is the size of physical memory, in pages. Use the DCL command SHOW MEMORY to determine the total size of physical memory on your system. |
| blocks-per-page |
Is the number of blocks per page of memory.
On Alpha systems, calculate the number of blocks per page of memory by dividing the system's page size by 512 (the size of a block). Use the following commands: $ PAGESIZE==F$GETSYI ("PAGE_SIZE")
|
| number-of-error-log-buffers | Is the value of the system parameter ERRORLOGBUFFERS. This parameter sets the number of error log buffers to permanently allocate in memory. |
| blocks-per-buffer | Is the value of the system parameter ERLBUFFERPAGES. This parameter sets the number of pages of memory in each buffer. |
A large memory system or a system with small disk capacity might not be able to supply enough disk space for a full memory dump. Under these circumstances, you should set the system parameter DUMPSTYLE to the appropriate value to indicate that the system is to dump only selective information. For more information, see Section 15.5.
If SYS$SYSTEM:SYSDUMP.DMP does not exist, the system writes crash dumps to the primary page file SYS$SYSTEM:PAGEFILE.SYS. The AUTOGEN command procedure calculates an appropriate size for your page file. However, to manually calculate the minimum page file size required to hold crash dumps, use the following formula:
On VAX systems:
size-in-blocks(SYS$SYSTEM:PAGEFILE.SYS) = size-in-pages(physical-memory) + number-of-error-log-buffers * blocks-per-buffer + 1 + 1000
On Alpha systems:
size-in-blocks(SYS$SYSTEM:PAGEFILE.SYS) = size-in-pages(physical-memory) * blocks-per-page + number-of-error-log-buffers * blocks-per-buffer + size-in-pages (physical memory)/512 + 2 + value of the system parameter RSRVPAGCNT
where:
| size-in-pages | Is the size of physical memory, in pages. Use the DCL command SHOW MEMORY to determine the total size of physical memory on your system. |
| blocks-per-page |
Is the number of blocks per page of memory.
On Alpha systems, calculate the number of blocks per page of memory by dividing the system's page size by 512 (the size of a block). Use the following commands: $ PAGESIZE==F$GETSYI ("PAGE_SIZE")
|
| number-of-error-log-buffers | Is the value of the system parameter ERRORLOGBUFFERS. This parameter sets the number of error log buffers to permanently allocate in memory. |
| blocks-per-buffer | Is the value of the system parameter ERLBUFFERPAGES. This parameter sets the number of pages of memory in each buffer. |
| RSRVPAGCNT | Is the value of the RSRVPAGCNT special system parameter. |
Caution
This formula calculates only the minimum size requirement for saving a dump in the system's primary page file. For most systems, the page file must be larger than this to avoid hanging the system. For more information about calculating the page file size, see Section 15.4.3.
On Alpha systems, the AUTOGEN command procedure calculates the appropriate size of your error log dump file. However, to calculate the size of the file manually, use the following formula, which calculates the file size required to hold all the error log buffers:
size-in-blocks(SYS$SYSTEM:SYS$ERRLOG.DMP) = number-of-error-log-buffers * blocks-per-buffer + 2
where:
| number-of-error-log-buffers | Is the value of the system parameter ERRORLOGBUFFERS. This parameter sets the number of error log buffers that are permanently allocated in memory. |
| blocks-per-buffer | Is the value of the system parameter ERLBUFFERPAGES. This parameter sets the number of pages of memory in each buffer. |
Sufficient page file space is critical to system performance. The AUTOGEN command procedure calculates an appropriate size for your page file space. The size calculated by AUTOGEN should be sufficient. However, to manually calculate the size for page file space, use one of the following formulas.
On VAX systems, use the following formula:
size-in-blocks (total for all page files on the system) = size-of-average-process (in pages) * maximum-number-of-processes
$ SHOW PROCESS/CONTINUOUS/ID=pid
If the result of the formula is less than VIRTUALPAGECNT, use the value of VIRTUALPAGECNT instead.
To determine a system's virtual page count, enter the following command:
$ WRITE SYS$OUTPUT F$GETSYI ("VIRTUALPAGECNT")
On Alpha Systems
On Alpha systems, use the following formula:
size-in-blocks (total for all page files on the system) = physical-memory-size (in pagelets) + 8192 (supplementary amount)
To calculate the physical memory size in pagelets, follow these steps:
$ SHOW MEMORY/PHYSICAL_PAGES
$ WRITE SYS$OUTPUT F$GETSYI ("PAGE_SIZE")
Adding 8192 to the physical memory size provides an extra margin of safety during periods of heavy paging activity.
After making the initial calculation, observe your system over time and make adjustments as necessary.
The page file size you calculate can be represented in one of the following ways:
Once you determine an initial size for your page file or files (either with AUTOGEN or manually), monitor page file usage by executing AUTOGEN with the following command:
$ @SYS$UPDATE:AUTOGEN SAVPARAMS TESTFILES FEEDBACK
With this command, AUTOGEN writes page file usage and size recommendations to the feedback report AGEN$PARAMS.REPORT. (For more information on AUTOGEN and the feedback report, see Section 14.4 and Section 14.4.2.) The DCL command SHOW MEMORY/FILES also displays file usage, as explained in Section 15.3.
Keep page file usage less than half the size of the page file or files. If a paging file starts to fill to the point where system performance is being affected, a message is printed on the console terminal. If this happens, increase the size of your page file or files or install additional files.
Note
Your system resources and work load affect the required size of your page file. You should be familiar with your system resources and work load. For more information, see the OpenVMS Performance Management.
Limit the amount of page file space consumed by user programs by using the /PGFLQUOTA qualifier of the AUTHORIZE commands ADD and MODIFY. (See the AUTHORIZE section in the OpenVMS System Management Utilities Reference Manual for more information.) Do not reduce the value of /PGFLQUOTA below 1024. Size requirements of the page file vary widely, depending on user applications.
Sufficient swap file space is critical to system performance. The AUTOGEN command procedure calculates an appropriate size for your swap file space. To manually calculate the size for swap file space, use the following formula:
size-in-blocks (total for all swap files on the system) = maximum-number-of-processes * average-working-set-quota-of-processes-on-system
where:
| maximum-number-of-processes | Is the value of the MAXPROCESSCNT system parameter. |
| average-working-set-quota-of-processes-on-system |
Is the average value of the WSQUOTA limit for processes running on the
system.
On VAX systems, specify the value in pages. On Alpha systems, specify the value in pagelets. |
The size you calculate can be represented in any of the following ways:
Once you have determined an appropriate size for swap file space (either manually or with AUTOGEN), monitor swap file usage with the DCL command SHOW MEMORY/FILES as explained in Section 15.3. Keep at least one-third of the swap file space unused; otherwise, system performance can be severely affected.
Note
Your system resources and work load affect the required size of your swap file. You should be familiar with your system resources and work load. For more information, see the OpenVMS Performance Management.
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.
Options for Minimizing System Dump File Size
Use one of the following options to minimize the size of the system dump file when disk space is insufficient:
| Type | Available Information | Unavailable Information |
|---|---|---|
| Physical 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. |
Section 15.5.1 discusses the order in which information is written to a selective system dump on Alpha and VAX systems. Section 15.5.2 discusses how this order can be fine-tuned on Alpha systems.
Following are lists of the order in which information is written to selective dumps on VAX and Alpha systems.
On VAX systems, information is written to selective dumps in the following order:
On Alpha systems, information is written to selective system dumps in the following order:
Note that on Alpha systems, processes are dumped in two stages: the page tables for the process first, and then the body of the process.
Usage Notes on VAX and Alpha Systems
On both VAX and Alpha platforms, no process is dumped twice. For example, on Alpha systems, if the current process is the Swapper, it is dumped only once.
Similarly, on Alpha 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 nonkey process.
On Alpha systems, a new category of processes, key processes, are dumped immediately following PT, S0/S1, and S2, including transition pages that link back. 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, follow these steps:
You can edit the data file and run the image at any time the system is running. Therefore, if a process is hung or appears to be stuck in a miscellaneous wait state such as RWAST, the system manager can designate the process as a priority process and then force a crash.
The System Dump Analyzer utility (SDA) lets you interpret the contents of the system dump file to investigate the probable causes of the crash. For information on analyzing a crash dump, see the OpenVMS VAX System Dump Analyzer Utility Manual or the OpenVMS Alpha System Dump Analyzer Utility Manual.
If your system fails, make a copy of the system dump file written at the time of the failure and contact your Digital support representative. For information on copying the system dump file, see Section 15.9.
SDA CLUE (Crash Log Utility Extractor) commands automate the analysis of crash dumps and maintain a history of all fatal bugchecks on a standalone system or cluster. SDA CLUE commands can be used in conjunction with SDA to collect and decode additional dump file information not readily accessible through standard SDA.
On Alpha systems, SDA is automatically invoked by default when you reboot the system after a system failure. To better facilitate crash dump analysis, SDA CLUE commands automatically capture and archive summary dump file information in a CLUE listing file.
A startup command procedure initiates commands that:
The CLUE HISTORY command adds a one-line summary entry to a history file and saves the following output from SDA CLUE commands in the listing file:
The contents of this CLUE list file can help you analyze a system failure.
If these files accumulate more space than the threshold allows (default 5000 blocks), the oldest files are deleted until the threshold limit is reached. This can also be customized using the CLUE$MAX_BLOCK logical name.
To inhibit the running of CLUE at system startup, define the logical CLUE$INHIBIT in the SYLOGICALS.COM file as /SYS TRUE.
It is important to remember that CLUE$nodename_ddmmyy_hhmm.LIS contains only an overview of the crash dump and does not always contain enough information to determine the cause of the crash. If you must do an indepth analysis of the system crash, Digital recommends that you always use the SDA COPY command to save the dump file.
Invoke CLUE commands at the SDA prompt as follows:
SDA> CLUE CONFIG
CLUE commands provide summary information of a crash dump captured from a dump file. When debugging a crash dump interactively, you can use SDA CLUE commands to collect and decode some additional information from a dump file, which is not easily accessible through standard SDA. For example, CLUE can quickly provide detailed XQP summaries.
You can also use CLUE commands interactively on a running system to help identify performance problems.
You can use all CLUE commands when analyzing crash dumps; the only CLUE commands that are not allowed when analyzing a running system are CLUE CRASH, CLUE ERRLOG, CLUE HISTORY, and CLUE STACK.
On VAX systems, the Crash Log Utility Extractor (CLUE) displays the contents of a crash history file. By examining the contents of the crash history file, you can understand and resolve the issues responsible for failures (crashes), and you might also obtain other useful data.
The crash history file, which is created and updated by CLUE, contains key parameters from crash dump files. Unlike crash dumps, which are overwritten with each system failure and are therefore typically available only for the most recent failure, the crash history file is a permanent record of system failures.
After a system fails and physical memory is copied to the crash dump file, CLUE automatically appends the relevant parameters to the file CLUE$OUTPUT:CLUE$HISTORY.DATA when the system is restarted. The remainder of this section describes how you can use CLUE to display the data it has collected; reference information about CLUE is available in the OpenVMS System Management Utilities Reference Manual.
Note
The history file typically grows by about 10 to 15 blocks for each entry. You can limit the number of entries in the binary file by defining the logical name CLUE$MAX_ENTRIES to be the maximum number desired. When this number is reached, the oldest entries are deleted from the history file.By default, operator shutdowns are recorded in the history file. You can exclude information from operator shutdowns in the history file by defining the logical name CLUE$EXCLUDE_OPERS as being TRUE, for example by including the following line in SYS$MANAGER:SYSTARTUP_VMS.COM:
$ DEFINE /SYSTEM CLUE$EXCLUDE_OPERS TRUE
To display data using CLUE, you must first define the following symbol:
$ CLUE :== $CLUE
After defining the symbol, you can use CLUE to display information by entering the following command:
$ CLUE/DISPLAY CLUE_DISPLAY>
At the CLUE_DISPLAY> prompt, you can issue commands to do the following:
CLUE_DISPLAY> DIRECTORY
CLUE_DISPLAY> SHOW ALL 7
CLUE_DISPLAY> EXTRACT 7/OUTPUT=15MAYCRASH.TXT
6017P049.HTM OSSG Documentation 22-NOV-1996 14:22:28.24
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.