Questions on 3b1 (ktune)

[was-John McMillan]

In article <1506 at naucse.UUCP> sbw at naucse.UUCP (Steve Wampler) writes:
...
>(3) Can anyone tell me how to *use* ktune?  I mean how I might
>	effectively adjust things to improve performance.  Since
>	I added both disk and memory, I thought I might want to
>	adjust it.  However, after trying to just bump all the
>	parameters up, I'm now convinced that one needs to make
>	changes systematically - bumping everything up resulted
>	in all but one parameter going *down*.  Is there a way
>	to monitor the system for a while to see what parameters
>	should be changed to what values?

	There is a very finite amount of memory available for
	the kernel code PLUS tunable arrays.  My recollection
	is that the total must be less than about 0x5c pages
	or about 360KB.

	If you get "smart" -- eg: ktune nbuf=200 -- the kernel
	realizes the "impracticality" of this and  tries again
	after multiplying every tunable value by .75.  After
	several iterations of this things usually "pass" the
	memory constraints.

	"nbuf" is the largest space consumer (~1070bytes)
	per unit and can't be pushed beyond ~125.  It is almost
	always the one people want to push UP.  Benchmarking
	typically show only modest gains above 80, however, and
	all gains here are potentially at the expense of paging
	faults.  If you've LESS than 2 MB, it might pay to REDUCE
	the nbuf.

			- - - - - - -

	Ergo, there isn't really very much 'ktune' can do to
	improve your system.  It CAN help you to work around
	problems idiosyncratic to YOUR use: perhaps you
	require a LARGER number of open files or inodes.
	Recommendation: unless you're getting resource
	exhaustion messages ("out of inodes"), ignore ktune.

jc mcmillan	-- att!mtunb!jcm	-- Speaking for SELF, not AT&T