OpenVMS System Manager's Manual

On VAX systems, AUTOGEN always creates a minimal SYSDUMP.DMP file for error log buffers.

On Alpha systems, AUTOGEN only manipulates the size of the error log dump file on the system disk.

If you do not want AUTOGEN to change the sizes of the primary files, specify the following symbols in MODPARAMS.DAT:

PAGEFILE =   0 
SWAPFILE =   0 
DUMPFILE =   0 
ERRLOGDUMP = 0 ! Alpha only 

These symbols direct AUTOGEN to ignore the primary page, swap, and dump files when calculating sizes.

If the creation or extension of a system page, swap, or dump file would cause the target disk to become more than 95 percent full, AUTOGEN issues a warning and does not perform the operation.

On Alpha systems, however, the 95 percent rule does not apply to the error log dump file, SYS$ERRLOG.DMP. This file is created if the disk can hold it.

You can use AUTOGEN to create a page, swap, or dump file that is smaller than the current version of the file. After you have booted and begun using the new file, remember to use the DCL command PURGE to reclaim the disk space from the old version of the file.

To determine the current sizes of installed page and swap files, enter the DCL command SHOW MEMORY/FILES. If you increased the size of any of these files and have not rebooted, this command displays the original sizes. Use the DIRECTORY command to determine the size of dump files.

Note

AUTOGEN does not change file sizes if you specify a value of 0 or a value that is within 10 percent of the current size.

Table 15-4 lists the symbols you can define in MODPARAMS.DAT to control the total size of page file, swap file, system dump file, or error log dump file space space.

Table 15-4 Symbols for Controlling the Total Size of Page, Swap, System Dump, or Error Log Dump File Space

Operation	Page File Symbol	Swap File Symbol	Dump File Symbol	Error Log File Symbol
To define the total amount of space	PAGEFILE = n¹	SWAPFILE = n¹	DUMPFILE = n¹	ERRLOGDUMP = n¹
To increase total size	ADD_PAGEFILE = n	ADD_SWAPFILE = n	ADD_DUMPFILE = n	ADD_ERRLOGDUMP = n
To specify maximum total size	MAX_PAGEFILE = n	MAX_SWAPFILE = n	MAX_DUMPFILE = n	MAX_ERRLOGDUMP = n
To specify minimum total size	MIN_PAGEFILE = n	MIN_SWAPFILE = n	MIN_DUMPFILE = n	MIN_ERRLOGDUMP = n

Table 15-5 lists the symbols you can define in MODPARAMS.DAT to control the size of individual files.

Table 15-5 Symbols for Controlling the Size of Individual Page and Swap Files

Operation	Page File Symbol¹	Swap File Symbol¹
To specify file size	PAGEFILE n_SIZE = block-size	SWAPFILE n_SIZE = block-size
To increase file size	ADD_PAGEFILE n_SIZE = block-size	ADD_SWAPFILE n_SIZE = block-size
To specify maximum file size	MAX_PAGEFILE n_SIZE = block-size	MAX_SWAPFILE n_SIZE = block-size
To specify minimum file size	MIN_PAGEFILE n_SIZE = block-size	MIN_SWAPFILE n_SIZE = block-size

Examples

1. The following line in MODPARAMS.DAT specifies that all page file space should total 100,000 blocks:

   PAGEFILE = 100000 
   

   
   If you had only a primary page file, the resulting size of that file would be 100,000 blocks. If you had multiple page files, the difference between the total current size and the total new size would be spread across secondary files. For example, if you specified PAGEFILE = 100000, the changed page file sizes would be as follows:

   File	Original Size (in Blocks)	Resulting Size (in Blocks)
   Primary page file	10,000	10,000
   Secondary page file 1	30,000	45,000
   Secondary page file 2	30,000	45,000

2. To direct AUTOGEN to set the primary page file size to 10,000 blocks, use the symbol definition:

   PAGEFILE1_SIZE = 10000 
   

3. To direct AUTOGEN to create a new secondary swap file named PAGED$:[PAGESWAP]SWAPFILE.SYS that holds 30,000 blocks, use the symbol definitions:

   SWAPFILE2_NAME = "PAGED$:[PAGESWAP]SWAPFILE.SYS" 
   MIN_SWAPFILE2_SIZE = 30000 
   

Digital recommends you use AUTOGEN to change sizes of system page, swap, and dump files. However, you can use the command procedure SYS$UPDATE:SWAPFILES.COM to change the size of primary system page, swap, and dump files. SWAPFILES.COM shows you the current size of the system page, swap, and dump files before you change the sizes.

If you change the sizes of system page, swap, or dump files, you must edit MODPARAMS.DAT to specify the new sizes, as explained in Section 15.15.1.2. If you do not specify the new sizes in MODPARAMS.DAT, AUTOGEN resizes the files next time it runs.

The procedure displays the sizes of the current system page, swap, and dump files in SYS$SYSTEM, and the amount of space remaining on the system disk. It then allows you to enter new sizes, or keep the existing sizes for these files. If you specify a size that is larger than that of an existing file, the procedure automatically extends the size of a page or dump file. If you specify a smaller size for a system page, swap, or dump file, a new version of the file is created.

How to Perform This Task

1. Enter the following command to invoke the command procedure:

   $ @SYS$UPDATE:SWAPFILES.COM
   

   
   The system displays the current files found in SYS$SYSTEM and their sizes. For example:

   Current file sizes are: 
    
   Directory SYS$SYSROOT:[SYSEXE] 
    
   PAGEFILE.SYS;1    16384 
   SYSDUMP.DMP;1      4128 
   SWAPFILE.SYS;1     3072 
    
   Total of 3 files, 23584 blocks. 
    
   There are 128741 available blocks on SYS$SYSDEVICE. 
   

2. In response to the following prompt, type the desired size, in blocks, for the page file. To keep the same size, press Return:

   Enter new size for page file: 
   

3. In response to the following prompt, type the desired size, in blocks, for the dump file. To keep the same size, press Return:

   Enter new size for system dump file: 
   

4. In response to the following prompt, type the desired size, in blocks, for the swap file. To keep the same size, press Return:

   Enter new size for swap file: 
   

5. Shut down and reboot the system to use the new files.
6. After the system reboots, purge obsolete copies of the files. Do not delete the old files until the system reboots.
7. Edit MODPARAMS.DAT to include the new file sizes, as explained in Section 15.15.1.2. If you do not specify the new sizes in MODPARAMS.DAT, AUTOGEN will automatically resize the files the next time it runs.

Example

$ @SYS$UPDATE:SWAPFILES.COM
To leave a file size at its current value type a 
carriage return in response to its size prompt. 
Current file sizes are: 
 
Directory SYS$SYSROOT:[SYSEXE] 
 
PAGEFILE.SYS;1    100000 
SYSDUMP.DMP;1      28000 
SWAPFILE.SYS;1     33000 
 
Total of 3 files, 161000 blocks. 
 
There are 128741 available blocks on SYS$SYSDEVICE. 
 
Enter new size for page file: [Return]
Enter new size for system dump file: 30000
%SYSGEN-I-EXTENDED, SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1 extended
Enter new size for swap file: [Return]
 
 
*********************************************************************** 
*  Please reboot in order for the new files to be used by the system. * 
*  After rebooting, purge obsolete copies of the files.               * 
*  DO NOT delete the old files until after the reboot.                * 
***********************************************************************

15.15.3 Using SYSGEN

Note

The SWPFILCNT and PAGFILCNT system parameters limit the number of swap and page files that the system installs. See the OpenVMS System Management Utilities Reference Manual for more information.

How to Perform This Task

1. Determine the location and appropriate size of the files. For information, see Section 15.4.
2. Invoke SYSGEN and enter the CREATE command in the following format:

   CREATE file-spec/SIZE=block-count 
   

   
   where:
   file-spec specifies the full file specification.
   block-count specifies the size of the file in blocks.
   If the file you specify already exists and the size you specify is larger than the existing file, the command extends the existing file. If the file you specify already exists and the size you specify is smaller than the existing file, the command creates a new file of the specified size.
   For example, the following command extends the existing, smaller primary page file PAGEFILE.SYS:

   SYSGEN> CREATE PAGEFILE.SYS/SIZE=100000
   

   
   For more information on the SYSGEN command CREATE, see the SYSGEN section in the OpenVMS System Management Utilities Reference Manual.

   ---

   Note

   Frequent file creation and deletion can cause the free space on a disk to become severely fragmented. SYSGEN issues a HEADERFULL warning message if it determines that the creation or extension of a system file would cause that file to become fragmented enough to render the system unbootable. If this occurs, Digital recommends that you back up and restore your system disk to consolidate the free space on the volume into one contiguous area. For more information, see Section 10.17.
   After you restore the disk, retry the SYSGEN operation. When SYSGEN issues a warning message, the file might be somewhat larger, but not as large as the value specified in the CREATE command.

   ---

3. Use the following table to determine if you should reboot to use the new or modified file:

   Type	Change	Reboot Required?
   Primary page, swap, system dump, or error log dump file¹	New file	Yes
   	Extended file	Yes
   Secondary page or swap file	New file	No²
   	Extended file	Yes

   ---

   ¹Primary page, swap, and dump files are SYS$SPECIFIC:[SYSEXE] PAGEFILE.SYS, SWAPFILE.SYS, SYSDUMP.DMP; and SYS$ERRLOG.DMP.
   ²Although rebooting the system is unnecessary, you must install secondary files before the system can use them. For more information, see Section 15.13.
   

   ---

4. If you create a new version of the file, purge the old version after the system reboots.
5. Add commands to the site-specific startup command procedure SYPAGSWPFILES.COM to make sure the files are installed each time the system boots. For instructions, see Section 15.13.
6. If you do not want AUTOGEN to resize the files according to its calculations, edit MODPARAMS.DAT to specify the sizes of these files. Follow the instructions in Section 15.15.1.2.

Example

The commands in the following example extend the existing files PAGEFILE.SYS, SWAPFILE.SYS, and SYSDUMP.DMP to the specified sizes:

$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CREATE PAGEFILE.SYS/SIZE=100000
%SYSGEN-I-EXTENDED, SYS$SYSROOT:[SYSEXE]PAGEFILE.SYS;1 extended
SYSGEN> CREATE SWAPFILE.SYS/SIZE=30000
%SYSGEN-I-EXTENDED, SYS$SYSROOT:[SYSEXE]SWAPFILE.SYS;1 extended
SYSGEN> CREATE SYSDUMP.DMP/SIZE=33000
%SYSGEN-I-EXTENDED, SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;1 extended
SYSGEN> EXIT   

This chapter introduces the basic concepts of performance management. For more detailed information, see OpenVMS Performance Management.

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Knowing your work load	Section 16.2
Choosing a work load management strategy	Section 16.3
Distributing the work load	Section 16.4
Predicting when tuning is required	Section 16.6
Evaluating tuning success	Section 16.7
Choosing performance options	Section 16.8
Installing images with the Install utility (INSTALL)	Section 16.9

This chapter explains the following concepts:

Concept	Section
Performance management	Section 16.1
System tuning	Section 16.5
Images and known images	Section 16.9.1
Known file lists	Section 16.9.2
Attributes of known images	Section 16.9.3

16.1 Understanding Performance Management

Performance management means optimizing your hardware and software resources for the current work load. This task entails several distinct but related activities:

• Acquiring a thorough familiarity with your work load and an understanding of how that work load exercises the system's resources. This knowledge, combined with an appreciation of the operating system's resource management mechanisms, will enable you to establish realistic standards for system performance in areas such as the following:
  • Interactive and batch throughput
  • Interactive response time
  • Batch job turnaround time
• Routinely monitoring system behavior to determine if, when, and why a given resource is approaching capacity.
• Investigating reports of degraded performance from users.
• Planning for changes in the system work load or hardware configuration and being prepared to make any necessary adjustments to system values.
• Performing, after installation, certain optional system management operations.

One of the most important assets that a system manager brings to any performance evaluation is an understanding of the normal work load and behavior of the system. Each system manager must assume the responsibility for understanding the system's work load sufficiently to be able to recognize normal and abnormal behavior; to predict the effects of changes in applications, operations, or usage; and to recognize typical throughput rates. The system manager should be able to answer such questions as the following:

• What is the typical number of users on the system at any given time of day?
• What is the typical response time for various tasks for this number of users, at any given hour of operation?
• What are the peak hours of operation?
• Which jobs typically run at which time of day?
• Which commonly run jobs are intensive consumers of the CPU, memory, and disk space?
• Which applications involve the most image activations?
• Which parts of the system software, if any, have been modified or user-written, such as device drivers?
• Do any known, or anticipated, system bottlenecks exist?

If you are new to the OpenVMS operating system or to system management, you should observe system operation using the following tools:

• Monitor utility
• Accounting utility
• SHOW commands (available through DCL)

The OpenVMS Performance Management provides detailed procedures for using the Monitor utility and, to a lesser extent, other operating system tools to observe and evaluate system performance. Also, the OpenVMS System Management Utilities Reference Manual provides reference information about using the Monitor utility.

Over time you will learn about metrics such as the typical page fault rate for your system, the typical CPU usage, the normal memory usage, and typical modes of operation. You will begin to see how certain activities affect system performance and how the number of users or the time of day affects some of the values.

As you continue to monitor your system, you will come to know what range of values is acceptable, and you will be better prepared to use these same tools, together with your knowledge, to detect unusual conditions. Routine evaluation of the system is critical for effective performance management. The best way to avoid problems is to anticipate them; you should not wait for problems to develop before you learn how the system performs.

You can learn more about your system's operation if you use the Monitor and Accounting utilities on a regular basis to capture and analyze certain key data items. By observing and collecting this data, you will also be able to see usage trends and predict when your system may reach its capacity.

You should also understand that system resources are used by system management tools. Be careful, therefore, in selecting the items you want to measure and the frequency with which you collect the data. If you use the tools excessively, the consumption of system resources to collect, store, and analyze the data can distort your picture of the system's work load and capacity. The best approach is to have a plan for collecting and analyzing the data.

16.3 Choosing a Work Load Management Strategy

System performance is directly proportional to the efficiency of work load management. Each installation must develop its own strategy for work load management. Before adjusting any system values, make sure you resolve the following issues:

• Does the work load "peak" at a particular time of day, that is, is it noticeably heavier than at other times?
• Can the work load be better balanced? Perhaps some voluntary measures can be adopted by users, after appropriate discussion.
• Could some jobs be run better as batch jobs, preferably during nonpeak hours?
• Have primary and secondary hours of operation been employed with users? If not, could system performance benefit by adopting this practice? If the primary and secondary hours are in use, are the choices of hours the most appropriate for all users? (Plan to review this issue every time you either add or remove users or applications, to ensure that the desired balance is maintained.)
• Can future applications be designed to work around any known or expected system bottlenecks? Can present applications be redesigned somewhat, for the same purpose? (See the Guide to OpenVMS File Applications.)
• Are you making the best use of the code-sharing ability that the operating system offers? Code sharing provides an excellent means to conserve memory and improve performance over the life of the system.

You should distribute the work load as evenly as possible over the time your system is running. Although the work schedule for your site may make it difficult to schedule interactive users at optimum times, the following techniques may be helpful:

• Run large jobs as batch jobs---Establish a site policy that encourages the submission of large jobs on a batch basis. Regulate the number of batch streams so that batch usage is high when interactive usage is low. You might also want to use DCL command qualifiers to run batch jobs at lower priority, adjust the working set sizes, or control the number of concurrent jobs. For information about setting up your batch environment, see Section 13.2.1.
• Restrict system use---Do not permit more users to log in at one time than the system can support with an adequate response time. You can restrict the number of interactive users with the DCL command SET LOGINS/INTERACTIVE. You can also control the number of concurrent processes with the MAXPROCESSCNT system parameter, and the number of remote terminals allowed to access the system at one time with the RJOBLIM system parameter. See Section 14.5 for information about modifying system parameters. See the OpenVMS System Management Utilities Reference Manual for descriptions of all system parameters.
  You might also restrict use of the system by groups of users to certain days and hours of the day. You can use the Authorize utility to define the permitted login hours for each user. In particular, refer to the AUTHORIZE qualifier /PRIMEDAYS. For more information, see Chapter 6 and the AUTHORIZE section of the OpenVMS System Management Utilities Reference Manual.
  You can use the DCL command SET DAY to override the conventional day of the week associations for primary and secondary days. For example, you might want to specify a primary day of the week as a secondary day when it is a holiday.
• Design applications to reduce demand on binding resources---If you know where your system bottlenecks are or where they will likely occur in the near future, you can distribute the work load more evenly by planning usage that minimizes demand on any bottleneck points. (See the Guide to OpenVMS File Applications.)

Tuning is the process of altering various system values to improve overall performance possible from any given configuration and work load. However, the process does not include the acquisition and installation of additional memory or devices, although in many cases such additions (when made at the appropriate time) can vastly improve system operation and performance.

On most systems, the work load is constantly changing. System parameters that produce optimal performance at one time may not produce optimal performance a short time later as the work load changes. Your goal is to establish values that produce acceptable performance under all of the changing work load conditions.

  6017P051.HTM
  OSSG Documentation
  22-NOV-1996 14:22:31.54

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal