HP OpenVMS Systems Documentation

Content starts here

OpenVMS Performance Management

Previous Contents Index

1.3.3 Why Use Them?

These system utilities and tools allow you to:

  • Collect and analyze key data items.
  • Observe usage trends.
  • Predict when your system reaches its capacity.
  • Adjust system parameters.
  • Modify users' privileges and quotas.

1.3.4 Knowing Your Work Load

The experienced system manager can answer the following questions:

  • What is the typical number of users on the system at each time of day?
  • What is the typical response time for various tasks for this number of users, at each 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? of memory? of disk?
  • Which applications have the most image activations?
  • Which parts of the system software, if any, have been modified or user written, such as device drivers?
  • Are there any known system bottlenecks? Are there any anticipated ones?


If you are a novice system manager, you should spend a considerable amount of time observing system operation using the DCL commands ACCOUNTING, MONITOR, and SHOW.

1.4 Developing a Strategy

Each installation site must develop its own strategy for optimizing system performance. Such a strategy requires knowledge about system use in the following areas:

  • Managing the work load
  • Distributing the work load
  • Sharing application code

1.4.1 Managing the Work Load

Before you attempt to adjust any system values, always ask yourself the following questions:

  • Is there a time of day when the work load peaks, that is, when it is noticeably heavier than at other times?
  • Is there any way to balance the work load better? Perhaps measures can be adopted by users.
  • Could any jobs be run better as batch jobs, preferably during nonpeak hours?
  • Have primary and secondary hours of operation been employed with users? Are the choices of hours the most appropriate for all users?
  • Can future applications be designed to work around any known or expected system bottlenecks? Can present applications be redesigned for the same purpose?
  • Are you using all of the code-sharing features that the OpenVMS system offers you?


    Do not adjust any system values until you are satisfied that all these issues are resolved and that your workload management strategy is appropriate.

1.4.2 Distributing the Work Load

Distribute the work load as evenly as possible using the following techniques:

  • 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.
    • Use DCL command qualifiers to run batch jobs at lower priority, adjust the working set sizes, and control the number of concurrent jobs.

    For more information, see the OpenVMS System Manager's Manual, Volume 1: Essentials.
  • Restrict system use.
    • Do not permit more users to log in at one time than the system can support with adequate response time.
    • Restrict the number of interactive users with the DCL command SET LOGINS/INTERACTIVE.
    • Control the number of conconcurrent processes with the MAXPROCESSCNT system parameter.
    • Control the number of remote terminals allowed to access the system at one time with the RJOBLIM system parameter.
    • Restrict system use to groups of users to certain days and hours of the day.
      • Use the Authorize utility to define permitted login hours for each user.
      • Use the DCL command SET DAY to override the conventional day-of-the-week associations for primary and secondary days.
  • Design applications to reduce demand on binding resources.
    • Find out where system bottlenecks are located.
    • Plan use that minimizes demands on the bottleneck points.

1.4.3 Sharing Application Code

Application code sharing provides a cost-effective means of optimizing memory utilization. To ensure optimum performance of your system, make sure that frequently used code is shared.

Use the site-specific startup procedure to install as shared known images user-written programs and routines that are designed for sharing and have reached production status or are in general use.

Encourage programmers to write shareable code.

1.5 Analyzing Complaints

Typically, an investigation into system performance begins when you receive a complaint about a slowdown of interactive response times or about some other symptom of decreased throughput. Before you decide that the current complaint reflects a performance problem, you should:

  • Ensure that hardware resources are adequate.
  • Know the work load reasonably well.
  • Have experience managing the work load according to the guidelines in Section 1.3.4.

1.5.1 Preliminary Steps

To analyze the complaint, you will need some additional information as described in the following table:

Step Action
1 Obtain the following information:
  • Number of users on the system at the time theproblem occurred
  • Number of jobs on the system
  • Response times
  • Evidence of jobs hanging and unable to complete
2 Compare these facts with your knowledge of the normal work load and operation of your system.
3 Follow the procedure shown in Figure A-1 to verify the validity of the complaint. Did you observe the problem? Can you duplicate the problem?

The following sections describe several reasons for performance problems.

1.5.2 Hardware Problem

Hardware problems are a common source of performance complaints. To determine if you have a hardware problem, do the following:

Step Action
1 Check the operator log and error log for indications of problems with specific devices.
2 Enter the DCL commands SHOW ERROR and ANALYZE/ERROR_LOG to help determine if hardware is contributing to a performance problem.
3 Review the previous day's error log as part of your morning routine.
4 Obtain a count of errors logged since yesterday. Use the following DCL command (which requires SYSPRV privilege):

For more information about error logging, see the OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems; for information about using the Analyze/Error_Log utility, refer to the OpenVMS System Management Utilities Reference Manual: A--L.

1.5.3 Blocked Process

A process enters the miscellaneous resource wait (MWAIT or RWAST) state usually because some resource, such as a paging file or mailbox, is unavailable (for example, because of a low quota or a program bug).

To identify processes in the MWAIT state, use the DCL command MONITOR STATES.

If... Then...
A process is in the MWAIT state Use the DCL commands MONITOR PROCESSES and SHOW SYSTEM to identify the reason for the MWAIT state.
The system fails to respond while you are investigating an MWAIT condition Check the system console for error messages.
The MWAIT condition persists after you increase the capacity of the appropriate resource Investigate the possibility of a programming design error.

1.5.4 Unrealistic Expectations

What appears at first to be a performance problem can turn out to be a case of unrealistic expectations. For example:

  • Users expect response times to remain constant, even as the system work load increases.
  • An unusual set of circumstances has caused exceptionally high demand on the system all at once.

Adjusting system values will accomplish nothing in such circumstances.


Whenever you anticipate a temporary workload change that will affect your users, notify them through broadcasts, text, or both, in the system notices.

Chapter 2
Performance Options

Generally, system performance problems are the result of the following:

  • Poor operation
  • Lack of understanding of the work load and its operational ramifications
  • Lack of resources
  • Poor application design
  • Human error
  • A combination of these factors

System management operations, normally performed after installation, often result in improved overall performance. This chapter discusses the following topics:

  • Decompressing system libraries
  • Disabling file system high-water marking
  • Setting RMS file-extend parameters
  • Installing frequently used images
  • Enabling virtual I/O or extended file caching
  • Reducing system disk I/O
  • Tuning

Note that not all the options discussed in this chapter are appropriate at every site.

2.1 Decompressing System Libraries

Most of the OpenVMS libraries are in compressed format in order to conserve disk space.

The CPU dynamically decompresses the libraries whenever they are accessed. However, the resulting performance slowdown is especially noticeable during link operations and when users are requesting online help.

If you have sufficient disk space, decompressing the libraries will improve CPU and elapsed-time performance.

To decompress the libraries, invoke the command procedure SYS$UPDATE:LIBDECOMP.COM.


Decompressed object libraries take up about 25 percent more disk space than when compressed; the decompressed help libraries take up about 50 percent more disk space.

2.2 Disabling File System High-Water Marking

High-water marking is set by default whenever a volume is initialized. This security feature guarantees that users cannot read data they have not written.

Disabling high-water marking improves performance when data is written past the current end-of-file. The amount of improvement depends on the following considerations:

  • How often new files are created
  • How often existing files are extended
  • How fragmented the volume is

To disable high-water marking, specify the /NOHIGHWATER_MARKING qualifier when initializing the volume, or do the following at any time:

  1. Enter a DCL command similar to the following:

  2. Dismount and remount the volume.

2.3 Setting RMS File-Extend Parameters

Because files extend in increments of twice the multiblock count (default is 16), system defaults now provide file extensions of only 32 blocks. Thus, when files are created or extended, increased I/O can slow performance. The problem can be overcome by:

  • Specifying larger values for system file-extend parameters
  • Setting the system parameter RMS_EXTEND_SIZE
  • Specifying a larger multiblock count
  • Specifying a larger multibuffer count

2.4 Installing Frequently Used Images

When an image is used 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 ensure that:

  • All processes use the same physical copy of the image.
  • The image will be activated in the most efficient way.

You may use either of the following commands:


ADD and CREATE are synonyms. The /SHARED and /HEADER_RESIDENT qualifiers imply the image is open. The /OPEN qualifier indicates the file is a permanently known image to the system.

2.5 Enabling File Caching

Enable virtual I/O or extended file caching to reduce the number of disk I/O operations. (See Section 12.2 and the OpenVMS System Manager's Manual.)

2.6 Reducing System Disk I/O

Remove frequently accessed files from the system disk and use logical names, or where necessary, use other pointers to access them as shown in the following table:

Logical Name File
ACCOUNTING System Accounting Data File
AUDIT_SERVER Audit server master file
QMAN$MASTER Job queue database master file 1
Directory specification 2 Job queue database queue and journal files
OPC$LOGFILE_NAME Operator log files
SYS$JOURNAL DECdtm transaction log files

1Mount the disk on which it resides in SYLOGICALS.
2When used with the DCL command START/QUEUE/MANAGER.

In addition, the default DECNET account can reside on another disk. Refer to the DECNET record in the system authorization file.

You might consider moving paging and swapping activity off the system disk by creating large secondary page and swap files on a less heavily used disk.

In an educational or learning environment, there are several other files you might want to move off the system disk. If many users will frequently access the help libraries, you could move the directory pointed to by logical name SYS$HELP to another disk. However, the system installation and upgrade procedures assume SYS$HELP is on the system disk. If you move SYS$HELP to another disk, you will have to update it manually after a system upgrade.

If users frequently use computer-based instruction programs, you can move SYS$INSTRUCTION or DECW$CBI (or both) off the system disk, or make them into search lists.

Make these changes only if you have determined that the files in these directories are frequently used on your system.

2.7 Tuning

Tuning is the process of altering various system values to obtain the optimum overall performance possible from any given configuration and work load.

You will rarely need to make major adjustments to system parameters.


When you have optimized your current system, the acquisition and installation of additional memory or devices can vastly improve system operation and performance.

Always aim for best overall performance, that is, performance viewed over time. The work load is constantly changing on most systems. Therefore, what guarantees optimal workload performance at one time might not produce optimal performance a short time later as the work load changes.

2.7.1 Prerequisites

Before you undertake any action, you must recognize that the following sources of performance problems cannot be resolved 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
  • Poorly designed applications
  • Human error, such as allowing one process to consume all available resources

2.7.2 Tuning Suggestions

Tuning is rarely required for OpenVMS systems for the following reasons:

  • The effort required is often more expensive than a capacity upgrade.
  • The system includes AUTOGEN, which automatically establishes initial values for all system-dependent system parameters.
  • The system includes features that in a limited way permit it to adjust itself dynamically during operation. The system can detect the need for adjustment in the following areas:
    • Nonpaged dynamic pool
    • Working set size
    • Number of pages on the free- and modified-page lists

As a result, these areas can grow dynamically, as appropriate, during normal operation. For more information on automatic adjustment features, see Section 3.5. The most common cause of poor system performance is insufficient hardware capacity.

Although tuning is rarely required, it is appropriate in response to two particular situations:

  • 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 workload, you should expect to compensate for the new workload.

2.7.3 Tools and Utilities

Use the AUTOGEN command procedure to manage your system parameters. If you modify a system parameter using AUTOGEN, AUTOGEN makes automatic adjustments in associated parameters. See the OpenVMS System Manager's Manual for a detailed description of the AUTOGEN command procedure.


Do not directly modify system parameters using SYSGEN. AUTOGEN overrides system parameters set with SYSGEN, which can cause a setting to be lost months or years after it was made.

Use AUTHORIZE to change user account information, quotas, and privileges.

2.7.4 When to Use AUTOGEN

Run AUTOGEN in the following circumstances:

  • During a new installation or upgrade
  • Whenever your work load changes significantly
  • When you add an optional (layered) software product
  • When you install images with the /SHARED qualifier
  • On a regular basis to monitor changes in your system's work load
  • When you adjust system parameters

AUTOGEN will not fix a resource limitation.

2.7.5 Adjusting System Parameter Values

When it becomes necessary to make adjustments, you normally select a very small number of values for change, based on a careful analysis of the behavior observed. These values are usually either system parameters or entries in the user authorization file (UAF).
If you want to... Then...
Modify system parameters Use the AUTOGEN command procedure.
Change entries in the UAF Use AUTHORIZE.

2.7.6 Using AUTOGEN Feedback

AUTOGEN has special features that allow it to make automatic adjustments for you in associated parameters. Periodically running AUTOGEN in feedback mode ensures that the system is optimally tuned.

The operating system keeps track of resource shortages in subsystems where resource expansion occurs. AUTOGEN in feedback mode uses this data to perform tuning.

2.7.7 Evaluating Tuning Success

Whenever you make adjustments to your system, you must spend time monitoring its behavior afterward to ensure that you obtain the desired results. Use the following procedure to evaluate the success of your tuning:

Step Action
1 Run a few programs that produce fixed and reproducible results at the same time you run your normal work load.
2 Measure the running times.
3 Adjust system values.
4 Run the programs again at the same time you run your normal work load under nearly identical conditions as those in step 1.
5 Measure the running times under nearly identical workload conditions.
6 Compare the results.
7 Continue to observe system behavior closely for a time after you make any changes.


This test alone does not provide conclusive proof of success. There is always the possibility that your adjustments have favored the performance of the image you are measuring---to the detriment of others.

Previous Next Contents Index