"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