<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The difference between %iowait from sar and %util from iostat</title>
	<atom:link href="http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/feed/" rel="self" type="application/rss+xml" />
	<link>http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/</link>
	<description>You will probably want some waders, a pick axe, and one of those hats with a light on it before you go in here.</description>
	<pubDate>Tue, 06 Jan 2009 04:14:07 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Joerg</title>
		<link>http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/#comment-103831</link>
		<dc:creator>Joerg</dc:creator>
		<pubDate>Wed, 05 Mar 2008 18:41:23 +0000</pubDate>
		<guid isPermaLink="false">http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/#comment-103831</guid>
		<description>IMO, "%iowait" is seen from a CPU point of view: No task was runnable, but at least one was waiting for disk IO (which may include paging, AFAIK). If the disk(s) were infinitely fast, the transfer would be done, and the task could continue.
Slightly different: "%iowait" is the (theoretical) limit to throughput improvement you could achieve by getting rid of disk IO (all files in memory, sufficient RAM not to page, ...).

"%util" shows you whether the disk(s) can keep up with the requests issued. When it approaches 100 % for one disk, you *have* to distribute that disk's load to multiple spindles.

You can have heavy disk utilization without waiting for them (low "%iowait") if you have some CPU-consuming background task which does not wait for disk IO. It would keep your CPU(s) busy while other tasks wait for the disk. Computing PI would be a candidate, I assume.

Joerg</description>
		<content:encoded><![CDATA[<p>IMO, &#8220;%iowait&#8221; is seen from a CPU point of view: No task was runnable, but at least one was waiting for disk IO (which may include paging, AFAIK). If the disk(s) were infinitely fast, the transfer would be done, and the task could continue.<br />
Slightly different: &#8220;%iowait&#8221; is the (theoretical) limit to throughput improvement you could achieve by getting rid of disk IO (all files in memory, sufficient RAM not to page, &#8230;).</p>
<p>&#8220;%util&#8221; shows you whether the disk(s) can keep up with the requests issued. When it approaches 100 % for one disk, you *have* to distribute that disk&#8217;s load to multiple spindles.</p>
<p>You can have heavy disk utilization without waiting for them (low &#8220;%iowait&#8221;) if you have some CPU-consuming background task which does not wait for disk IO. It would keep your CPU(s) busy while other tasks wait for the disk. Computing PI would be a candidate, I assume.</p>
<p>Joerg</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sean</title>
		<link>http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/#comment-98294</link>
		<dc:creator>Sean</dc:creator>
		<pubDate>Mon, 25 Feb 2008 17:44:56 +0000</pubDate>
		<guid isPermaLink="false">http://ebergen.net/wordpress/2008/02/25/the-difference-between-iowait-from-sar-and-util-from-iostat/#comment-98294</guid>
		<description>iowait is effectively idle time (in 2.4 kernels, it was rolled up into idle).

I'd be interested in seeing the other numbers (sys, user, idle) for the bonnie++ tests...  If the disks are maxed and only 1% iowait, then user% is probably running at ~99%.

Sean</description>
		<content:encoded><![CDATA[<p>iowait is effectively idle time (in 2.4 kernels, it was rolled up into idle).</p>
<p>I&#8217;d be interested in seeing the other numbers (sys, user, idle) for the bonnie++ tests&#8230;  If the disks are maxed and only 1% iowait, then user% is probably running at ~99%.</p>
<p>Sean</p>
]]></content:encoded>
	</item>
</channel>
</rss>
