Re: gstat shows > 100% busy

In message <42616D77.2070205_at_centtech.com>, Eric Anderson writes:

>> The reason why I don't want to spend cpu time on the %busy field
>> is that it is useless as a performance indication for all modern
>> disks and most ancient ones as well.
>
>Why is that?  I have a general notion, but I'd like to know more details.  If 
>this is documented somewhere, just give me a pointer and I'll read away.

Busy says how big a fraction of the time the disk had an outstanding
request, but that doesn't tell you how much more traffic it would
be able to sneak in without affecting the throughput of the current
traffik.

If you had a process doing essentially:

	while (1) {
		read_sector(0);
		write_sector(N-1);
	}

That would give you 100% disk busy.  But you can throw a lot more traffic
at the disk without affecting (the abysmal) performance you already see,
for instance you can probably read the first and last tracks of the disks
for 100% free.

The trouble is that %busy says something about how much of the time the
disk had something to do, but says nothing about how much more the disk
could have accomplished in the same time.

>> The "ms/r" and "ms/w" give you the time it takes to send a transaction
>> through (in milliseconds, for read and write respectively) and those
>> are the numbers you should monitor.

These on the other hand are what people really care about: how fast
(or slow) will it be to access the disk.  If you run a disk benchmark
you will notice that the service time has seismographic sensitivity,
run a stupid access pattern and it explodes into the 100s of
milliseconds.

>Is there a place to grab those stats in a more 'script friendly'
>way?  I am the author of a (rather cheesy) tool called bsdsar, and
>I'm thinking about updating it with all the new cool 5.X-isms.

Go for it.  There is a pretty simple API to pull it out of the
kernel, check the gstat source.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.