Date: Wed, 05 Feb 2003 08:26:52 +0100 From: phk@freebsd.org To: "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: Brad Knowles <brad.knowles@skynet.be>, current@freebsd.org Subject: Re: Preview: GEOMs statistics code. Message-ID: <34054.1044430012@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 05 Feb 2003 11:52:14 %2B1030." <20030205012214.GG12525@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030205012214.GG12525@wantadilla.lemis.com>, "Greg 'groggy' Lehey" writes: >2. %busy. I personally think this is the most important one, but as > you say, there's no reason not to do the others as well. The problem with this one is that we can't measure it in a way which tells us the truth, and we may not even be able to find a meaningful definition of "the truth": Is a scsi disk busy if it has received one request but has 64 tagged-queing openings ? Is it idle ? is it 1/64 busy ? 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 ? Responsetime on the other hand is a very reliable estimator of how long time you next request is going to take to handle. >3. Average number of requests waiting. > >> I don't have a queue-depth as such, but I have number of >> transactions in transit. Will a snapshot of that at the time of the >> read do what you want ? > >What's the difference? I would have thought that's the same thing. 1.000 read statistics, find 1 item in queue 1.001 1000 requests arrive 1.999 999 of them + the first one finish 2.000 read statistics, find 1 item in queue 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. Of course the transaction rate for the above example will be 1000/sec but it will not say if those were handled one at a time or if they arrived in one large pile like above. 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). Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@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. 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?34054.1044430012>