From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 18-NOV-1992 09:35:19.04
To: info-vax@kl.sri.com
CC:
Subj: SUMMARY : TUNING QUANTUM
Last week I posted a query about the SYSGEN parameter QUANTUM and what
it should be set to.
I have received a number of replies with various recommendations and I
wish to thank the following people in particular:
Rick Colombo, Dan Wing, Wolfgang J Moeller, Kent Gabrin and Robert McIntosh.
Thankyou to everyone who replied.
I have summarised the information for anyone interested and would be
extremely interested in any further clarifications or extensions that
you would care to provide.
Please note that I am only a lowly database administrator trying to get
the best out of what I have to use and I have not been on any VMS Tuning
or System Administration courses as that's not my job but someone has
to do it.
=============================================================
All replies are in agreement that a lower setting for QUANTUM (than the
DEFAULT) is recommended unless you have a BATCH oriented machine or a
single user machine.
QUANTUM
-------
This is the time-slice of CPU that a process can have before it has to give
it up for another process to do work. In reality very few processes would
use their entire QUANTUM before being interrupted by the need for I/O, page
faults, or pre-emption by a higher priority process. The default setting
under VMS V2 was 40, under VMS V3 it was 30, and with VMS V4 and V5 it is
20 (ie 20 x 10ms where 10ms = 1 "clock tick"). This default is the same
across all VAX platforms and I believe was the original setting for a VAX
11/780, a 1 VUP machine. Information from Internet indicates that an
interactive user moving from field to field in an editor and forms and such
would rarely (if ever) use up a QUANTUM of 5 let alone 20 and this becomes
even less likely on th faster machines.
On a 11/780 (a 1 VUP machine), one "clock tick" is approximately equal to
10,000 instructions so a lot more work can be done on a 32 VUP CPU like one
of the ones in our 6620's.
Many Internet replies indicated that sites are running with a QUANTUM
setting of 5 on machines such as 780, 6430, 8600, 8650, 8800, 8820, 8830,
6530, 9210 and no more than 10 on smaller machines.
One interesting "rule-of-thumb" for Quantum setting uses the algorithm:
QUANTUM = 20 / SQRT(VUP rating)
I have assumed that on a machine with two or more CPUs then you would
only use the VUP rating of one of the CPUs for the calculation.
This means that QUANTUM should be set as follows on my various machines:
Machine VUP for single CPU Calculation QUANTUM
3300 2.4 12.90 13
3900 3.8 10.25 10
4200 5 8.94 9
4300 8 7.07 7
63xx 3.8 10.25 10
64xx 7 7.55 8
65xx 13 5.54 6
66xx 32 3.53 4
94xx 40 3.16 3
Since the vast majority of my machines are for interactive work then the
default of 20 should be altered as indicated above for best interactive
performance. Batch jobs will incur a slight overhead of process
time-slicing but the purpose is to primarily service our interactive users.
Quantum can never go below a value of 2.
Note: Decreasing the QUANTUM does not improve performance; it improves the
"perceived response" by balancing the CPU resources more evenly across all
users and if the users think that they're getting better response then I'm
happy too. The overall throughput of the machine is slightly reduced
because of the extra OS overheads of a smaller time-slice.
IOTA
----
IOTA defaults to 2 and is the number of QUANTUM that a process misses out
on if it is forced to do an I/O, or memory fault etc.
General consensus here was that if you lower QUANTUM then you should also
lower IOTA to 1. The change should be proprtional but you only work in
integers. An increase in QUANTUM above 20 should be matched with a
proprtional increasein IOTA.
All Internet replies indicated that there was little danger in changing the
QUANTUM and IOTA parameters.
----------------------
During the investigation some other parameters were identified that could
do with some tweaking:
AWSTIME
-------
Has a default setting of 20 and represents the CPU time to be reached
before Automatic Working Set Adjustment can occur.
A setting of 60 was recommended. No justification was presented for this
but I think it will reduce the OS overheads of how often it is checking
processes for Working Set adjustment. Don't know how safe it is to change
this parameter.
WSINC
-----
Has a default of 150 and represents the number of pages by which any
processes working set size can increase when more RAM is requested.
A low value for this results in a process having to make many OS calls for
RAM when a lot is needed. eg if a process has a current working set size of
500 and needs to grow to 2000 then it will be delayed (2000-500)/150 = 10
QUANTUMs (ie 1 sec) but this assumes that they have the CPU to themselves
and you would experience longer delays before an executable gets enough
space to start running.
A setting of 503 was recommended. By having a larger value you can reduce
the number of calls (and OS overhead) and shorten load times. A high
setting here may help with the problems users are having in Oracle with
spawning sub-tasks and such. Should be relatively safe to change this
parameter.
WSDEC
-----
Has a default of 35 and is the exact opposite of WSINC. If the OS needs
RAM for other processes then it starts grabbing back space from processes
in chunks of this size. This was apparently changed to a default of 250
under VMS 5.4.
A setting of 19 was recommended but I can't see any reason for reducing it
below its default setting. Should be relatively safe to change this
parameter.
PFRATH
------
Has a default of 120 and is the Page fault tollerance rate. A high setting
here means that the OS will not bother adjusting your working set size
until you start exceeding this limit regularly (I think).
A setting of 10 was recommended. I assume that this means that the OS
should endeavour to give everyone as much RAM as they can use and reduce
page faulting to a minimum. I think we should be wary about making changes
to this parameter on any machine that has an obvious shortage of RAM.
PFRATL
------
Has a default of 0 (zero) and is the Page fault encouragement rate. I
think that the default of zero indicates that the ideal process state is
when it executes with no page faults at all and no working set reductions
are carried out as a result of low page faulting.
A setting of 1 was recommended (except in the case where you have LOTS of
memory to play with {ie CNB13V and CNB11V} in which case you should leave
it at zero). I think the justification here (for a setting of 1) is that
all processes should be forced to do some page faulting thus freeing up
memory to the OS pool for better use elsewhere. I think that this change
can be made safely on all our memory hungry machines.
PIXSCAN
-------
Has a default of 1 and I'm not sure what it is used for.
A setting of 1 was recommended. Current settings vary on our machines as
shown:
CNB12V = 63, CNB01V = 24, CNB06V = 66, CNB08V = 66, CNB13V = 10, and CNB07V
= 16.
I'm not sure of why it should be set to 1 and if it is safe to make this
change although there seems to be little correlation between CPU size,
machine technology and the current set value.
----------------------
--
Bruce... pihlab@hhcs.gov.au
*******************************************************************
* Bruce Pihlamae -- Database Administration *
* Commonwealth Department of Health, Housing & Community Services *
* Canberra, Australia (W) 06-289-7056 *
*******************************************************************
* These are my own thoughts and opinions, few that I have. *
*******************************************************************