Tuning up an Ultrix system? HELP

[Alan's Home for Wayward Notes File.]

	The summary refers to the fact that in past years the 
	VMS answer to "How do it make it run faster" was "Get 
	more memory.".   That may still be true in your case,
	but we have to find out.

	1.  First use vmstat(1) to look at:

	    a.  How much memory you have and if you might be
		paging.
	    b.  How the CPU is spending its time.

	Sample vmstat(1) output:

 procs     memory                       page      disk  faults          cpu
 r b w   avm  fre  re at  pi  po  fr  de  sr x0 x1 x2 x3  in  sy  cs us sy id
 0 0 0   964 7576   0  0   0   0   0  36   0  0  0  0  0  12  32   6  0  1 98

							  (CPU related stuff)

	For CPU time look at the end of the line.  The columns for
	"us", "sy" and "id" are times spent in user and kernel mode 
	and idle time (percentages).  Since you have a two CPU system
	you'll also want to look at the individual CPU break down
	with iostat(1).  If the majority of time is being spent in
	user mode and the slave processor is reasonably busy then
	the problem is that you don't have a fast enough system.

	On the other hand if the majority (or a signifcant part) of
	the time is spent in kernel mode or there is idle time and
	the slave processor is mostly idle, look for a problem else
	where.  The first place I'd look is "in", "sy" and "cs".

	These are device interrupts, system calls and context switches
	(per second).  Lots of system calls will tend to create lots
	of time spent in kernel mode.  "Lots" depends a lot on the
	system and I'm afraid I don't have a good feel for what a lot
	is on your system.  You might want to look at it when the system
	doesn't seem slow and when it does to see if there is a difference.

 procs     memory                       page      disk  faults          cpu
 r b w   avm  fre  re at  pi  po  fr  de  sr x0 x1 x2 x3  in  sy  cs us sy id
 0 0 0   964 7576   0  0   0   0   0  36   0  0  0  0  0  12  32   6  0  1 98
	(Memory usage)

	If the CPU utilization looks "reasonable" (meaning you have
	idle time that isn't being used).  Look to see if you have
	enough memory.  The current version of ULTRIX tries to keep
	about 512 KB. free and will start paging and perhaps even
	swapping to do this.  If "fre" is around there or below see 
	if you have many non-zero number in the "re" through "sr"
	fields.  These are the paging stats and are resonably des-
	cribed in the manual page for vmstat(1).  The fields "pi"
	and "po" represent real paging I/O where "re" and "at" are
	usually "soft" page faults.

	If you're paging there are a couple of choices.

	1.  Get more memory.
	2.  Use less memory.
	3.  If you must page, page more efficiently.

	Getting more memory is good for DEC or the company you buy 
	memory from.  Arrangeing to use less memory takes more work
	on the part of the system manager.  Use ps(1) to look for
	processes that are using lots of memory.  If they are user
	applications work with the users to see if they can reduce
	the memory requirements.  If all else fails you can start
	looking at hand scheduling them with kill -{STOP,CONT} and
	letting the page daemon reclaim their pages when they don't
	run.

	If you're still stuck with paging I/O look to see if you can
	arrange the page/swap space so that it is more efficient.
	Put the page/swap partitions on the fastest disks and
	spread them between the controllers and disks.  If you have
	the option look at putting the page/swap partition towards
	the logical middle of the disk (this should be close to the
	physical middle).

	Have you changed the size of the buffer cache?  It might be
	better to give some memory back to the system to use for
	program rather than as buffer cache.  You might be able to
	reduce the amount of memory the system tries to keep free
	(_lotsfree I think).

	This should give you enough to start.  You might also want
	to ask your local DEC office for a program called monitor.
	It might make collecting and looking at the vmstat(1) and
	iostat(1) style data easier.  If they haven't heard of it
	they can ask me (I also work for DEC).
-- 
Alan Rollow				alan at nabeth.enet.dec.com