Back in 1987, I had the pleasure of attending a multiday VAX/VMS tuning seminar put on by Raxco. At that time, the lecturer, Clayton J. Prestia, presented the audience with a plethora of VMS tuning information that I didn't know was buried (hidden?) across numerous volumes of DEC's own literature.
At that time, I was a member of a team managing two VAX-11/750's and eight VAX-11/730's distributed across the Canadian province of Ontario (we were also the application developers). The 730's would really bog down whenever there were 10-12 active interactive processes.
Before my Raxco tuning operation, a pair of VAX-8550s had already been ordered which would be operated as a VAX-Cluster from a central location in Toronto which would replace the ten distributed machines just mentioned. Even though these new machines had been installed with a maximum amount of memory (80 MB which seemed huge at the time), Raxco-based tuning still improved their operation.
In 2010, I still am responsible for several VMS systems including two AS-2100 platforms, one AS-4100 platform, and two AS-DS20e platforms. I still use some of this material to tune these systems as well as educate others.
The Raxco seminar was based upon VMS-4.x for VAX in 1987 but VMS has changed for the better with each successive release. In the early 1990's, DEC developed the 64-bit Alpha processor and even though the code base for Alpha was separate from that used by VAX, bugs corrected in the Alpha version of VMS (now called OpenVMS) were back ported to VAX. In the early 2000s the 64-bit code base, which was only meant for Alpha, was adapted to generate code for 64-bit Itanium (which HP named Integrity). HP engineers have told me privately that the Alpha-to-Itanium port was the first time a new set of eyes were collectively engaged in examining/improving OpenVMS since the previous port from VAX to Alpha.
|32-bit VAX||64-bit Alpha||64-bit Itanium||x86-64|
|OpenVMS 6.x||OpenVMS 6.x|
|OpenVMS 7.x||OpenVMS 7.x|
|OpenVMS 8.x||OpenVMS 8.x|
Why does this history matter? Well, in the days of VMS 4.x electronic memory was very expensive (compared to now) which meant there was never enough available. For example, the big VAX-8550 I mentioned previously could only accept a maximum amount of 80 MB although a third party modification would allow you to increase this limit. Today, memory is cheaper and faster (DRAM -> SDRAM -> DDR -> DDR2) which means that Alpha and Itanium systems almost always have access to much more.
Because most memory in 1987 was smaller in size, the default behavior of either "VMS Tuning" (or "Raxco Tuning") involved enabling and using AWSA (automatic working set adjustment) reduction. This meant that processes not actively using memory on a busy system would be required to surrender LRU (least Recently Used) pages to the FREELIST or MODIFIED LIST. Currently faulting processes could SOFT FAULT those pages back unless the system had already reassigned the memory meaning that the SOFT FAULT would need to be converted to a HARD FAULT (involving one, or more, disk I/O's)
Poking around tuning scripts (like AUTOGEN) this side of Y2K will reveal that AWSA will be disabled by default whenever a minimum of 500 MB of memory is present. This means that many Alpha or Itanium system will almost always have AWSA Reduction disabled.
Where I disagree with RAXCO:
On June 30, 2010 I contacted RAXCO Software president Robert E. Nolan to obtain permission to make these notes freely available to the VMS Community. Permission was granted (verbally) provided the original RAXCO copyright remains in place.
On behalf of the VMS community, "thank you Robert".
Raxco sells Perfectdisk for Windows as well as Performance Suite for OpenVMS and RaxcoSupport Suite for OpenVMS so please send them some of your business.
Different vendors have slightly different meanings for the phrases "working set", "resident set", "balance set", etc. Here are a few official definitions from official OpenVMS documentation.
|Working set||The total number of a process’s pages in physical memory. It is a subset of the total number of pages allocated to a process. Also called the primary page cache.|
|Balance set||The sum of all working sets currently in physical memory.
|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
- Modified Page List
|required page is retrieved from disk (pagefile or program image)
required page is retrieved from secondary cache