|
HP OpenVMS Systemsask the wizard |
|
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...)
|