yannanqi@126.com wrote:

> system configuration: sco 5.0.6, with about 170 ttys loggedin by
> telnet, two 2G cpu, 4G memory

A buncha other stuff, in ugly format, not worth trying to edit for
quoting.

Your sar output looks reasonable for a system as described. So do the
other utils (modulo a few display bugs in u386mon). The system isn't
swapping at all and has loads more memory than it needs. sarcheck looks
like it isn't prepared to deal with some details of the sar outputs --
is it the latest sarcheck for OSR506?

The big thing missing in all that output is your description of what's
wrong. It looks like a system that has a lot of work to do and is doing
it without complaint. Plus some spurious nonsense from sarcheck. If
the whole problem is the advice from sarcheck, ignore it (ask them for
advice, though...)

The one possibly questionable stat is that the disk is 100% busy. But
you posted a snapshot, we can't tell if that was a momentary burst or
continuous. If it's continuous, the system might benefit from a faster
disk subsystem (faster drive, faster HBA, maybe an external RAID of the
sort that's intended to speed things up rather than or in addition to
giving redundancy -- RAID 0 or RAID 10). Although it's 100% busy, the
delay stats didn't look bad, so I'm not sure if this relates to your
issue.

If there's an actual performance problem, why don't you describe it
instead of posting a morass of details that don't seem to show much
wrong?

In your other message about NBUF:

> On OSR506 platform with 4G memory, the mtune shows:NBUF
> 0 24 450000,that means the maximum value of NBUF is
> 450000,but if I give 1000000 to NBUF,when system starts,it give the
> following message:
>
> kernel: Hz = 100, i/o bufs = 467116k (high bufs = 466092k)CONFIG:
> Buffer allocation was reduced (NBUF reduced to 467116)
>
> (1)That means NBUF gets a value of 467116, where does this number come
> from?

I would guess that 450000 was someone's back-of-napkin calculation
of the most buffers that could guaranteed to be accomodated within
the constraints of other kernel structures. When you demand 1000000
buffers, you cause the kernel to do a live calculation of the same
constraints, only now it has more specific information about certain
structures whose sizes are system-specific. Some of the constraints on
your system aren't quite the theoretical limits, so it can squeeze in a
few more buffers.

You should expect that by demanding the absolute maximum buffers, you
may be invisibly squeezing down the size of other kernel structures.
This could potentially hurt performance or stability. (I'm not saying
that it _does_ hurt, I don't really know.) You can also reasonably
expect that SCO _tested_ with 450000 buffers but not with 467116. I
I doubt the 3.8% increase in buffers is making so much difference in
performance that it's worth running in an untested configuration.

> ps:
> (2) If NBUF has a value other than zero, Is it ok to let NHBUF=0? Can
> NHBUF self-tune according to NBUF when NBUF is not set to zero?

It should auto-tune. You can observe runtime values of these by doing:

# crash
> v | grep buf
v_buf: 450000
v_hbuf: 524288

If you boot with different forced NBUF (v_buf) values, you should see
v_hbuf (NHBUF) float to different values. It's always a power of 2 so
you'll have to make sharp changes to NBUF to see NHBUF change.

> (3)When does MAXBUF have effect, when NBUF is zero or NBUF is not zero?

MAXBUF is an obsolete parameter, no longer edited by configure(ADM), no
longer meaningful to the kernel.

>Bela<