$My company has a 486-66 with 16MB RAM, Adaptec 1542B SCSI controller
$card, and 3 Micropolis 1GB H.D. Everytime someone does a report, the
$system slows down quite a bit (it was due to that RM/COBOL data files
$are about 50MB in size, and sometimes the report will cover 3 years of
$data). Is there any tunable kernel parameter that can adjust the
$behavior of the SCSI H.D. disk access?
Yes; there are lots.
But a little more information on your disk usage patterns might
be useful prior to making some recommendations. And I should probably
also note that while we may be able to help a bit, if you're running
great big reports on great big data files, the system is pretty much
_always_ going to slow down; short of replacing hardware with faster
devices, the best we can realistically hope for is to make the system
not quite as slow as it is now.
Also, we should make a quick survey of other areas of system
performance, to make sure that it really _is_ your disk subsystem
which is the root of the problem and not, say, a shortage of memory
or lack of CPU power. If your disks _can_ keep up and the real problem
is that you're out of CPU and/or memory, then we can tweak the
kernel parameters for the disk all we want and it's not going to help.
Your system includes some performance monitoring tools. The one
I really want you to use is sar. Some of the useful options include:
-d: This shows a whole whack of information on disk activity, broken
out by device. Let's say your reports take three minutes to
run. One minute before you start them, run sar -d 60 5, and
then post the results. This will show five samples, each taken
over one minute; we'll have a relatively quiet period on each
side of the report, and then three minutes of data during the
report to show what it's doing. Actually, sar -d 30 10 or
sar -d 15 20 would be better, but the output will start to get
rather large ...
-b: This shows how well your buffer cache is working for you. Again,
try running it so that it takes snapshots before, during, and after
-u: This shows CPU utilization; what I want to see here is that %wio
is fairly high. That means that there's plenty of CPU power left,
and that the system is spending most of its time waiting for I/O
-w: Reports swapping activity. I want to know if you're trying to
use more RAM than you actually have. If you have enough memory,
we should see low (or zero) for everything except pswch/s.
There are also some very useful tools available from the net.
At ftp.sco.com, you will find (among other tools) bcw, memhog, iohog,
bcw is basically a real-time tool for displaying the status of your
buffer cache. It's non-obvious unless you have some understanding
of how Unix manages its buffers, but if you can capture its output
to a file (I'm not sure, but I _think_ it can be told to run once and
print to a file) while your report is running, post the results and
we may see some useful information.
memhog, iohog, and cpuhog are actually all the same program. They
sample data over a user-defined period of time and display which
processes are using the most memory, I/O, and CPU time, respectively.
They're probably not going to be of much assistance to us here, but
they're worth mentioning so that you know they're out there. Ditto
for u386mon, which I _think_ is also at ftp.sco.com (if not, check
the major SCO archive sites and you should find it).
Manager, Technical Services United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7 (416) 750-7946 x251