Slow system performance

[spddmon]

Hello.
A client has a 5.0.5 patched with 505a, that at times performs very slow. They have 2 remote sited that connect via a multimux, yes all serial devices, only a few ethernet. A ttal of 32 users at a time a re connected 16 hours aday.
there is 512 MB RAM, a lot od swap space. the command swap -l always indicates its not being used, which mens memory is sufficient. the only thing I could find is when I do a sar -b, it indicated a bottleneck at the scsi hard drive;89% or higher. The machine is a HPLC3, 36 GIG SCSI HD, and embeded dual cjannel scsi controller.
I am looking for ways to improve performance. Can anyone give tips and pointers please. Thank you

 

[stanhubble]

How much extra memory is there at peak usage? (sar -r)
what is the primary use of the system?
what are the disk i/o buffers set to?

 

[apeasecpc]

Am I correct in understanding that you have a total of 1 36G hard drives?

You would get much better performance with a multiple drive array because of the data striping. Even a 2 drive array should significantly improve your performance.

I recommend some kind of caching raid controller with a large amount of cache (i.e. 512M or more). You will get the best performance with raid 0 (which does not mirror the data over the array).

 

[spddmon]

apeasecpc, thank you, yes it is a 1 hard drive, and I agree about the raid, however, at this point the client is refusing to do any kind of hardware upgrades.
Stanhubble, thank you for replying. The system is used mainly for medical billing software based on acucobol, character based. Some report generating using old software that I know eats up a lot of resources, also Word perfect for SCO which is also rough around the edges.
For other questions, I will have to get back to you on that between 3:00-6:30 PM, as I can't locate the info I already have. But if you mean the NBUF, NHBUF and MAXBUFF, I tried playing around with that but got a little intimidated with "the power of 2" stuff...etc. I sure can use some help there.

 

[stanhubble]

The amount of extra ram they have will determine how much you can increase the i/o buffers.
Since it is a cobol based application it will probably benefit from increased i/o buffers as opposed to a RDBMS system that can sometimes slow down with increased buffers.
A lot of the tuning guidelines are from the 386/486 days when ram, disk and cpu speeds were very limited compared to today's machines.

As an example, on a machine with 512MB ram serving up to 40+ users, some of the changes we make in stune:

MAXBUF 32767
NHBUF 65535
NBUF 32767
NINODE 400
NFILE 400
NPROC 400
MAXUP 200
NCALL 70
NAUTOUP 1
BDFLUSHR 1

-------------
note: the nautoup and bdflushr may be counter productive depending on how the application does updates.

Again it depends on the amount of ram available at peak usage ( sar -r )