|
HP OpenVMS Systemsask the wizard |
|
The Question is:
I recently took over as the new Alpha Operator, and I’m trying to find
out how to optimize the performance of this machine. This machine is used at a
community college, and during registration time, we experience a slow response
time.
When I took a quick look at the system memory resources, this is what I saw:
System Memory Resources on 18-AUG-2003 13:20:17.00
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (512.00Mb) 65536 4913 45783 14840
Virtual I/O Cache
Total Size (Kbytes) 3200 Read IO Count 1159165
Free Kbytes 0 Read Hit Count 166005
Kbytes in Use 3200 Read Hit Rate 14%
Write IO Bypassing Cache 10442 Write IO Count 70128
Files Retained 99 Read IO Bypassing Cache 350153
Granularity Hint Regions (pages): Total Free In Use Released
Execlet code region 512 0 498 14
Execlet data region 128 2 94 32
S0/S1 Executive data region 374 0 374 0
S2 Executive data region 320 0 320 0
Resident image code region 1024 0 822 202
Slot Usage (slots): Total Free Resident Swapped
Process Entry Slots 346 218 128 0
Balance Set Slots 344 218 126 0
Nonpaged Dynamic Memory (Lists + Variable)
Current Size (bytes) 6479872 Current Size (pagelets) 12656
Initial Size 3006464 Initial Size (pagelets) 5872
Maximum Size 15032320 Maximum Size (pagelets) 29360
Free Space (bytes) 956928 Space in Use (bytes) 5522944
Largest Variable Block 165888 Smallest Variable Block 64
Number of Free Blocks 2944 Free Blocks LEQU 64 Bytes 376
Free Blocks on Lookasides 1225 Lookaside Space (bytes) 348928
(Bus Addressable Memory requests use Nonpaged Dynamic Memory)
Paged Dynamic Memory
Current Size (PAGEDYN) 3170304 Current Size (pagelets) 6192
Free Space (bytes) 1611136 Space in Use (bytes) 1559168
Largest Variable Block 1590832 Smallest Variable Block 16
Number of Free Blocks 292 Free Blocks LEQU 64 Bytes 242
Buffer Object Usage (pages): In Use Peak
32-bit System Space Windows (S0/S1) 1 1
64-bit System Space Windows (S2) 0 0
Memory Reservations (pages): Reserved In Use Type
Total (0 Mb reserved) 0 0
DISK$ALPHA_711H2:[SYS0.SYSEXE]SWAPFILE.SYS
Free Blocks 44288 Reservable Blocks 44288
Total Size (blocks) 44288 Paging File Number 1
Swap Usage (processes) 0 Paging Usage (processes) 0
This file is used exclusively for swapping.
DISK$ALPHA_711H2:[SYS0.SYSEXE]PAGEFILE.SYS
Free Blocks 86704 Reservable Blocks -739184
Total Size (blocks) 1056768 Paging File Number 3
Swap Usage (processes) 0 Paging Usage (processes) 127
This file can be used for either paging or swapping.
Of the physical pages in use, 4299 pages are permanently allocated to OpenVMS.
My question what road should I take to improve performance? Should I:
1 – Increase the physical memory
2 – Increase the PAGEFILE.SYS
3 – Modify the SWAPFILE.SYS
Although we have recently installed three new drives, we have yet to populate
them.
The Answer is : Please do not follow the course of action that you have started toward in a head-long fashion. Rather, please use the systematic approach documented in the OpenVMS performance manual. Please first find, benchmark, and then remove specific bottlenecks. It does appear that your primary pagefile is woefully undersized for the current system load, but this could easily be because a secondary pagefile was originally used and is not presently connected. Or this could be because too many processes are presently running on this unspecified Alpha system, or because the pagefile settings of the processes present are collectively far too large. (The OpenVMS Wizard would look at locating all pagefiles as secondary files, and thus on disks other than the system disk, particularly based on disk I/O loadings -- the performance manual will discuss this and related considerations.) After reading the performance documentation and after cleaning out the old and unnecessary cruft in MODPARAMS.DAT and then performing an AUTOGEN pass with FEEDBACK (which a full pass will re-size) -- and after seriously considering an upgrade to V7.3-1 -- the OpenVMS Wizard would seriously look at an Alpha system upgrade or at least a memory hardware upgrade if the current system load is to be sustained with increased performance requirements. (This unspecified Alpha system looks to be severely overloaded, simply put.) The OpenVMS Wizard uses a rule-of-thumb that there can usually be a roughly ten percent improvement in aggregate system performance through manual system tuning, beyond what AUTOGEN with FEEDBACK can acquire. Further, this manual tuning effort is an expensive and particularly time-consuming process. Manual tuning -- particularly tuning without having a target bottleneck and benchmark data -- can potentially result in lower system performance. (The benchmark data will help identify these situations, and detailed information on your changes will help you back out from failed performance-improvement changes and to then try new and different changes.) Your current read hit rate is hideously bad, which implies the I/O cache is undersized (and at 3MB, that's not surprising) or that the cache is unable to predict the I/O patterns. This tends to imply a cache that is too small (which certainly looks to be the case), or highly random I/O patterns. (V7.3 and later have a much improved cache, but you do not appear to have sufficient physical memory present to use the existing VIOC or the new XFC cache to any particular benefit.) Again, please review the performance manual.
|