HP OpenVMS Systems Documentation

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.

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 occurs:
  • 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 expires. If no other process of equal or higher priority is ready to execute, the current process obtains 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 obtains 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:

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:

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:

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

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

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.

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:

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

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