Unix, Xenix and ODT General FAQ
This article is from a FAQ concerning SCO operating
systems. While some of the information may be applicable to any OS,
or any Unix or Linux OS, it may be specific to SCO Xenix, Open
There is lots of Linux, Mac OS X and general Unix info elsewhere on
this site: Search this site is the best
way to find anything.
(Also see /Unixart/troubleshooting.html
This is a very old article and has little relevance to modern
systems. It does remain true that having insufficient memory will
cause bad performance but "tuning" is very unusual because most
sytems dynamically tune now and do a very good job of it.
First things first - make sure that somebody didn't accidentally
turn the Turbo switch off. Don't laugh - I have a client who
regularly manages this one. At some sites, it may be wise to
disconnect this switch entirely.
It might also be wise to run the system's CMOS setup program and
ensure that primary and secondary cache is turned on, unless you
know for a fact that there's something in your system that won't
work properly that way. Turning on BIOS shadowing will generally
only speed things up at boot time; with the exception of vbiosd
(used to call real-mode video BIOS routines for video mode
switching on some video cards in SCO's X11R5 implementation), the
BIOS is not used after this point. If you gain the use of extra RAM
by disabling BIOS shadowing, you should certainly do so; even if
you don't, there may be cases where BIOS shadowing may lead to
weird problems (I've even seen a host adapter which wouldn't work
at all if its BIOS was shadowed or cached, for example).
Under both Unix and Xenix, you can use vmstat
to give you an overview of system performance. One problem is that
it won't show you what percent of the system's time was spent
waiting on I/O devices, and what percent was spent idle; these are
both lumped together as idle time. vmstat can be helpful in
diagnosing excessive swapping, and in finding if your system is
Unix also offers sar,
which is far more advanced than vmstat. It reports on a wide range
of system statistics including CPU utilization (system, user, idle,
waiting for I/O), memory use, disk cache effectiveness,
swapping/paging, and things you've never even thought of. Note that
under MPX, it may not be reliable; check your MPX release notes for
info (and for information on the mpstat
programs). One third-party program which may be useful in
conjunction with sar is sarcheck (Aurora Software Inc., P. O. Box
1033, Plaistow NH 03865, (603) 382-4200, http://www.sarcheck.com/, firstname.lastname@example.org),
which translates sar's results into English to identify system
performance bottlenecks and suggest possible resolutions for these
problems. sarcheck also works on multi-processor systems.
There are some other utilities you may wish to use. Some freely-
available ones include u386mon, bcw, and
cpuhog/iohog/memhog, all of which are available in various TLSes
for older versions- but not Xenix). u386mon is a general
performance monitoring utility which watches about as many
different things as sar (but presents the information in a
full-screen display format); bcw is the Buffer Cache Watch, which
can help you see how well your cache buffers are tuned for your
system's actual needs; the hog programs show you processes which
are hogging those respective resources.
Skunkware has "iohog", "memhog", and "cpuhog". These can help
you pinpoint misbehaving processes. Download them all from Hog
Linux systems have "memhog" if numactl is installed. Numactl can assign specific a process to a specific cpu and control memory policy in other ways. The "memhog" does something very simple: it eats up memory and then releases it. Why would you ever do that?
Well, possibly to test how another app performs when starved for memory or to push unused memory in other apps out to swap (that can help you see what's really available should you need it)..
Another commercial product which may be of use is Olympus Tuneup
(Olympus Software, (408) 426-7582, email@example.com), which will
monitor how your system is making use of tunable kernel resources
and can perform tuning for you.
Multiuser/multitasking/etc. operating systems love extra memory.
Xenix will use up to 16 MB; Unix will use much more (how much
depends on what version; check your release notes). There are
several ways that extra memory is used; here are three of the most
important. First, disk buffers; the system uses these for disk
cache, and in general, the more, the better. Second, to avoid
swapping; while a virtual memory system allows you to access more
memory than you actually have, doing so involves the hard drive,
which is several orders of magnitude slower than memory. Third, the
system keeps recently-used programs in memory; if you access one
again, it doesn't have to be reloaded from disk. There are
tradeoffs between #1 and #2+#3; the more memory you have, the more
generously each can be configured. Note that adding more memory
will not cure CPU-bound processes, and will only cure I/O-bound
processes if it can be used effectively as a disk cache (often it
can, but not always).
Roberto Zini: I seem to remember that some "old" systems could
start crawling after adding more RAM; if I remember correctly, that
was due to the fact the CPU could not cope with the additional RAM
since it had too little internal cache. I'm not an hardware expert
so the above could be plain wrong nowadays; could you confirm that
Yes. CPU cache is still important- Tony
Also, double check the "netstat -m" output; we're currently
fighting against a problem under SCO OpenServer 5.0.5 (fully
patched) which causes it to crawl when STREAMS resources get low.
If you notice non-zero values under the "fail" column, it's time to
add more STREAMS buffer by making use of the configure utility
under /etc/conf/cf.d (NSTRPAGES is the parameter to boost).
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic