SCO Unix 3.2.4.2 tunable kernel parameter for SCSI H.D.

SCO Unix 3.2.4.2 tunable kernel parameter for SCSI H.D.

Post by Stephen M. Du » Fri, 08 Nov 1996 04:00:00




$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
     your report.

-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
     to complete.

-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,
and cpuhog.

   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

 
 
 

SCO Unix 3.2.4.2 tunable kernel parameter for SCSI H.D.

Post by Simon Hobs » Sun, 10 Nov 1996 04:00:00




Quote:> 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?

Been there, done that, got the grey hairs to prove it ;-)  ... and many
thanks to Bela and others for their help.

We used to have a a 386DX with 8M RAM, then a 486DX33 & 16M, then a 486DX50
& 32M ..... and now we have a P133 with 128M (and when the new board
arrives, 256M RAM). We also now have a raid array. Almost every processor
upgrade has been a by product of needing to change the motherboard in order
to fit more RAM.

We used to be using Cobol, but have changed accounts SW and now have C-ISAM
files.

The most effective thing you can do is add more RAM, lots, lots more - the
more you have the better the chance of data being in the cache, and the
lower the disk IO loading. However you do have to manually configure NBUF
as SCO unix is not dynamic with its memory allocation to the cache. 'sar
-r' tells you how much memory and swap you have free (in 4k pages), so look
at these figures to see if you are using all the memory and try adjusting
NBUF (and NHBUF) - increase it too far and performance will start to drop
off as the system will then run short of memory.

The other thing you should consider with that volume of disk space is get a
faster controller (and possibly fater disk(s)). Only you can decide where
to draw the line, but the slowdown will be costing you money in lost
productivity. Upgrading to a faster processor and a PCI based machine will
allow you a choice of much faster SCSI controllers (but beware of drivers
below version 1.8 for the Adaptec 2940). The 1542 controller only runs up
to around 4MB/s and is plugged into an IO bus that only really gets up to
16MB/s throughput. The PCI bus is capable of up to 133MB/s, and modern fast
SCSI disks and controllers are capable of up to 40MB/s (depending on bus
options used) although no current disk can provide this sustained data rate
!.

Another trick worth looking at (it worked for us !), is to run your reports
at a lower priority ('man nice' for details). It doesn't affect disk
accesses (unless soemone tells me otherwise), but it does mean that the
report gets suspended whenever any of the user processes are trying to run
(this in itself tends to improve the disk io situation). We found it made
very little difference to the run time of reports, but gave a significant
reduction in their impact on system responsiveness.

One last thing, you don't mention what OS you are running, and if you are
still running Xenix then you will have to upgrade to Unix to extend you RAM
(Xenix only supports 16M). Also if you do look to replace some of the
hardware, make sure that any replacement disk controller handles transfers
to/from memory above 16M, as if it doesn't then some of your IO has to be
double buffered (ie copied to ram below 16M before writing to disk, or
copies from ram below 16M after reading).

TTFN, Simon

 
 
 

1. SCO Unix 3.2.4.2 tunable kernel parameter for SCSI H.D.


: 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?

What version of SCO Unix?

There is no way you are going to cache a signifigant part of
a 50Megabloat data file in 16MB of ram.  Subtracting about 4MB
for the kernel and 0.5MB per user, there really isn't that much
ram left to build a decent cache.  You *probably* need to add
some ram.  (This is a guess, this is only a guess).

If you're running 3.2v5.0.x, the NBUF and NHBUF kernel disk buffer
parameters are established dynamically.  Not much you can do there.

However, if you are running 3.2v4.2, SCO sets a limit of 600Kb of
NBUF disk buffering for boot time buffer allocation.  IMHO, this
is much too small.  I usually set NBUF for about 1/4 to 1/3 of real
memory with NHBUF=NBUF/4 rounded up to the nearest power of 2.
Several of my customers machines (one running RM/Cobol) have
achieved dramatic improvements in disk performance.  It doesn't
do anything to sequential access (large file copies and tape backups)
but random access is much better.

For 3.2v4.2, I suggest "The SCO Performance Tuning Handbook" by
Miscovich and Simons, ISBN 0-13-102690-9.  You will also need
to monitor sar output to determine if you're making any progress.

[x] Email to author  [ ] To mailing list  [x] Posted to newsgroup
--
# Jeff Liebermann  Liebermann Design  150 Felker St #D  Santa Cruz  CA  95060

# 408.699.0483 digital_pager    73557,2074  cis [don't]

2. problems to install a 86C362 S3 TRIO 3D2X under X

3. tunable kernel parameters for SCSI H.D.

4. AFIO

5. OSR5.0.0 -- tuneable kernel parameters

6. samba-2.0.7 auth to Win2k encrypted

7. New: Change compile-time option CONFIG_APM_RTS_IS_GMT to sysctl-tunable kernel parameter

8. ATI Xwindows Compatibility

9. Tunable Kernel Parameters

10. List of Tunable kernel parameters

11. Solaris 2.3 tunable kernel parameters

12. Kernel TCP/IP Tunable parameters?

13. kernel tuneable parameters?