OpenVMS Performance Management
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
- 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
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
- 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
- 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
1.4.2 Distributing the Work Load
Distribute the work load as evenly as possible using the following
- 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
- 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
- Use the Authorize utility to define permitted login hours for each
- 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:
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
Compare these facts with your knowledge of the normal work load and
operation of your system.
Follow the procedure shown in Figure A-1 to verify the validity of
the complaint. Did you observe the problem? Can you duplicate the
The following sections describe several reasons for performance
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:
Check the operator log and error log for indications of problems with
Enter the DCL commands SHOW ERROR and ANALYZE/ERROR_LOG to help
determine if hardware is contributing to a performance problem.
Review the previous day's error log as part of your morning routine.
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
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
Check the system console for error messages.
The MWAIT condition persists after you increase the capacity of the
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
Generally, system performance problems are the result of the following:
- Poor operation
- Lack of understanding of the work load and its operational
- 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
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
If you have sufficient disk space, decompressing the libraries will
improve CPU and elapsed-time performance.
To decompress the libraries, invoke the command procedure
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
Disabling high-water marking improves performance when data is written
past the current end-of-file. The amount of improvement depends on the
- 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:
- Enter a DCL command similar to the following:
$ SET VOLUME/NOHIGHWATER_MARKING device-spec[:]
- 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:
INSTALL ADD/OPEN/SHARED/HEADER_RESIDENT filename
INSTALL CREATE/OPEN/SHARED/HEADER_RESIDENT filename
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:
System Accounting Data File
Audit server master file
Job queue database master file
Job queue database queue and journal files
Operator log files
ERRFMT log files
DECdtm transaction log files
MONITOR 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
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.
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
Before you undertake any action, you must recognize that the following
sources of performance problems cannot be resolved 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
- Poorly designed applications
- Human error, such as allowing one process to consume all available
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
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...
Modify system parameters
Use the AUTOGEN command procedure.
Change entries in the UAF
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
Run a few programs that produce fixed and reproducible results at the
same time you run your normal work load.
Measure the running times.
Adjust system values.
Run the programs again at the same time you run your normal work load
under nearly identical conditions as those in step 1.
Measure the running times under nearly identical workload conditions.
Compare the results.
Continue to observe system behavior closely for a time after you make
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