Updated: 11 December 1998

OpenVMS Performance Management

AUTOGEN has special features that allow it to make automatic adjustments for you in associated parameters. Periodically running AUTOGEN in feedback mode can ensure 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 how successful your tuning was:

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.

In every effort to improve system performance, there comes a point of diminishing returns. In other words, you will find that once you obtain a certain level of improvement, you can spend a great deal of time tuning the system beyond that point and achieve only marginal improvement.

Because a system that has been improperly adjusted usually exhibits blatant symptoms with fairly obvious and simple solutions, you will likely find that tuning---in the form of adjustments to certain critical system values---produces a high return for the time and effort invested and that there is a much lower risk of error. As a guideline, if you make adjustments and see a marked improvement, make more adjustments and see about half as much improvement, and then fail to make more than a small improvement on your next attempt or two, you should stop and evaluate the situation. In most situations, this is the point at which to stop tuning.

2.7.7.2 Still Not Satisfied?

If you are not satisfied with the final performance, consider increasing your capacity through the addition of hardware.

Generally, memory is the single piece of hardware needed to solve the problem. However, some situations warrant obtaining additional disks or more CPU power.

The operating system employs several memory management mechanisms and a memory reclamation policy to improve performance on the system. These features are enabled by default. In the majority of situations, they produce highly desirable results in optimizing system performance. However, under rare circumstances, they might contribute to performance degradation by incurring their own overhead. This chapter describes these features and provides insight into how to adjust, or even turn them off, through tuning.

3.1 Memory

Once you have taken the necessary steps to manage your work load, you can evaluate reports of performance problems. Before you proceed, however, it is imperative that you be well versed in the concepts of memory management.

On OpenVMS VAX, system parameter values are allocated in units of 512-byte pages. On OpenVMS Alpha, some system parameter values are allocated in units of pages, while others are allocated in units of pagelets. (A pagelet is equal to a VAX page, or 512 bytes.) Figure 3-1 illustrates the configuration of memory for OpenVMS systems.

Figure 3-1 OpenVMS Memory Configuration

Physical memory consists of three major parts according to use:

• Primary page cache where processes execute: the balance set resides in the primary page cache.
• Secondary page cache where data is stored for movement to and from the disks. The secondary page cache consists of two sections as follows:
  • Free-page list---Pages whose contents have not been modified
  • Modified-page list---Pages whose contents have been modified
• Operating system resident executive.

Each disk has only one access path available to transfer data from and to physical memory, that is, to perform disk I/O.

3.1.2 Virtual Memory

Virtual memory is the set of storage locations in:

• Physical memory
• Secondary storage (disk)

From the programmer's point of view, the secondary storage locations appear to be locations in physical memory.

3.1.3 Process Execution Characteristics

Processes executing on a general timesharing system use CPU time and memory in the following manner:

• A process executes in physical memory until it must wait---usually for the completion of an I/O request.
• Every time a process has to wait, another process may use the CPU.
• The operating system maintains an even balance in the use of memory, CPU time, and the number of processes running at once.
• Each time a process starts to execute, it is assigned a slice of computer processing time called a quantum. The process will continue to execute until one of three possible events happens:
  • A higher priority process becomes executable. In this case the lower priority process is preempted and the higher priority process starts to execute.
  • The process enters a wait state, for example, in order to wait for the completion of an I/O operation.
  • The assigned quantum expired. If no other process of equal or higher priority is ready to execute, the current process gets a new quantum and continues execution. If another process of equal priority is already waiting to execute, the current process must now wait and the new process gets the CPU for the duration of 1 quantum.

This round-robin mode of scheduling does not apply to real-time processes. They cannot be interrupted by other processes of equal priority.

3.2 Working Set Paging

The exchange of pages between physical memory and secondary storage is called paging. The following table lists conditions under which paging can occur:

When...	Then...
image activation begins	the process brings in the first set of pages from the image file and uses them in its own working set.
the process's demand for pages exceeds those available in the working set	some of the process's pages must be moved to the page cache to make room or the process's working set is expanded.
the page cache fills up	the swapper transfers a cluster of pages from the modified-page cache to a paging file.

A page fault occurs when a required page is not in your balance set (primary cache).

• A hard fault requires a read operation from a page or image file on disk.
• A soft fault involves mapping to a secondary page cache; this can be a global page or a page in the secondary page cache.

When a process whose working set is in memory becomes inactive, the entire working set or part of it may be removed from memory to provide space for another process's working set to be brought in for execution.

Swapping is the partial or total removal of a process's working set from memory.

3.3.1 What is the Swapper?

The swapper process schedules physical memory. It keeps track of the pages in both physical memory and on the disk paging and swapping files so it can ensure that each process has a steady supply of pages for each job.

3.3.2 Types of Swapping

A process's working set can be removed from memory using either of the following techniques:

• Swapper trimming---Pages are removed from the target working set but the working set is not swapped out.
• Process swapping---All pages are swapped out of memory.

The memory management strategy depends initially on the values in effect for the working set quota (WSQUOTA) and working set extent limit (WSEXTENT).

3.4.1 Processes

When a process is created, its quota and related limits must be specified. The LOGINOUT facility obtains the parameter settings for the quota and related limits from the record in the user authorization file (UAF) that characterizes the user. (System managers create a UAF record for each user.) LOGINOUT is run when a user logs in and when a batch process starts.

When an interactive job runs, the values in effect might have been lowered or raised either by the corresponding qualifiers on the last SET WORKING_SET command to affect them, or by the system service $ADJWSL.

The initial size of a process's working set is defined (in pagelets) by the process's working set default quota WSDEFAULT.

When ample memory is available, a process's working set upper growth limit can be expanded to its working set extent, WSEXTENT.

3.4.2 Subprocesses and Detached Processes

Subprocesses and detached processes derive their working set characteristics from one of the following:

• $CREPRC system service
• DCL command RUN

If characteristics are not specified by either of the above, then the values of the corresponding process quota and creation limit (PQL) system parameters are used as shown in the following table:

Parameter	Characteristic
PQL_DWSDEFAULT	Default WSDEFAULT
PQL_DWSQUOTA	Default WSQUOTA
PQL_DWSEXTENT	Default WSEXTENT
PQL_MWSDEFAULT	Minimum WSDEFAULT
PQL_MWSQUOTA	Minimum WSQUOTA
PQL_MWSEXTENT	Minimum WSEXTENT

All these values are checked by AUTOGEN and will be overridden by AUTOGEN if the values in the UAF are too large or too small.

PQL parameters are described in the OpenVMS System Management Utilities Reference Manual.

3.4.3 Batch Queues

When a batch queue is created, the DCL command INITIALIZE/QUEUE establishes the default values for jobs with the /WSDEFAULT, /WSQUOTA, and /WSEXTENT qualifiers.

These qualifiers can, however, be set to defer to the user's values in the UAF record.

When a batch job runs, the values in effect may have been lowered by the corresponding qualifiers on the DCL commands SUBMIT or SET QUEUE/ENTRY.

3.4.4 Required Memory Resources

On Alpha, for processing that involves system components, the following working set limits are suggested:

• Small (Up to 200 pages) --- For editing, and for compiling and linking small programs (typical interactive processing)
• Large (400 or more pages) --- For compiling and linking large programs, and for executing programs that manipulate large amounts of data in memory (typical batch processing)

Note that the definitions of "small" and "large" working sets change with time, and the memory required may increase with the addition of new features to programs. Furthermore, many applications now take advantage of the increased memory capacity of newer Alpha systems and the increased addressing space available to programs. Applications, especially database and other data handling programs, may need much larger working sets than similar applications required in the past.

On VAX, for processing that involves system components, the following working set limits are suggested:

• Small (256 to 800 pages) --- For editing, and for compiling and linking small programs (typical interactive processing)
• Large (1024 pages or more) --- For compiling and linking large programs, and for executing programs that manipulate large amounts of data in memory (typical batch processing)

Working set limits for user programs depend on the code-to-data ratio of the program and on the amount of data in the program.

Programs that manipulate mostly code and that include only small or moderate amounts of data or use RMS to process data on a per-record basis require only a small working set.

Programs that manipulate mostly data such as sort procedures, compilers, linkers, assemblers, and librarians require a large working set.

3.4.6 Guidelines

The following guidelines are suggested for initial working set characteristics:

• System parameters---Set WSMAX at the highest number of pages required by any program.
• UAF options
  • Set WSDEFAULT at the median number of pages required by a program that the user will run interactively.
  • Set WSQUOTA at the largest number of pages required by a program that the user will run interactively.
  • Set WSEXTENT at the largest number of pages you anticipate the process will need. Be as realistic as possible in your estimate.
• Batch queues for user-submitted jobs
  • Set WSDEFAULT at the median number of pages required.
  • Set WSQUOTA to the number of pages that will allow the jobs to complete within a reasonable amount of time.
  • Set WSEXTENT (using the DCL command INITIALIZE/QUEUE or START/QUEUE) to the largest number of pages required.

This arrangement effectively forces users to submit large jobs for batch processing because otherwise, the jobs will not run efficiently. To further restrict the user who attempts to run a large job interactively, you can impose CPU time limits in the UAF.

3.5 Automatic Working Set Adjustment (AWSA)

The automatic working set adjustment (AWSA) feature allows processes to acquire additional working set space (physical memory) under control of the operating system.

The goal of this activity is to reduce the amount of page faulting.

By reviewing the need for each process to add some pages to its working set limit (based on the amount of page faulting), the operating system can better balance the working set space allocation among processes.

3.5.1 What are AWSA Parameters?

The AWSA mechanism depends heavily on the values of the key system parameters: PFRATH, PFRATL, WSINC, WSDEC, QUANTUM, AWSTIME, AWSMIN, GROWLIM, and BORROWLIM.

Normally, the default values that the system provides for these parameters correctly match the operational needs.

All processes have an initial default limit of pages of physical memory defined by the system parameter WSDEFAULT.

Any process that needs more memory is allowed to expand to the amount of a larger limit known as the working set quota defined by WSQUOTA.

Because page faulting is costly, the operating system has another feature for extending working set space to needy processes, provided the system has free memory available. If the conditions are right, the process can borrow working set space up to a final limit known as its working set extent, or WSEXTENT.

Whenever a process's working set size increases, the growth occurs in increments according to the value of the system parameter, WSINC.

Figure 3-2 illustrates these important regions.

Figure 3-2 Working Set Regions for a Process

The system recognizes or reviews the need for growth by sampling the page faulting rate of each process over an adjustment period. The adjustment period is the time from the start of the quantum (defined by the system parameter QUANTUM) right after an adjustment occurs until the next quantum after a time interval specified by the parameter AWSTIME elapses. For example, if the system quantum is 200 milliseconds and AWSTIME is 700 milliseconds, the system reviews the need to add or subtract pages from a process every time the process consumes 800 milliseconds of CPU time, or every fourth quantum.

3.5.4 How does AWSA Work?

The following table summarizes how AWSA works:

Stage	Description
1	The system samples the page faulting rate of each process during the adjustment period.
2	The system parameters PFRATL and PFRATH define the upper and lower limits of acceptable page faulting for all processes. At the end of each process's adjustment period, the system reviews the need for growth and does the following: If the page fault rate is... Then the system... too high compared with PFRATH approves an increase in the working set size of that process in the amount of system parameter WSINC up to the value of its WSQUOTA. too low compared with PFRATL (when PFRATL is nonzero) approves an decrease in the working set size of that process in the amount of system parameter WSDEC. No process will be reduced below the size defined by AWSMIN. This process is called voluntary decrementing.
3	If the increase in working set size puts the process above the value of WSQUOTA and thus requires a loan, the system compares the availability of free memory with the value of BORROWLIM. The AWSA feature allows a process to grow above its WSQUOTA value only if there are at least as many pages of free memory as specified by BORROWLIM. If too many processes attempt to add pages at once, an additional mechanism is needed to stop the growth while it is occurring. However, the system only stops the growth of processes that have already had the benefit of growing beyond their quota. If... Then the system... a process page faults after its working set count exceeds WSQUOTA examines the value of the parameter GROWLIM before it allows the process to use more of its WSINC loan. Note that this activity is not tied into an adjustment period but is an event-driven occurrence based on page faulting. the number of pages on the free-page list is at least equal to or greater than GROWLIM continues to allow the process to add pages to its working set. the number of free pages is less than GROWLIM will not allow the process to grow; the process must give back some of its pages before it reads in new pages. active memory reclamation is enabled both BORROWLIM and GROWLIM are set to very small values to allow active processes maximum growth potential.

3.5.5 Page Fault Rates

Page fault rate varies as a function of the working set size for a program. For initial working set sizes that are small relative to the demands of the program, a small increase in working set size will result in a very large decrease in page fault rate. Conversely, as initial working set size increases, the relative benefit of increased working set size will diminish. Figure 3-3 shows this: by increasing the working set size in the example from 50 to 100 pages, the page fault rate will drop from 200 to 100 pf/s. In the midrange the program will still benefit from an increase in its working set, but in this realm twice the increase in the working set (100 to 200 pages versus 50 to 100 pages) yields only half the decrease in page fault rate (100 to 50 pf/s versus 200 to 100 pf/s). A point may be reached at which further substantial increases in working set size will yield no or little appreciable benefit.

Figure 3-3 Effect of Working Set Size on Page Fault Rate

Figure 3-3 illustrates a general relationship between Working Set Size. The numbers provided are for comparison only. Not all programs exhibit the same curve depicted. Three different ranges are delineated to show that the effect of increasing working set size can vary greatly depending upon a program's requirements and initial working set size.

Figure 3-4 illustrates setting minimum and maximum page fault rates and determining the required working set size for images running on your system.

Figure 3-4 Setting Minimum and Maximum Page Fault Rates

Figure 3-5 illustrates how automatic working set adjustment works over time, across the whole system, to minimize the amount of page faulting by adjusting working set sizes in balance with the amount of free memory available. The units used for AWSTIME, WSDEC, and WSINC in Figure 3-5 are for illustration; they are not recommendations.

In the figure, the shaded area identifies where paging occurs. The portion between the desired working set size and the actual working set limit (shown with cross-hatching) represents unnecessary memory overhead---an obvious case where it costs memory to minimize page faulting.

Figure 3-5 An Example of Working Set Adjustment at Work

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

6491PRO_002.HTML