From owner-freebsd-current Wed Feb 5 0:43:58 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E44CE37B407; Wed, 5 Feb 2003 00:43:50 -0800 (PST) Received: from riker.skynet.be (riker.skynet.be [195.238.3.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545DC43FCB; Wed, 5 Feb 2003 00:43:45 -0800 (PST) (envelope-from brad.knowles@skynet.be) Received: from [10.0.1.2] (ip-26.shub-internet.org [194.78.144.26] (may be forged)) by riker.skynet.be (8.12.7/8.12.7/Skynet-OUT-2.21) with ESMTP id h158hV2s006059; Wed, 5 Feb 2003 09:43:35 +0100 (MET) (envelope-from ) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <34054.1044430012@critter.freebsd.dk> References: <34054.1044430012@critter.freebsd.dk> Date: Wed, 5 Feb 2003 09:22:55 +0100 To: phk@freebsd.org From: Brad Knowles Subject: Re: Preview: GEOMs statistics code. Cc: "Greg 'groggy' Lehey" , Brad Knowles , current@freebsd.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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, "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