Document revision date: 15 July 2002

When a single process fails but the operating system is still running, the system can create a process dump that contains information about the process to assist in determining what caused the process to fail.

By default, process dumps are written to the current default directory of the user. You can override this by defining the logical name SYS$PROCDMP to identify an alternate directory path. Note that the name of the process dump file is always the same as the name of the main image active at the time the process dump is written, with the file extension .DMP.

On Alpha systems, a process dump is either complete or partial. A complete process dump contains all of process space and all process-pertinent data from system space. A partial process dump contains only user-readable data from process space and only those data structures from system space that are not deemed sensitive. Privileged or protected data, such as an encryption key in third-party software, might be considered sensitive.

On Alpha systems, you can force a dump to be written for another process with the DCL command SET PROCESS/DUMP=NOW process-spec. This command causes the contents of the address space occupied by process-spec to be written immediately to the file named image-name.DMP in the current directory of process-spec.

For more information about the DCL command SET PROCESS/DUMP, refer to the OpenVMS DCL Dictionary: N--Z.

16.17.1 Understanding Privileged Users and Access to Process Dumps (Alpha Only)

For this discussion, a privileged user is one who satisfies one of the following conditions:

• Has one or more of the privileges CMKRNL, CMEXEC, SYSPRV, READALL, or BYPASS
• Is a member of a system UIC group (by default [10,n] or lower). Such users are treated as though they hold SYSPRV privilege.

Holders of CMKRNL or CMEXEC can write complete process dumps. Holders of any of the other privileges mentioned above can read a process dump wherever it has been written.

In general, nonprivileged users should not be able to read complete process dumps, and by default they cannot do so. However, certain situations require that a nonprivileged user be able to read a complete process dump. Other situations require that a nonprivileged user be able to create a complete process dump but be able to read only a partial process dump.

Rights identifier IMGDMP$READALL enables a nonprivileged user to read a complete process dump. Rights identifier IMGDMP$PROTECT protects a complete process dump from being read by the nonprivileged user that created the process dump. These rights identifiers are created during the installation of OpenVMS by the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE, which is also run automatically during system startup to ensure that these rights identifiers exist with the correct values and attributes.

If these rights identifiers have been deleted, you can run SYS$SYSTEM:IMGDMP_RIGHTS.EXE to recreate them. For example:

$ RUN SYS$SYSTEM:IMGDMP_RIGHTS %PROCDUMP-I-CREATED, rights identifier IMGDMP$READALL successfully created %PROCDUMP-I-CREATED, rights identifier IMGDMP$PROTECT successfully created

Note that IMGDMP$READALL has no attributes, but IMGDMP$PROTECT is created with the RESOURCE attribute.

16.17.2 Granting Access to Process Dumps (Alpha Only)

To allow a nonprivileged user to write and read complete process dumps, grant the rights identifier IMGDMP$READALL to the user. If the IMGDMP$READALL rights identifier does not exist, run the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE to create it (see Section 16.17.1). Then use AUTHORIZE to grant the rights identifier to the user. For example:

$ DEFINE /USER SYSUAF SYS$SYSTEM:SYSUAF.DAT !if necessary $ RUN SYS$SYSTEM:AUTHORIZE UAF> GRANT /IDENTIFIER IMGDMP$READALL <user> UAF> EXIT

Note that the user must log out and log in again to be able to exercise the rights identifier. A nonprivileged user with rights identifier IMGDMP$READALL can read and write complete process dumps without restriction.

16.17.3 Restricting Access to Process Dumps (Alpha Only)

You can allow a nonprivileged user to write a complete process dump and at the same time prevent the user from reading that process dump. To do so, perform the following steps:

1. If the IMGDMP$PROTECT rights identifier does not exist, run the image SYS$SYSTEM:IMGDMP_RIGHTS.EXE to create it (see Section 16.17.1).
2. Create a protected directory with rights identifier IMGDMP$PROTECT. For example:

   $ CREATE /DIRECTORY DKA300:[PROCDUMPS] - /PROTECTION=(S:RWE,O:RWE,G,W) /OWNER_UIC=IMGDMP$PROTECT $ SET SECURITY DKA300:[000000]PROCDUMPS.DIR - /ACL=((DEFAULT_PROTECTION,SYSTEM:RWED,OWNER:RWED,GROUP:,WORLD:), - (IDENTIFIER=IMGDMP$PROTECT,ACCESS=READ+WRITE), - (IDENTIFIER=IMGDMP$PROTECT,OPTIONS=DEFAULT, - ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL), - (CREATOR,ACCESS=NONE))

3. Define the executive-mode logical name SYS$PROTECTED_PROCDMP to point to the protected directory. For example:

   $ DEFINE /SYSTEM /EXECUTIVE_MODE SYS$PROTECTED_PROCDMP DKA300:[PROCDUMPS]

4. If DISKQUOTA is to be used on the disk containing the protected directory, specify the maximum disk space to be used for process dumps. For example:

   $ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA CREATE /DEVICE=DKA300 ! if necessary SYSMAN> DISKQUOTA ENABLE /DEVICE=DKA300 ! if necessary SYSMAN> DISKQUOTA ADD IMGDMP$PROTECT /DEVICE=DKA300 /PERMQUOTA=10000 SYSMAN> DISKQUOTA REBUILD /DEVICE=DKA300 ! if necessary SYSMAN> EXIT

You can choose to set up additional ACLs on the protected directory to further control which users are allowed to read and write process dumps there.

Note that to take a process dump when the image is installed with elevated privileges or belongs to a protected subsystem, the user must hold CMKRNL privilege, and is by definition a privileged user (see Section 16.17.1).

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

Information Provided in This Chapter

This chapter describes the following tasks:

Task	Section
Knowing your work load	Section 17.2
Choosing a work load management strategy	Section 17.3
Distributing the work load	Section 17.4
Predicting when tuning is required	Section 17.6
Evaluating tuning success	Section 17.7
Choosing performance options	Section 17.8
Installing images with the Install utility (INSTALL)	Section 17.10
Reserving memory for specific uses (Alpha only)	Section 17.11

This chapter explains the following concepts:

Concept	Section
Performance management	Section 17.1
System tuning	Section 17.5
Images and known images	Section 17.10.1
Known file lists	Section 17.10.2
Attributes of known images	Section 17.10.3

17.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 ones:
  • 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 ones:

• 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.

17.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? (Refer to 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 14.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 15.5 for information about modifying system parameters. Refer to 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 7 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. (Refer to 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.

Before you undertake any action, you must recognize that the following sources of performance problems cannot be cured by adjusting system values:

• Improper operation
• Unreasonable performance expectations
• Insufficient memory for the applications attempted
• Inadequate hardware configuration for the work load, such as too slow a processor, too few buses for the devices, too few disks, and so forth
• Improper device choices for the work load, such as using disks with insufficient speed or capacity
• Hardware malfunctions
• Poor application design
• Allowing one process to consume all available resources

When you make adjustments, you normally select a very small number of values for change, based on a careful analysis of the behavior you observed. You control system resources by tuning the values of two types of parameters:

Parameter Type	Description
System parameters	The values set for system parameters control system resources on a systemwide basis. The AUTOGEN command procedure automatically sets system parameters to appropriate values for your system configuration. AUTOGEN can also record feedback from a running system to adjust those parameters based on the system's work load. The OpenVMS Performance Management describes how to select the parameters and new values that are likely to produce the desired changes. Section 15.5 explains how to use AUTOGEN to modify system parameter values.
UAF limits and quotas	The values set for limits and quotas in each user authorization file (UAF) record control system resources on a per-user basis. To control these values, use the Authorize utility. For information, see Section 7.11.

Before you undertake any tuning operation, be sure you are familiar with the resource management mechanisms described in the OpenVMS Performance Management. Understand the nature of system values before adjusting them. Without the proper level of understanding, you might degrade, rather than improve, overall performance.

17.6 Predicting When Tuning Is Required

Under most conditions, tuning is rarely required for OpenVMS systems. The AUTOGEN command procedure, which is included in the operating system, establishes initial values for all the configuration-dependent system parameters so that they match your particular configuration. For information about AUTOGEN, see Section 15.4.

Additionally, the system includes features that, in a limited way, permit it to adjust itself dynamically during operation. That is, the system detects the need for adjustment in certain areas, such as the nonpaged dynamic pool, the working set size, and the number of pages on the free and modified page lists. The system makes rough adjustments in these areas automatically. As a result, these areas can grow dynamically, as appropriate, during normal operation.

Experience has shown that the most common cause of disappointment in system performance is insufficient hardware capacity. Once the demand on a system exceeds its capacity, adjusting system values will not result in any significant improvements, simply because such adjustments are a means of trading off or juggling existing resources.

Although tuning is rarely required, you should recognize that system tuning may be needed under the following conditions:

• If you have adjusted your system for optimal performance with current resources and then acquire new capacity, you must plan to compensate for the new configuration. In this situation, the first and most important action is to execute the AUTOGEN command procedure.
• If you anticipate a dramatic change in your work load, you should expect to compensate for the new work load.

Whenever you adjust your system, you should monitor its behavior afterward to be sure that you have obtained the desired results. To observe results, use the Monitor utility and the various forms of the DCL command SHOW. Refer to the OpenVMS DCL Dictionary for detailed information about the SHOW command. See Section 20.8.2 for information about using MONITOR. Refer to the OpenVMS System Management Utilities Reference Manual for detailed descriptions of MONITOR commands.

For example, you might consider running some programs (whose results you believe are fixed and reproducible) at the same time that you run your normal work load. If you run the programs and measure their running times under nearly identical work load conditions both before and after your adjustments, you can obtain a basis for comparison.

However, when applying this technique, remember to take the measurements under very similar work load conditions. Also, remember that this test alone does not provide conclusive proof of success. The possibility always exists that your adjustments may have favored the performance of the image you are measuring---to the detriment of other images. Therefore, in all cases, continue to observe system behavior closely for a time after you make any changes.

	privacy and legal statement
6017PRO_076.HTML