home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18149 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  8.9 KB
  1. Xref: sparky comp.os.vms:18149 comp.sys.dec:6035
  2. Path: sparky!uunet!munnari.oz.au!manuel.anu.edu.au!sserve!hhcs.gov.au!pihlab
  3. From: pihlab@hhcs.gov.au
  4. Newsgroups: comp.os.vms,comp.sys.dec
  5. Subject: SUMMARY : TUNING QUANTUM
  6. Message-ID: <1992Nov18.184713.493@hhcs.gov.au>
  7. Date: 18 Nov 92 18:47:13 +1100
  8. Organization: Aust. Dept. Health, Housing and Community Services
  9. Lines: 223
  10.  
  11.  
  12.   Last week I posted a query about the SYSGEN parameter QUANTUM and what
  13.   it should be set to.
  14.  
  15.   I have received a number of replies with various recommendations and I
  16.   wish to thank the following people in particular:
  17.  
  18.   Rick Colombo, Dan Wing, Wolfgang J Moeller, Kent Gabrin and Robert McIntosh.
  19.  
  20.   Thankyou to everyone who replied.
  21.  
  22.   I have summarised the information for anyone interested and would be
  23.   extremely interested in any further clarifications or extensions that 
  24.   you would care to provide.
  25.   
  26.   Please note that I am only a lowly database administrator trying to get
  27.   the best out of what I have to use and I have not been on any VMS Tuning
  28.   or System Administration courses as that's not my job but someone has
  29.   to do it.
  30.  
  31.  
  32.   =============================================================
  33.  
  34.     
  35.   All replies are in agreement that a lower setting for QUANTUM (than the
  36.   DEFAULT) is recommended unless you have a BATCH oriented machine or a
  37.   single user machine.
  38.   
  39.   
  40.   QUANTUM
  41.   -------
  42.  
  43.   This is the time-slice of CPU that a process can have before it has to give 
  44.   it up for another process to do work.  In reality very few processes would 
  45.   use their entire QUANTUM before being interrupted by the need for I/O, page 
  46.   faults, or pre-emption by a higher priority process.  The default setting 
  47.   under VMS V2 was 40, under VMS V3 it was 30, and with VMS V4 and V5 it is 
  48.   20 (ie 20 x 10ms where 10ms = 1 "clock tick").  This default is the same 
  49.   across all VAX platforms and I believe was the original setting for a VAX 
  50.   11/780, a 1 VUP machine.  Information from Internet indicates that an 
  51.   interactive user moving from field to field in an editor and forms and such 
  52.   would rarely (if ever) use up a QUANTUM of 5 let alone 20 and this becomes
  53.   even less likely on th faster machines.
  54.   
  55.   On a 11/780 (a 1 VUP machine), one "clock tick" is approximately equal to 
  56.   10,000 instructions so a lot more work can be done on a 32 VUP CPU like one 
  57.   of the ones in our 6620's.
  58.    
  59.   Many Internet replies indicated that sites are running with a QUANTUM 
  60.   setting of 5 on machines such as 780, 6430, 8600, 8650, 8800, 8820, 8830, 
  61.   6530, 9210 and no more than 10 on smaller machines.
  62.   
  63.   One interesting "rule-of-thumb" for Quantum setting uses the algorithm:
  64.   
  65.                QUANTUM  =  20 / SQRT(VUP rating)
  66.  
  67.   I have assumed that on a machine with two or more CPUs then you would 
  68.   only use the VUP rating of one of the CPUs for the calculation.
  69.   
  70.   This means that QUANTUM should be set as follows on my various machines:
  71.   
  72.   
  73.   Machine       VUP for single CPU          Calculation        QUANTUM
  74.   
  75.   3300                   2.4                    12.90             13
  76.   
  77.   3900                   3.8                    10.25             10
  78.    
  79.   4200                   5                       8.94              9
  80.   
  81.   4300                   8                       7.07              7
  82.   
  83.   63xx                   3.8                    10.25             10
  84.   
  85.   64xx                   7                       7.55              8
  86.   
  87.   65xx                  13                       5.54              6
  88.   
  89.   66xx                  32                       3.53              4
  90.   
  91.   94xx                  40                       3.16              3
  92.   
  93.   Since the vast majority of my machines are for interactive work then the 
  94.   default of 20 should be altered as indicated above for best interactive 
  95.   performance.  Batch jobs will incur a slight overhead of process 
  96.   time-slicing but the purpose is to primarily service our interactive users.  
  97.   Quantum can never go below a value of 2.
  98.   
  99.   Note:  Decreasing the QUANTUM does not improve performance; it improves the 
  100.   "perceived response" by balancing the CPU resources more evenly across all 
  101.   users and if the users think that they're getting better response then I'm
  102.   happy too.  The overall throughput of the machine is slightly reduced
  103.   because of the extra OS overheads of a smaller time-slice.
  104.   
  105.   
  106.   IOTA
  107.   ----
  108.  
  109.   IOTA defaults to 2 and is the number of QUANTUM that a process misses out 
  110.   on if it is forced to do an I/O, or memory fault etc.
  111.   
  112.   General consensus here was that if you lower QUANTUM then you should also 
  113.   lower IOTA to 1.  The change should be proprtional but you only work in
  114.   integers.  An increase in QUANTUM above 20 should be matched with a
  115.   proprtional increasein IOTA.
  116.   
  117.   
  118.   
  119.   All Internet replies indicated that there was little danger in changing the 
  120.   QUANTUM and IOTA parameters.
  121.   
  122.   
  123.   
  124.   
  125.                             ----------------------
  126.   
  127.   
  128.   During the investigation some other parameters were identified that could 
  129.   do with some tweaking:
  130.   
  131.   
  132.   AWSTIME
  133.   -------
  134.  
  135.   Has a default setting of 20 and represents the CPU time to be reached 
  136.   before Automatic Working Set Adjustment can occur.
  137.   
  138.   A setting of 60 was recommended.  No justification was presented for this 
  139.   but I think it will reduce the OS overheads of how often it is checking 
  140.   processes for Working Set adjustment.  Don't know how safe it is to change 
  141.   this parameter.
  142.   
  143.   
  144.   WSINC
  145.   -----
  146.  
  147.   Has a default of 150 and represents the number of pages by which any 
  148.   processes working set size can increase when more RAM is requested.
  149.   
  150.   A low value for this results in a process having to make many OS calls for 
  151.   RAM when a lot is needed. eg if a process has a current working set size of 
  152.   500 and needs to grow to 2000 then it will be delayed (2000-500)/150 = 10 
  153.   QUANTUMs (ie 1 sec) but this assumes that they have the CPU to themselves 
  154.   and you would experience longer delays before an executable gets enough 
  155.   space to start running.
  156.   
  157.   A setting of 503 was recommended.  By having a larger value you can reduce 
  158.   the number of calls (and OS overhead) and shorten load times.  A high 
  159.   setting here may help with the problems users are having in Oracle with 
  160.   spawning sub-tasks and such.  Should be relatively safe to change this 
  161.   parameter.
  162.   
  163.   
  164.   WSDEC
  165.   -----
  166.  
  167.   Has a default of 35 and is the exact opposite of WSINC.  If the OS needs 
  168.   RAM for other processes then it starts grabbing back space from processes 
  169.   in chunks of this size.  This was apparently changed to a default of 250 
  170.   under VMS 5.4.
  171.   
  172.   A setting of 19 was recommended but I can't see any reason for reducing it 
  173.   below its default setting.  Should be relatively safe to change this 
  174.   parameter.
  175.   
  176.   
  177.   PFRATH
  178.   ------
  179.  
  180.   Has a default of 120 and is the Page fault tollerance rate.  A high setting 
  181.   here means that the OS will not bother adjusting your working set size 
  182.   until you start exceeding this limit regularly (I think).
  183.   
  184.   A setting of 10 was recommended.  I assume that this means that the OS 
  185.   should endeavour to give everyone as much RAM as they can use and reduce 
  186.   page faulting to a minimum.  I think we should be wary about making changes 
  187.   to this parameter on any machine that has an obvious shortage of RAM.
  188.   
  189.   
  190.   PFRATL
  191.   ------
  192.  
  193.   Has a default of 0 (zero) and is the Page fault encouragement rate.  I 
  194.   think that the default of zero indicates that the ideal process state is 
  195.   when it executes with no page faults at all and no working set reductions 
  196.   are carried out as a result of low page faulting.
  197.   
  198.   A setting of 1 was recommended (except in the case where you have LOTS of 
  199.   memory to play with {ie CNB13V and CNB11V} in which case you should leave 
  200.   it at zero).  I think the justification here (for a setting of 1) is that 
  201.   all processes should be forced to do some page faulting thus freeing up 
  202.   memory to the OS pool for better use elsewhere.  I think that this change 
  203.   can be made safely on all our memory hungry machines.
  204.   
  205.   
  206.   PIXSCAN
  207.   -------
  208.  
  209.   Has a default of 1 and I'm not sure what it is used for.
  210.   
  211.   A setting of 1 was recommended.  Current settings vary on our machines as 
  212.   shown:
  213.   
  214.   CNB12V = 63, CNB01V = 24, CNB06V = 66, CNB08V = 66, CNB13V = 10, and CNB07V 
  215.   = 16.
  216.   
  217.   I'm not sure of why it should be set to 1 and if it is safe to make this 
  218.   change although there seems to be little correlation between CPU size, 
  219.   machine technology and the current set value.
  220.   
  221.   
  222.                             ----------------------
  223.    
  224. -- 
  225.  
  226. Bruce...        pihlab@hhcs.gov.au
  227. *******************************************************************
  228. * Bruce Pihlamae  --  Database Administration                     *
  229. * Commonwealth Department of Health, Housing & Community Services *
  230. * Canberra, Australia                             (W) 06-289-7056 *
  231. *******************************************************************
  232. * These are my own thoughts and opinions, few that I have.        *
  233. *******************************************************************
  234.