OpenVMS System Manager's Manual
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:
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
- Performing, after installation, certain optional system management
17.2 Knowing Your Work Load
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
- 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
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
- 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.
17.4 Distributing the Work Load
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.
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.)
17.5 Understanding System Tuning
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
- 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
- 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:
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
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
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.
17.7 Evaluating Tuning Success
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
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
- How fragmented the volume is
Be sure to consider the security implications before you disable
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
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.
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
can help you decide whether installing an image is an efficient use of
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:
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
- 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
- Default DECnet for OpenVMS accounts (records included in the SYSUAF
file on the OpenVMS distribution kit)
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.