Date: Wed, 5 Feb 2003 09:22:55 +0100 From: Brad Knowles <brad.knowles@skynet.be> To: phk@freebsd.org Cc: "Greg 'groggy' Lehey" <grog@freebsd.org>, Brad Knowles <brad.knowles@skynet.be>, current@freebsd.org Subject: Re: Preview: GEOMs statistics code. Message-ID: <a05200f02ba66778c5b08@[10.0.1.2]> In-Reply-To: <34054.1044430012@critter.freebsd.dk> References: <34054.1044430012@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 8:26 AM +0100 2003/02/05, phk@freebsd.org 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, <brad.knowles@skynet.be>
"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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a05200f02ba66778c5b08>