  OpenVMS performance? 
 The Question is:
 
Firstly I am an Oracle DBA new to the VMS environment and whilst I've done a
couple of System Administration courses I'm still new to VMS, so my apologies
if this is a stupid question with an obvious or trivial answer.
 
We recently upgraded from VMS 6.2 to VMS 7.1 and at the same time upgraded
Oracle from 7.1.3.4 to 7.3.3.4 - not an ideal stategy but one that couldn't
be avoided.
 
The upgrade was reasonably successful but we have had some response time
problems. Our alpha is a dedicated Oracle server and one of the VMS /
Oracle gurus at Oracle logged onto our system to have a look around.
He identified a number of problems amongst which was we had 10 to
15 online users in a com state. He looked at the value of quantum and
suggested we reduce the value from 20 to 5. He said the value 20 was a
carry-over from the old VAX days and was far too high. Quantum was
effectively a time-slice of the CPU and as you now got many more
intructions per time-slice this value should be reduced. Can you tell me
what the value should be set to - we are currently running with a value
of 5 but at peak times (typically one or two days a month) there can
still be around 5 users in a com state. Should this value of  quantum be
reduced still further ?
 
Thanks and apologies if it is a really stupid question.
 
 
 The Answer is:
 
  Quantum controls how long a process holds the CPU, once scheduled, for
  its initial processing.  After the initial quantum has expired, then the
  process can be interrupted or rescheduled.
 
  That you have multiple computable jobs tends to point to a processor
  limitation -- your processor(s) appear unable to keep up with the system
  load.  (If there are a variety of interprocess communications, or a number
  of sys$getjpi requests flying around -- idle process monitors can queue
  large numbers of sys$getjpi requests -- then the number of computable jobs
  can be inflated.  In other words, you will want to make sure that the CPU
  queue length is consistently long before proceeding.)
 
  As a rough estimate of expected interactive responsiveness:
 
    Average_Compute_queue_length * Quantum * 10ms
 
  Assuming that the processors are doing useful work -- and you will want
  to verify this -- then you can try tweaking parameters and such, but the
  Wizard suspects that you will require a hardware upgrade to handle the
  load on the system.
 
  The Wizard will assume that you have followed the systematic performance
  analysis guidelines set forth in the Guide to OpenVMS Performance
  Management manual -- using these techniques, you can determine what the
  particular performance bottleneck(s) are, and whether these can be removed
  through hardware upgrades or application tweaks, or through system tuning.
 
  Tuning can seldom be performed remotely, and there are few (if any) "quick
  fixes" to a performance problem.  (If there were known quick fixes, they
  would/should already have been tweaked for you by AUTOGEN.)
 
  If you choose to tweak parameters, follow the steps outlined in the
  performance manual.  Get a baseline.  Tweak the parameter.  Measure
  the results.  Determine if you should tweak the parameter again, or
  if you should try another parameter.  (And do not expect to gain much
  in the way of performance beyond what a periodic AUTOGEN with FEEDBACK
  can provide you with.  Short of software problems or flagrant tuning
  problems -- clean the cruft out of MODPARAMS.DAT -- a hardware upgrade
  is often the surest way to improve performance.  Once you find out which
  part of the hardware is limiting the performance, of course...)
 
