A simplified approach to OpenVMS tuning
This report was prepared by Touch Technologies, Inc., as a service to the VAX community.
This copyrighted document may be reproduced without formal consent from Touch Technologies, Inc., provided that each copy includes the copyright page in its entirety.
Touch Technologies, Inc. (TTI) has prepared this publication for use by TTI personnel, licensees, and customers. This information is protected by copyright. No part of this document may be photocopied, reproduced or translated to another language without prior written consent of Touch Technologies Incorporated.
TTI believes the information described in this publication is accurate and reliable; much care has been taken in its preparation. However, no responsibility, financial or otherwise, is accepted for any consequences arising out of the use of this material.
The information contained herein is subject to change without notice and should not be construed as a commitment by Touch Technologies, Inc.
The following are trademarks of Touch Technologies, Inc., and may be used only to describe products of Touch Technologies, Inc.:
DYNAMIC LOAD BALANCER DYNAMIC TAPE ACCELERATOR INTOUCH I/O PLUS REMOTE TAPE FACILITY FRAGMENTATION CONTROLLER
The following are trademarks of Digital Equipment Corporation, and may be used only to describe products of Digital Equipment Corporation:
DBMS DCL DECNET RDB RMS VAX VMS
Revised 27-Apr-1992
There comes a time in the life of every OpenVMS system when the system must be tuned. Much myth and lore has been handed down from manager to manager on tuning OpenVMS. This guide will replace those myths with facts, facts acquired through the tuning of countless OpenVMS systems.
The purpose of this guide is to provide:
This guide is intended for use by the system manager or other technical personnel. The reader is expected to be familiar with the OpenVMS SYSGEN utility and the OpenVMS AUTHORIZE utility.
Note
It is because of the heavy demand for Touch Technologies, Inc.'s Dynamic Load Balancer software and the requests for further information on OpenVMS tuning from VAX users that TTI has decided to write and produce this OpenVMS Tuning Guide.
The purpose of tuning a system is to get maximum benefit from existing hardware.
If at times your system is sluggish, it most likely needs to be tuned. On a well- tuned system, response time is smooth and consistent. Even a system that is not yet sluggish can benefit from tuning. In this case, tuning is performed as a kind of response time insurance.
When manually tuning your system, it is necessary to step back and work out a solid plan of attack. With a good tuning strategy, your tuning efforts are more likely to be successful.
The purpose of this guide is to help VAX managers develop guidelines for reviewing some of the more important system statistics and adjusting key SYSGEN parameters.
Automatically tuning Dynamic parameters should be considered. Dynamic tuning is the process of tuning the system every few seconds. This rapid rate of tuning is performed by specialized dynamic tuning software. Automatic tuning can respond faster and can quickly consider more significant factors to ensure optimum system performance.
Note
The Dynamic Load Balancer (DLB) tunes the system as often as every six (6) seconds. The tuning involves sampling the system, changing SYSGEN and PROCESS parameters based on the sample, waiting a few moments, and then sampling the system again. This tuning cycle is performed continuously, 24 hours a day, seven days a week. Overall throughput increases of over 25% are typical when using DLB.
Before any tuning is attempted, the system must be given an examination. In the case of VMS, the DCL command SHOW MEMORY provides a wealth of information. This information will, in most cases, pinpoint major parameters that need changing.
2.2 UNDERSTANDING VMS'S WORRIES
Because of the way that the OpenVMS operating system is designed, it worries when it starts running out of a resource. Worrying begins when the "free" level for memory resources goes below certain thresholds.
Although the resources may be far from exhausted, the system will act as if it was very concerned about losing the amount it does have. In some cases, OpenVMS will limit processes and/or spend inordinate amounts of time trying to increase the free level of the resource. This is done even to the detriment of overall system throughput.
VMS's worries can be calmed by increasing the setting of a parameter that appears NOT to need such an increase. In fact, when some settings are increased enough, it can be seen that OpenVMS will suddenly find a use for the additional resources. This use will occur although it previously seemed to have more than enough.
The above leads to a practical tuning principle, which may be stated as follows:
The following recommendations are based on tuning experiences with dozens of OpenVMS systems. Use them as guidelines and remember to experiment with variations if possible.
2.3 PROCESS ENTRY SLOTS AND BALANCE SET SLOTS.
The number of process entry slots is the same as the maximum number of processes allowed in the system at any time. The main factors in determining this limit are the CPU class, physical memory, type or workload expected. Another factor is any political guidelines used to restrict the number of processes.
The number of balance set slots is the number of processes allowed in physical memory at any given time. A low balance set count will result in physical memory being consistently unused, regardless of how many active processes may need it.
Note
If you notice processes in a swapped-out state, then most likely your BALSETCNT is too low. Increase BALSETCNT by 10%. (Except when using the OpenVMS 5.4-3 memory reclamation system. The OpenVMS memory reclamation system encourages idle process to swap.)
The balance set count must always be at least two less than the number of process entry slots to allow room for the swapper and the null process.
These are linked lists of memory packets used to speed up the processing of requests for dynamic memory. There are three separate lists according to the request packet size: small (SRP), I/O (IRP), and large (LRP).
The packet size used for each list, and the list lengths, is determined by system parameters. OpenVMS uses the request packet lists as look aside lists. When a request for memory cannot be satisfied from any of the lists, non-paged dynamic memory is used.
The total number of packets of a given type is calculated based on VMS's consumption of packets. When the number of packets gets low, VMS stops using the packets and starts using non-paged dynamic memory. Allocating space from non-paged dynamic memory is much slower than simply choosing a packet from the linked list.
Note
You should always have available packets. Failure to have packets available will slow down your system.
In order to insure that enough packets are available, raise the values of the following SYSGEN parameters. Raise the values until, during peak times, the FREE LEVELS shown below are reached.
| Request Packet List | SYSGEN Parameter | Free Level |
|---|---|---|
| Small (SRP) | SRPCOUNT, SRPCOUNTV | 100 |
| I/O (IRP) | IRPCOUNT, IRPCOUNTV | 50 |
| Large (LRP) | LRPCOUNT, LRPCOUNTV | 25 |
Non-paged Dynamic memory is used primarily by OpenVMS system routines and device drivers. Paged Dynamic memory is used by many VMS facilities---most notably, the ACP caching system.
PAGEDYN may not be large enough to accomodate the ACP caches. In this case, the ACP caching will be effectively turned off by OpenVMS without any warning or indication other than decreased system performance.
In order to insure that enough dynamic memory is available so that VMS won't need to worry, raise the values of the following SYSGEN parameters. Raise the values until, during peak times, the FREE LEVELS shown below are reached.
| SYSGEN parameter | Free Level |
|---|---|
| NPAGEDYN | 150,000 bytes |
| PAGEDYN | 150,000 bytes |
PAGE files are where modified pages are written. If the Modified List is full, the pages are written to disk but not back to the application, because that page has been changed. The page is moved to PAGE FILE on disk and when the process needs that page again, it goes to PAGEFILE instead of to the application. The PAGE files are a critical resource on your system. If you run low on PAGE file space, OpenVMS panics and puts processes into resource wait states. This will slow down, or even deadlock your system.
PAGE file space is allocated dynamically, based on the virtual size of each process's writeable address space. PAGE file space is also used by RMS for global buffering of files.
When a process is created, OpenVMS decides which page file it will use. This decision is based on which page file AT THAT MOMENT has the most free space. If later on that page file becomes full, VMS will put EVERY PROCESS using that PAGE file into a resource wait state.
Because page file space is allocated dynamically, it is important that it not get fragmented. A badly fragmented page file will slow down those processes that use the page file.
Note
PAGE files that are full or nearly full tend to become badly fragmented. Make sure that during peak times EACH page file has at least 25% of its total size in pages free. Failure to have a large enough PAGE file will cause processes to go into a resource wait state. This will slow down the entire system.
The free list size is simply the number of physical pages available to processes in the system. The modified page list contains modifiable pages that have been faulted out of a working set. These modified pages will probably be written to the page file at some point. How often these pages are actually written to the page file is determined by two factors:
VMS begins writing modified pages to disk when this limit is reached.
The DEC default is 4 percent of total physical memory. For optimum system
performance, MPW_HILIMIT should be set to 15 percent of the total
physical memory. This large setting will reduce PAGED I/O activity
at the expense of some physical memory.
2.7.2 MPW_LOWAITLIMIT
When writing pages from the modified page list to page files,
VMS stops writing modified pages when the list reaches MPW_LOWAITLIMIT.
In order to reduce constant writing of modified pages to page files,
MPW_LOWAITLIMIT should be set to one-half of MPW_HILIMIT.
2.7.3 MPW_THRESH
VMS will flush the modified page list if the FREE LIST becomes near empty and the modified list contains MPW_THRESH pages. To avoid flushing the modified page list, set this parameter to MPW_HILIMIT.
The value of QUANTUM is in 10ms units. The default quantum value is 20...or 1/5 second. Quantum is the amount of time that a process gets to run before giving up the CPU to another process. A tuning goal is to adjust the value of quantum, giving each process just enough CPU time to complete its work, before doing an I/O.
When changing the value of QUANTUM, you must also consider changing AWSTIME and PIXSCAN. These two parameters do work based on QUANTUM.
Ideally, a process on the system would keep track of the average time between I/O's. It would adjust QUANTUM, PIXSCAN, and AWSTIME values dynamically based on these observations. Without such a process, values must be chosen based on experience, assuming a typical workload. A crude way to approximate the optimal value for QUANTUM is to quickly type several control-T's. Then use the observed elapsed CPU time between each one.
Note
The Dynamic Load Balancer calculates the average quantum required by a process to complete an I/O without having to be rescheduled. This average is updated every few seconds. The parameters IOTA, AWSTIME, and PIXSCAN are also adjusted by DLB.
It is important to note the difference between the WORKING SET and the WORKING SET LIST.
The WORKING SET LIST (WSL) is made up of pointers to each page in the working set (WS). The size of each working set is therefore limited by the number of pointers in the list.
VMS grants physical memory to a process by increasing the size of the WSL, but it is then up to the process to make use of the extra memory. The memory is used when the process faults pages into the process working set.
3.3 AUTOMATIC WORKING SET SIZE ADJUSTMENT
Working set list adjustment is controlled by the following system parameters:
| Parameter | Description |
|---|---|
| AWSTIME | CPU time to be reached before AWS can occur |
| WSINC | number of WSL entries added by AWS |
| WSDEC | number of WSL entries removed by AWS |
| PFRATH | page fault tolerance rate |
| PFRATL | page fault encouragement rate |
The following parameter values are recommended to keep AWS overhead at a reasonable minimum:
| Parameter | Recommend Value |
|---|---|
| AWSTIME | 60 or more |
| WSINC | 503 |
| WSDEC | 19 |
| PFRATH | 10 |
| PFRATL | 1 |
Note
The Dynamic Load Balancer does not rely on the OpenVMS automatic working set adjustment mechanism to adjust process memory allocation. WHEN INSTALLING DLB, BE SURE TO USE THE SYSGEN PARAMETER VALUES GIVEN IN THE DLB INSTALLATION GUIDE.The Dynamic Load Balancer works by keeping a history on the memory needs and page fault behavior of each process. This history is used to determine which processes need more memory pages and which processes have unused memory pages. Unused pages of memory are taken from memory rich processes and given to memory poor processes. This technique decreases both hard and soft page faults, resulting in better overall system performance. In addition, the reduction of hard page faults decreases I/O activity... helping systems that are I/O bound.
Prior to May, 1987, the only way to tune a OpenVMS system (or for that matter ANY system) was through the time-consuming process of manual tuning. The general steps taken for successful manual tuning are:
Manual tuning has three major problems.
In May, 1987, Touch Technologies, Inc. developed the technology for dynamically tuning operating systems. The technology has been first implemented on DEC OpenVMS based systems. The steps for dynamic tuning are:
The dynamic tuning software uses a goal-oriented algorithm. The goal is optimum performance NOW. At every time interval, the software checks critical system metrics. If the metrics show non-optimal system performance, appropriate dynamic system parameters are adjusted to compensate.
In addition, a complete history is kept of system and process
level metrics and system parameter changes. A history of
their effects on system performance is also kept. This
feedback technology is the key to effective dynamic tuning.
4.2.1 DYNAMIC TUNING ADVANTAGES
Dynamic tuning has many advantages over traditional manual tuning. These advantages are: