HP OpenVMS Systems Documentation
OpenVMS Performance Management
22.214.171.124 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.
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.
|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.|
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
3.3.2 Types of Swapping
The memory management strategy depends initially on the values in
effect for the working set quota (WSQUOTA) and working set extent limit
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.
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
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
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:
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
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)
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?
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.
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:
|1||The system samples the page faulting rate of each process during the adjustment period.|
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 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.
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
|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