[mod.computers.vax] Tuning and similarly 'touchy' topics

"MCCORE::BOLTHOUSE@ti-eg.CSNET".UUCP (03/23/87)

I feel compelled to join in the fray regarding system tuning, especially
since someone made the point that swapping under VAX/VMS is *VERY* bad.
This generalization is sufficiently oversimplified I arched my left eyebrow 
in surprise.  Perhaps it is being foisted upon us by overly-zealous but
well-meaning employees of a certain large computer firm...


My experience/biases:

1.  What is 'bad' depends upon your workload.  It is very, very bad to
    trim pages from a large process merrily spinning away on an attached
    processor.   [ Can *you* say 'flushed free and modified lists'? :-) ]
    Especially if someone with clout is eagerly awaiting the results of said
    processing.

2.  What is 'bad' also depends upon your user community.  I 'tuned' an
    11/785 one day such that the system was significantly more 
    responsive.  But in doing so, I reduced overall throughput.  My
    customers were satisfied.  The moral:  what users perceive
    is more important than what you (or I) think about tuning.

3.  What is 'bad' also depends upon how you implement a system performance
    model.  VMS can swap efficiently.  At the Spring '86 DECUS in Dallas, (I
    think) someone discussed a rather rebellious tuning method.  The basic
    argument was that secondary trimming is more expensive than swapping 
    (you do lots of little I/Os when paging the process back in versus several 
    LARGE I/Os when being swapped in).  The key to tuning, in my opinion, is 
    to reduce I/O frequency; that is, don't spend your elapsed time moving lots 
    of small chunks around.  We have machines which primarily swap to gain 
    memory, and we have machines which page.  Again, the decision is made 
    based upon the current and anticipated workload of the machine.

4.  AUTOGEN (and SYSGEN/SYSBOOT defaults) is biased against swapping.  Remember 
    that these tools must work across the entire spectrum of VAX processors,
    memory sizes, disk device speeds, and workloads.  AUTOGEN provides a
    reasonable point of departure for most systems.  If you want a system
    to swap you'll have to work at it.  Check the symposium notes for the 
    Dallas DECUS for more info; also, regard the VAX/VMS system performance
    manual as a motherlode of ideas.

5.  AUTOGEN (and, indeed, most tuning methods I've seen) is biased 
    against a large modified list.  People who tune systems on which 
    simulations are run can probably expect to increase the size of their 
    modified list significantly.  I have tuned a few machines such that
    the modified list can become larger than the free list; on the other
    hand, most of our machines 'want' the free list to be about 5 times 
    the size of the modified list.

6.  People who tune large VAXes (85/87/8800) should look very carefully 
    at spindle (disk) loading before anything else.  Watch for overloaded
    HSC disk data channels, large pagefiles and swapfiles on disks with
    high image activation rates (like the system disk...), and so forth
    after MONITOR DISK/ITEM=QUEUE tells you which disks are troublesome.
    Also beware fragmented volumes and poorly-designed RMS files.

7.  People who tune multiprocessor VAXes are in a different boat than those
    who tune uniprocessor machines because SWAPPER can run at the same time
    as a user process.  We, for example, have a VAX which has a single queue 
    (JOBLIMIT = 1) dedicated to processes requiring up to half of physical 
    memory.  We use slightly less than 1/4 of physical memory for free and 
    modified pages, and the rest is used for working sets.  We routinely
    see 195 - 200% CPU utilization on this machine.  This would *not* work
    well on a uniprocessor VAX!

8.  People who maintain historical performance data tend to tune systems
    better than people who don't.

Finally, a quick reminder from somewhere regarding optimizing anything:

The laws of optimization:

1.    Don't.
2.    Don't yet.
2.5.  See laws 1 and 2.
3.    If you must, take it one step at a time, measuring extensively 
      (and patiently!) before and after.

David L. Bolthouse
Texas Instruments Defense Electronics Information Systems VAX System Support

ma bell:  214.952.2059
arpa:     bolthouse%mccore@ti-eg.csnet
csnet:    bolthouse%mccore@ti-eg