From owner-freebsd-hackers Mon Dec 25 12:35:42 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA00293 for hackers-outgoing; Mon, 25 Dec 1995 12:35:42 -0800 (PST) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA00288 for ; Mon, 25 Dec 1995 12:35:40 -0800 (PST) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id OAA04004; Mon, 25 Dec 1995 14:34:25 -0600 From: Joe Greco Message-Id: <199512252034.OAA04004@brasil.moneng.mei.com> Subject: Re: iostat and msps To: bde@zeta.org.au (Bruce Evans) Date: Mon, 25 Dec 1995 14:34:24 -0600 (CST) Cc: Mattias.Gronlund@sa.erisoft.se, bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199512250133.MAA13380@godzilla.zeta.org.au> from "Bruce Evans" at Dec 25, 95 12:33:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > >OK, if we can't calculate msps on new disk's, what is the reason for > >it to still exist? > > They can be calculated accurately for some disks (for floppies and old > uncached wd drives :-) and inaccurately for other cases. Maybe the inaccurate count is better than nothing at all. Solaris does a convincing attempt at gathering statistics on SCSI disks, and even if it is not 100% accurate, it helps an administrator locate the most likely bottleneck drive in a busy filesystem. It also helps when you want to go to management and say "hey, the system statistics claim that the drive is 95% saturated, and the performance tuning book says you have a problem if it's over 30%" (Solaris has a NICE performance tuning book).... Tools I don't have under FreeBSD but would like :-) slowaris% iostat -x 30 extended disk statistics disk r/s w/s Kr/s Kw/s wait actv svc_t %w %b fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd0 11.8 1.2 60.0 6.5 0.0 0.3 28.2 1 29 sd1 6.0 1.9 21.5 7.3 0.0 0.2 26.7 0 14 sd12 44.0 15.9 313.9 102.5 1.1 4.3 90.2 3 75 sd2 10.8 4.6 36.7 15.9 0.0 0.5 34.9 0 24 sd3 3.0 1.5 16.4 10.5 0.1 0.1 57.9 1 10 sd7 0.3 0.4 1.6 1.8 0.0 0.0 27.8 0 2 This is a fairly useful display - "wait" is the avg number of transactions waiting for service, "actv" is the avg # of transactions actively being serviced, svc_t is the average service time in ms, %w is the percent of time that there are transactions waiting for service, and %b is the percent of time the disk is busy (both derived from wait/actv). It clearly shows that sd12 is in some pain.... > >> Lots of things would break even if DK_NDRIVE only increased. systat > >> output wouldn't fit in 80 columns... > > >So, I have checked, the only system binaries that uses the dk_xxx > >variables from /dev/kmem is systat and iostat and I guess that it > >should be possible to fix them if they break :-)... > > I think Joe Greco fixed some things here. I raised DK_NDRIVE (on my local system) and then fixed a bunch of formatting type issues that arose from 4-character device names in systat and iostat, etc.... might hold us for another half a decade :-) I do NOT know whether or not these changes were merged into -current as I don't have any boxes running -current currently. There was one problem I didn't track down relating to the numbers mode of systat -io and unusually sized xterms. My changes were sufficient for a moderately sized system. > >Is it possible that an dynamic implementation of thous statistics could > >be intergrated into FreeBSD-current? > > Someone has to do the work. It would be nice if every driver didn't > have to know how to manage the statistics. They could call (inline) > functions but the placement of the calls is driver-dependent. Always the problem... somebody's gotta do the work :-) :-) Merry Christmas everyone, ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847