Tune up for an old engine

[~XT6561110~Frank McGee~C23~L25~6326~]

In article <8287 at ccncsu.ColoState.EDU> dennis at longs.LANCE.ColoState.Edu (Dennis Miyoshi) writes:
>
>Hello again AT&T computer folks:
>
>I have a new and exciting venture in store.  Recently, I was able
>to add 4 MB of RAM to a 6386E system running UNIX SysV Rel 3.2.1
>bringing my machine to a total of 8 MB of RAM.  Wonderful.  Right?
>Wrong.  I assumed that this memory addition would enable me to 
>execute the X-Window System Release 1.1 in a more efficient manner.
>No distinct difference was noticed.  My question is.  Is there a
>good set of Tunable Parameters for a machine with 8 MB of RAM?
>Even better.  Is there a table which illustrates the Tunable Prameters
>for 6386E's from 2 to 64 MB?  The tables that I have are included with
>the UNIX documentation and go up to 4 MB of RAM.

More memory won't help you run Open Look faster unless you are
swapping.  Something else to keep in mind is that as you add
memory, you might need to increase swap space.  In general,
swap space should be atleast equal to the amount of memory
installed.  Since swap space is measured in 512 byte (1/2 K)
blocks, you'd need atleast 16000 blocks (8 MB) of swap space.
You can find out about swap with the /etc/swap command.

Here's some generic information on tuning; it's basically my
interpretation of what's in Chapter 5.  Beyond the guidelines
for 4 MB of RAM, it's probably a better idea to evaluate your
processor load, and see which tunables will help.  Most of
what it will do is increase your disk performance though, and
that probably won't help Open Look much.

Hope this helps you out,

Frank McGee
Entry Level Systems Support
attmail!fmcgee (prefered)
{att,attmail}!cuuxb!fmcgee

"UNIX, Xwin, and OPEN LOOK are registered trademarks of UNIX
System Laboraties, Inc., in the U.S. and other countries."

------------------

As far as performance tunables go for UNIX, they are described
in great detail in Chapter 5 of the UNIX System V/386 Release
3.2.2 Operations/System Administration Guide.  There are good
general descriptions of the UNIX tunables and how to properly
adjust them in that chapter.  The ones I suggest you adjust
would be :

NBUF - size of the buffer cache for block devices.  Most of
the time it is used as disk buffers.  Each block is 1024 bytes
(1K).  Ideally, you want to set this as high as possible
within reason.  For example, if you have lots of disk buffers
(more than 2000) you will probably spend a sizable amount of
cpu time just flushing the dirty buffers.  You also don't
want to set it so high that the size of your buffer cache
causes the system to start swapping - you can determine the
amount of free memory by running sar reports (sar reports
free memory in 4K pages, so multiply by 4 and you have the
number of K free).  I'd recommend setting it for 1000 if you
have 1 MB of RAM free, and if possible you might want to go
as high as 2200.  If you set it above 1000 though, you'll
probably want to adjust the tunable NAUTOP, which regulates
how often you flush your disk buffers (for 2200 buffers the
Sysadmin Guide recommends you set it for 45).  

NHBUF - should be 1/4 of NBUF.

NPROC - size of the process table.  You need an entry in the
table for every process you have running.

NREGION - number of memory regions.  Each process uses atleast
3 memory regions, and if it happens to use shared memory it
will use more.  I usually recommend that it be 4 times the
size of the process table.

NFILE  - size of the file table.  Each process uses atleast 3
files; stdin, stdout, and stderr.  So NFILE should be atleast
as large as 3 times NPROC, and possibly larger.

NINODE - size of the i-node table, should be the same size as NFILE.

NCLIST - I recommend you raise this tunable "just in case".
NCLIST regulates the number of CLISTS in the kernel.  CLISTs
are used primarily by serial device drivers to pass data
around.  If you happen to run out of them, you won't get any
error messages on the console since it requires free CLISTs to
print them.  Since most of your I/O will done over the network
though (networks use streams to pass data, not CLISTs), setting
it for 200 should be okay.  The symptom that you are out of
CLISTs is that see some users that work okay, but others
don't, and if one person logs off, now another persons
terminal will start working again.

In general, if you run out of file table, proc table, region
table, or inode table space, you will get an error message on
the console saying so.  In addition, you can run daily sar
reports to find out how things are going, and if you need more
memory, or need to do more tuning.  Remember also that just
blindly cranking up the tunables is a bad idea as well.  If you
have a process table with 1000 entries, and you only use 100,
you'll be spending 90% of your time scanning an empty process
table as you scan the process table.

-- 
Frank McGee, AT&T
Entry Level Systems Support
attmail!fmcgee (preferred)
att!cuuxb!fmcgee (those that can't reach attmail)