Why is my system slow?

From http://pcunix.com/SCOFAQ/scotec1.html#slow



(Also see http://pcunix.com/Unixart/troubleshooting.html and http://pcunix.com/Unixart/slow.html)

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 CPU-bound.

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 and mpsar 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/, 74013.1625@compuserve.com), 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 (tls518 for OSR5, tls018d 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 http://www.caldera.com/skunkware/osr5/vols/hog-1.1-VOLS.tar

Another commercial product which may be of use is Olympus Tuneup (Olympus Software, (408) 426-7582, olympus@olysoft.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 Lawrence

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).