Updated: 11 December 1998 |
OpenVMS Performance Management
Previous | Contents | Index |
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. |
This test alone does not provide conclusive proof of success. There is always the possibility that your adjustments have favored the performance of the image you are measuring---to the detriment of others. |
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:
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).
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:
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 |
---|---|
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:
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:
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:
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.
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. |
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:
|
||||||||||
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.
|
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
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 case where it costs memory to minimize page faulting.
Figure 3-5 An Example of Working Set Adjustment at Work
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6491PRO_002.HTML
|