Document revision date: 30 March 2001
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Performance Management


Previous Contents Index

1.3.3 Why Use Them?

These system utilities and tools allow you to:

1.3.4 Knowing Your Work Load

The experienced system manager can answer the following questions:

Note

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:

1.4.1 Managing the Work Load

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

1.4.2 Distributing the Work Load

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

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:

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):
 $ ANALYZE/ERROR_LOG/BRIEF/LOG/OUTPUT=DAILY.LOG/SINCE=YESTERDAY

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:

Adjusting system values will accomplish nothing in such circumstances.

Note

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:

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

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.

Note

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:

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.

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:

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:

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


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.

Note

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:

2.7.2 Tuning Suggestions

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

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:

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.

Caution

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:

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.

Note

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

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6491PRO_001.HTML