Updated: 11 December 1998

OpenVMS Performance Management

Before you adjust any system parameters, you should:

• Be familiar with system tools and utilities
• Know your work load
• Develop a strategy for evaluating performance

You can observe system operation using the following tools:

• Accounting utility (ACCOUNTING)
• Audit Analysis utility (ANALYZE/AUDIT)
• Authorize utility (AUTHORIZE)
• AUTOGEN command procedure
• DCL SHOW commands
• DECamds (DIGITAL Availability Manager for Distributed Systems)
• DECevent utility (Alpha only)
• Error Log utility (ANALYZE/ERROR_LOG)
• Monitor utility (MONITOR)

On Alpha platforms, Compaq recommends using the DECevent utility instead of the Error Log utility, ANALYZE/ERROR_LOG. (You invoke the DECevent utility with the DCL command, DIAGNOSE.) You can use ANALYZE/ERROR_LOG on Alpha systems, but the DECevent utility provides more comprehensive reports.

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

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 involve 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?

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
• Application code sharing

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?

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

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

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.

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 the problem 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.
4	Did you observe the problem? Can you duplicate the problem?

1.5.2 Hardware Problem?

Hardware problems are a common source of performance complaints.

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): $ ANALYZE/ERROR_LOG/BRIEF/LOG/OUTPUT=DAILY.LOG/SINCE=YESTERDAY For more information about error logging, see the OpenVMS System Manager's Manual: 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 paging file or mailbox, is unavailable (for example, because of 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?

Always bear in mind that 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.

Generally, system performance problems are the result of poor operation, lack of understanding of the work load and its operational ramifications, lack of resources, poor application design, human error, or 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 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 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.

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:

   $ SET VOLUME/NOHIGHWATER_MARKING device-spec[:]

2. Dismount and remount the volume.

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

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 Virtual I/O Caching

Enable virtual I/O caching to reduce the number of disk I/O operations. (See Section 12.2.)

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
NETPROXY	NETPROXY.DAT
OPC$LOGFILE_NAME	Operator log files
RIGHTSLIST	RIGHTSLIST.DAT
SYS$ERRORLOG	ERRFMT log files
SYS$JOURNAL	DECdtm transaction log files
SYS$MONITOR	MONITOR log files
SYSUAF	SYSUAF.DAT
VMSMAIL_PROFILE	VMSMAIL_PROFILE.DATA

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 frequent access the HELP libraries, the directory pointed to by logical name SYS$HELP could be moved 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 computer-based instruction programs are frequently used, SYS$INSTRUCTION or DECW$CBI, or both can be moved off the system disk or made into search lists.

Similarly, if the system is often used for Bookreader documentation, DECW$BOOK can be located off the system disk, or the logical name can be implemented as a search list.

These changes should be made 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.

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 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
• Human error, such as poor application design or allowing one process to consume all available resources

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.
• Experience has shown that the most common cause of disappointment in system performance is insufficient hardware capacity.

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

1. 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.
2. If you anticipate a dramatic change in your workload, you should expect to compensate for the new workload.

Using the AUTOGEN command procedure to manage your system parameters is recommended. 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.

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

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6491PRO_001.HTML