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 When to Stop Tuning

In every effort to improve system performance, there comes a point of diminishing returns. After you obtain a certain level of improvement, you can spend a great deal of time tuning the system yet achieve only marginal results.

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

Chapter 3
Memory Management Concepts

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

3.1.1 Physical Memory

Physical memory consists of three major parts according to use:

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:

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:

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

3.3 Process Swapping

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:

3.4 Initial Working Set Quotas and Limits

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:

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

AUTOGEN checks all these values and overides them 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.

However, you can set these qualifiers to defer to the user's values in the UAF record.

When a batch job runs, the values 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:

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:

3.4.5 User Programs

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

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.

This activity reduces 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.


The possibility that AWSA parameters are out of balance is so slight that you should not attempt to modify any of the key parameter values without a very thorough understanding of the entire mechanism.

3.5.2 Working Set Regions

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

3.5.3 Adjustment Period

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 a 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 Sets BORROWLIM and GROWLIM 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 results in a very large decrease in page fault rate. Conversely, as initial working set size increases, the relative benefit of increased working set size diminishes. Figure 3-3 shows that by increasing the working set size in the example from 50 to 100 pages, the page fault rate drops from 200 to 100 pf/s. In the midrange the program still benefits 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 yields little or no 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 and page fault rate. 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

If... Then...
You establish a maximum acceptable page fault rate of PFR1 For each image there is a minimum required working set size as shown at point A in Figures 3-3 and 3-4.
You determine that the minimum level of page faulting is defined by PFR2 for all images For each image there is a point (shown at point B) that is the maximum size the working set needs to reach.

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 instance where it costs memory to minimize page faulting.

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

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