Re: Preview: GEOMs statistics code.

[Brad Knowles]

At 8:26 AM +0100 2003/02/05, [EMAIL PROTECTED] wrote:

 Is a disk 100% busy if it has requests outstanding at all times,
 but could handle five times as many requests because they could be
 sorted into the current stream of requests free of cost ?  Or is
 it only 20% busy ?  How do you measure it ?

My understanding was that a disk is 100% busy, if the heads are constantly moving to and fro, and there is no period of time when they aren't being yanked around. In other words, it would be 100% if there is always at least one outstanding request.

Now, these requests could be sorted into a more efficient order and you could continue to get better performance out of a disk even though it is technically 100% busy, but that should show up as the throughput and number of transactions per unit of measurement time continuing to climb, while the %busy remains pegged.

In this scenario, of real concern would be the average service time, %wait, and wait service time statistics. Once the %busy is pegged, %wait is climbing and wsvc_time also starts climbing, you've gotten to a point where there probably isn't anything more that you can squeeze out of that disk. If this situation persists for a significant period of time, then you probably want to get more spindles going for you so that you can eliminate this bottleneck.


What is your time resolution on this sort of thing? Iostat can only report in periods as small as one update per second, so I would hope that you could measure these quantities on a much more frequent basis, thus being able to make a useful calculation of average values over that period of time.

 Responsetime on the other hand is a very reliable estimator of how
 long time you next request is going to take to handle.

Right. That should be relatively low, so long as the disk is less than 100% busy. You still want to pay attention to it, but it shouldn't be much to worry about.

 The correct average queue length is close to a thousand, but the
 sampled number will be just one.  It's random sampling.  Without
 some comparatively expensive math in the kernel I don't think I can
 see a way to return the correct number.

Give us the best you can, and let us know about the resolution issues. So long as we know, we should be okay.

 For truly trying to understand our disk-I/O load, tracelogs will
 be needed (And I fear they will show a lot of interesting phenomena).

Hmm. I'd like to learn more about this tracelog concept. Can you provide any pointers?

--
Brad Knowles, <[EMAIL PROTECTED]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message