HP OpenVMS Systems Documentation

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

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

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

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.

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

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:

 $ ANALYZE/ERROR_LOG/BRIEF/LOG/OUTPUT=DAILY.LOG/SINCE=YESTERDAY

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.

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

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

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.

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

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.

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.

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

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: