HP OpenVMS Systems

ask the wizard
Content starts here

System Performance Tuning?

» close window

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
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
    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.
    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

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.

answer written or last revised on ( 24-NOV-2003 )

» close window