Comments on: iostat -x

By: flytox

flytox — Wed, 20 May 2009 07:43:40 +0000

an interesting reading to share on the same subject : http://www.slideshare.net/PerconaPerformance/your-disk-array-is-slower-than-it-should-be

By: Interesting Items - April 27, 2009 | Oxidiser techblog

Interesting Items - April 27, 2009 | Oxidiser techblog — Mon, 27 Apr 2009 10:07:16 +0000

[...] iostat -x [...]

By: Dev Blog AF83 » Blog Archive » Veille technologique : Design, Navigateurs, Optimisations, Javascript, Ruby, Rails, Agilité, Outils

Tue, 24 Mar 2009 17:58:29 +0000

[...] http://dammit.lt/2009/03/11/iostat/ : iostat, un outil pour surveiller les I/O [...]

By: Isotopp

Isotopp — Wed, 18 Mar 2009 09:40:50 +0000

A relatively new tool in the Linux toolbox that I find increasingly useful is btrace (part of the sysstat package) on a sufficiently recent kernel.

By: Michael Renner

Michael Renner — Sat, 14 Mar 2009 19:48:25 +0000

The device utilization (%util) doesn’t let you know anything about how the underlying physical devices are used (unless your logical device maps to exactly one physical device).

What the device utilization shows is the percentage of time between two measurements, for which the logical device had outstanding I/Os (hence: “Was busy”). See Documentation/iostats.txt in Linux and the iostat source for details.

Nice summary though, highly appreciated!

By: Mike MacCana

Mike MacCana — Sat, 14 Mar 2009 16:48:07 +0000

hehe, I know you didn’t write the manual Domas, but it could be worth reporting the upstream documentation as being a little misleading.

By: Marius Gedminas

Marius Gedminas — Sat, 14 Mar 2009 14:43:42 +0000

I think you misspelt %iowait as %iostat in one place.

Personally, I like %iowait. It’s the amount of time that your CPU(s) is (are) idling because all runnable programs are blocked waiting for I/O. It’s useful when you want to get an overview of what your system is doing, and perhaps less useful if you’re only interested in the I/O side.

By: Kord Campbell

Kord Campbell — Sat, 14 Mar 2009 14:36:29 +0000

If you want to graph the results over time, download the free version of Splunk from their website and then add a small scripted input to run ‘iostat -x’ every minute or so.

You’ll end up using a command called |multikv to split the lines and fields out for graphing. Usually takes about 15 minutes to get all of it running – and it’s FREE!

By: Stephen P. Schaefer

Stephen P. Schaefer — Sat, 14 Mar 2009 05:05:20 +0000

Assuming (large assumption) that requests are for random places on the disk, I would expect the elevator algorithm to cause less wait for disk head motion per request for a larger number of requests than for a smaller number. The assumption may be entirely wrong; for all I know, there is naturally emerging locality of activity, and it will of course differ between database indexes and video delivery.

By: Domas Mituzas

Domas Mituzas — Fri, 13 Mar 2009 23:13:28 +0000

@Mike, I didn’t write the manual ;-) The formula for svctime is quite clear ( svctm = (await*%util)/avgqu-sz * 100) ) ) – so, bigger queue is, smaller svctm is.

By: Mike MacCana

Mike MacCana — Fri, 13 Mar 2009 22:11:31 +0000

Or, to make it short: where is it documented that svctime is a measure of throughput, and why does this differ from ‘time to be served’ per the manual?

By: Mike MacCana

Mike MacCana — Fri, 13 Mar 2009 22:10:19 +0000

@Domas: I know that’s what you’re saying, but it seems to differ from the documentation. According to the man page service time is ‘The average service time (in milliseconds) for I/O requests that were issued to the device.’ I read this as the time taken to respond to requests (hence my statement that slower response = more service time), but this may be misleading – I gather you’re saying it’s the opposite, but why? Is the man page wrong or misleading?

By: Domas Mituzas

Domas Mituzas — Fri, 13 Mar 2009 18:53:23 +0000

@Mike, ergh, svctm would go up because of _less_ outstanding parallel requests (more parallelism = higher overall throughput)

By: Mike MacCana

Mike MacCana — Fri, 13 Mar 2009 17:04:09 +0000

From the article:
“Actually, less you load your system, higher svctm is (as there’re more outstanding requests, and average time to serve them goes up). ”

Are you sure about that? Why would less load result in more outstanding requests and higher service time?

By: David Cartwright

David Cartwright — Wed, 11 Mar 2009 23:09:13 +0000

@Don

Thanks.

yum install sysstat

is also needed on Fedora 10.

By: Matt Y

Matt Y — Wed, 11 Mar 2009 22:41:37 +0000

Could agree more, I love, no I ABSOLUTLEY LOVE IT! Iostat its one of the most useful tools I have found:) Its truly amazing how many people have never seen it or used it before.

By: Didier Spezia

Didier Spezia — Wed, 11 Mar 2009 22:24:09 +0000

Actually, it is reading 40 MB/s (81848.00/2048), and not 80 MB/s.

By: Don McArthur

Don McArthur — Wed, 11 Mar 2009 17:12:17 +0000

For the information of readers using CentOS and unable to find iostat installed or via yum, do ‘yum install sysstat’ instead.