HP OpenVMS Systems Documentation

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:

This chapter explains the following concepts:

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:

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.

17.8 Choosing Performance Options

The following list of optional system management operations, normally performed after installation, often result in improved overall performance. Choose the options that are appropriate for your site. Not all options are appropriate at every site.

• Decompress system libraries---Most of the libraries shipped with the operating system are in a compressed format in order to conserve disk space. The system dynamically decompresses them whenever they are accessed, and the resulting performance slowdown is especially noticeable during link operations and when requesting online help. If you have sufficient disk space, decompressing the libraries improves both CPU and elapsed time performance. To do this, invoke the command procedure SYS$UPDATE:LIBDECOMP.COM. The decompressed object libraries use about 25 percent more disk space than when compressed; the decompressed help libraries use about 50 percent more disk space.
• Disable file system high-water marking---This security feature is set by default when a volume is initialized to guarantee that users cannot read data they have not written.
  For nonshared sequential files, the performance impact of high-water marking is minimal. However, for files of nonsequential format, high-water marking creates some overhead; the system erases the previous contents of the disk blocks allocated every time a file is created or extended.
  Disabling the feature improves system performance by a variable amount, depending on the following factors:
  • How frequently new files are created
  • For indexed and relative files, how frequently existing files are extended
  • How fragmented the volume is
  
  Be sure to consider the security implications before you disable high-water marking.
  To disable high-water marking, you can specify the /NOHIGHWATER qualifier when initializing the volume, or you can disable high-water marking with the DCL command SET VOLUME in the following format:

  SET VOLUME/NOHIGHWATER_MARKING device-name[:]

• Set file extend parameters for OpenVMS Record Management Services (RMS)---Because files extend in increments of twice the multiblock count (default 16), system defaults provide file extension of 32 blocks rounded up to the nearest multiple of the disk's cluster size. Thus, when files are created or extended, increased I/O may slow performance. The problem can be corrected by specifying larger values for file extend parameters or by setting the system parameter RMS_EXTEND_SIZE. See Section 15.5 for information about modifying system parameters. Refer to the OpenVMS System Management Utilities Reference Manual for a description of all system parameters.
  For more detailed information about establishing the file extension quantity, refer to the section on tuning in the Guide to Creating OpenVMS Modular Procedures.
• Install frequently used images---When an image is accessed concurrently by more than one process on a routine basis, install the image with the Install utility (INSTALL), specifying the /OPEN, /SHARED, and /HEADER_RESIDENT qualifiers. You will thereby ensure that all processes use the same physical copy of the image, and that the image will be activated in the most efficient way.
  Generally, an image takes about two additional physical pages when installed with the /OPEN, /HEADER_RESIDENT, and /SHARED qualifiers. The utility's LIST/FULL command shows the highest number of concurrent accesses to an image installed with the /SHARED qualifier. This information can help you decide whether installing an image is an efficient use of memory.
  See Section 17.9.11 and the INSTALL section of OpenVMS System Management Utilities Reference Manual for more information about installing images.
• On Alpha systems, install shareable and executable images specifying the /RESIDENT qualifier with the Install utility. For more information, see Section 17.9.6.
  Note that this is a tradeoff between the CPU and memory. Installing an image with /RESIDENT qualifier means that the code is to be nonpaged. Depending on the amount of sharing, this is can be a memory gain or loss.
• Reduce system disk I/O---You can move frequently accessed files off the system disk and use logical names to specify the location or, where necessary, other pointers to access them. For example:
  • SYSUAF.DAT (SYSUAF is the logical name)
  • RIGHTSLIST.DAT (RIGHTSLIST is the logical name)
  • VMSMAIL_PROFILE.DATA (VMSMAIL is the logical name)
  • NETPROXY.DAT (NETPROXY is the logical name)
  • NET$PROXY.DAT (NET$PROXY is the logical name)
  • The queue database (for more information, see Section 13.3)
  • ERRFMT log files (SYS$ERRORLOG is the logical name)
  • MONITOR log files (SYS$MONITOR is the logical name)
  • The accounting log file (ACCOUNTNG is the logical name)
  • SECURITY_AUDIT.AUDIT$JOURNAL (SET AUDIT/JOURNAL=SECURITY/DESTINATION= filespec)
  • Default DECnet for OpenVMS accounts (records included in the SYSUAF file on the OpenVMS distribution kit)
  To redefine logical names for these system files, edit the site-specific command procedure SYS$MANAGER:SYLOGICALS.COM. For more information about defining logical names in SYLOGICALS.COM, see Section 5.2.5.
  You can also consider moving paging and swapping activity off the system disk by creating large secondary page and swap files on a less heavily used disk. However, if you want to store crash dumps for diagnosing system failures, the dump file must reside in the system-specific directory SYS$SPECIFIC:[SYSEXE] on the system disk for storing crash dumps; if no dump file exists in SYS$SPECIFIC:[SYSEXE], the primary page file must be located there if you want to store crash dumps. For detailed information about moving page and swap files, see Section 16.16.