[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

OpenVMS Performance Tuning? (Large Memory)

» close window

The Question is:

 
I have another question for you from Tallahassee, I would also appreciate
your opinion about some SYSGEN Parameters. We have a three node alpha
cluster running VMS 7.1-2 with 6 GIG of memory on each node.
 
1) Per suggestion from are contractor we have set the following parameters
such that the system does not utilize the system pagefiles. The process tend
to use memory until the Free Page List is almost empty. We then  have to
stop and start the process to
recover the memory. They say this improves performance by reduceing the
number of hard page faults, but I believe we have reached a point of
diminshing return. Is it a good idea to set these values this high.
 
PQL_DWSEXTENT = 1282048
PQL_DWSQUOTA  = 37368
 
2) I have been trying to determine how much physical memory a process is
using. There are a couple of argument for the lexical F$GETJPI that I have
been playing with to determine the overall largest consumers of memory. Can
you define these arguements mor
e clearly. I would also appreciate your thought on the best way to determine
how much memory a process is consuming.
 
GPGCNT    -   Global Page Count in Working Set.
PPGCNT    -    Process Page Count.
VIRTPEAK  -   Peak Virtual Address Size.
WSSIZE    -    Process's current working set size.
 
 
 
Mike Casserly
Please feel free to publish my question.
 
 


The Answer is :

 
  Without particular details on the environment -- both in terms of the
  current process activity and the specific requirements -- an answer
  is rather difficult.  Remote system tuning is exceedingly difficult.
 
  As a first rule of thumb, the OpenVMS Wizard strongly encourages you
  to ignore most tuning "rules of thumb" and to also ignore most
  "quick-and-easy" system tuning tips -- some are certainly correct,
  some were once correct, some are correct for very specific workloads,
  and some were never correct.  Determining which of these possibilities
  is the basis of the "tip" is an interesting and difficult task for the
  OpenVMS system manager.
 
  That said, the use of the MODPARAMS.DAT file and AUTOGEN, saving and
  using the FEEDBACK mechanism, and following the recommendations for the
  system parameters and process quota settings discussed in the OpenVMS
  performance management manual are recommended -- AUTOGEN and a basic
  system performance examination will generally get you rather close to
  the theoretical maximum system performance, often with extensive manual
  effort (gathering data, analyzing, tweaking, and then analyzing results)
  and/or one or more hardware upgrades required to achieve additional
  system performance gains.  (Failure to follow the analysis-feedback
  loop as set forth by the OpenVMS performance manual can actually lead
  to serious performance problems...)
 
  There are system performance analysis and tuning tools available from
  various sources -- in addition to AUTOGEN, of course -- that can
  sometimes be of assistance.  These tools can range from reporting
  and analysis tools to tools that gather and dynamically tune the
  system.  Also available from various sources are consulting services.
 
  PPGCNT is the number of private pages in the process's working set.
  GPGCNT is the number of global pages in the working set.  WSSIZE is the
  current capacity of the process working set list -- the working set
  limit -- and the working set is not necessarily densely packed.  The
  actual working set size can be determined by adding PPGCNT and GPGCNT.
  VIRTPEAK is the peak number of pages in the process's virtual address
  space.
 
  The actual amount of physical memory in use by a process is GPGCNT+PPGCNT.
  Since there is an unknown about of memory sharing, the total memory
  consumed by all processes is anywhere between SUM(all PPGCNT)+MAX(GPGCNT)
  and SUM(all PPGCNT)+SUM(all GPGCNT).
 
  The PQL_D* SYSGEN parameters are the Process Quota List (PQL) defaults.
  They are only considered for processes which are activated without the
  corresponding PQL entry being specified.  Since a complete PQL is
  specified for *most* processes (ie: all interactive, batch, network and
  subprocesses), there are probably only a handful of processes on your
  system that will be affected by these settings.
 
  Of much more interest are the PQL_M* parameters. These are PQL Minimum
  values and will override lower PQL settings for ALL processes on the
  system. by default AUTOGEN will set PQL_MWSEXTENT to WSMAX, thereby
  allowing any process on the system to expand its working set size to
  WSMAX (assuming memory is available).  In general, this can be a "good
  thing" and is unlikely to cause trouble as the system is free to take
  memory back from processes with working sets extended beyond their
  WSQUOTA.  By default, WSMAX on a 6 GB system would be larger than
  1282048.
 
  A WSQUOTA of 37368 pagelets is not very large -- that is only ~16MB.
  However, depending on the number of processes on your system, it may
  make sense to reduce it, to allow the system more latitude for
  recovering memory.
 
  On very large memory systems, reducing the WSEXTENT value will not
  necessarily increase hard pagefaults as processes will page against
  the free list and modified page list. Soft page faults are cheap, but
  they are not free.  If you have free memory, but are still experiencing
  pagefaults, you need to determine the cause. You may find they are due
  to image activations, in which case tuning working set sizes won't
  help much, you would need to look at the application to see if it's
  possible to reduce the number of activations.  And -- of course -- you
  will want to determine first if the application performance is currently
  insufficient, and then if the numbers of soft and hard faults are even
  of central concern when examining system and application performance...
 

answer written or last revised on ( 15-NOV-1999 )

» close window