From owner-freebsd-current@FreeBSD.ORG Sat Apr 16 19:55:14 2005 Return-Path: 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 CC69116A4CE for ; Sat, 16 Apr 2005 19:55:14 +0000 (GMT) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A0143D41 for ; Sat, 16 Apr 2005 19:55:14 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.22] (andersonbox2.centtech.com [192.168.42.22]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j3GJtCRj041839 for ; Sat, 16 Apr 2005 14:55:12 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42616D77.2070205@centtech.com> Date: Sat, 16 Apr 2005 14:54:31 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050325 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current References: <3703.1113680811@critter.freebsd.dk> In-Reply-To: <3703.1113680811@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/833/Fri Apr 15 21:31:36 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: gstat shows > 100% busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 19:55:14 -0000 Poul-Henning Kamp wrote: > In message <42616975.9060303@centtech.com>, Eric Anderson writes: > > >>Is gstat supposed to show > 100% sometimes? What does that mean, >>or is it a bug? >> >>dT: 0.501 flag_I 500000us sizeof 240 i -1 >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 2 260 146 14912 10.7 114 14565 2.8 148.1| ad0 >> 0 0 0 0 0.0 0 0 0.0 0.0| ad0s1 > > > The reason gstat shows >100% busy is that there are some outstanding > requests. (the 2 in the left hand column). > > I tried to make the statistics collection as cheap as possible, and > as a side effect some of the columns can be somewhat misleading. Makes perfect sense, and I was thinking that was the case. I love how fast and non-cpu intensive it is. I use this tool like *crazy* on my servers. Thanks for writing it! > The length of the queue "L(q)" can be plain wrong due to a race in > updating the counters and %busy can go over 100% while there are > outstanding requests. > > The sysctl kern.geom.collectstats can be used to tune some aspects > of the statistics collection, but the %busy issue is just something > you have to live with. > > 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. > 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. Thanks! I've been reading man pages and such trying to figure out what else is cool I'm missing. I just happened to stumble into the tool while messing with ggate (another really awesome tool). 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. Thanks for the quick responses! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------