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