Re: Interpreting iowait value from output of iostat

Thanks Herta . You explanation is clear and simple and it helps to
understand clear . I will come back again if I have further doubts .



On Tue, Jan 11, 2011 at 3:23 AM, Herta Van den Eynde
<[email protected]> wrote:
> On 10 January 2011 11:40, Ask Questions <[email protected]> wrote:
>> Hi,
>>
>> Need some clarifications on my understanding of =A0iostat command.
>>
>> Pasting the first line of output from this command .
>>
>> $iostat
>> Linux 2.6.32-21-generic (desktop) =A0 =A0 =A0 Monday 10 January 2011=
 =A0_i686_ =A0(2
>> CPU)
>>
>> avg-cpu: =A0%user =A0 %nice =A0%system =A0%iowait =A0 =A0%steal =A0 =
%idle
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0.09 =A0 =A0 =A0 0.03 =A0 =A0 =A0 0.=
74 =A0 =A0 =A0 =A0 0.07
>> 0.00 =A0 =A0 99.08
>>
>> My confusion is with the %iowait column. The man page says : =A0 ios=
tat
>> "show the percentage of time that the CPU or CPUs were idle during
>> which the system had an outstanding disk I/O request ".
>>
>> So , what I understood is that when the CPU is mostly idle and have
>> free cycles, and =A0there is an IO request , the CPU can immediately
>> handle it since it has free cycles. Now if the CPU is 100% busy and
>> has no free cycles to handle an IO request , and there is a IO reque=
st
>> during that time , %iowait value is expected to increase based on my
>> understanding as the the request is waiting because CPU is busy and
>> has no free cycles left.
>>
>> So , if there is an increase in IO wait time , =A0we need to check t=
he
>> CPU and memory utilization . =A0There might me a possibility of bad
>> blocks in the disk also .
>>
>> To simulate this , I tried the following .
>>
>> I executed dd if=3D/dev/zero of=3D/home/test =A0till the disk is sat=
urated.
>> disk saturation I identified by running the iostat command on anothe=
r
>> terminal and looking at the %util column after every 5 secs. %iowait
>> was mostly fluctuating within 35.00 when the disk was 100% saturated=
=2E
>>
>> After waiting for around 3 minutes , I fired another IO intensive
>> command using dd . =A0The disk was already 100% busy as per the %uti=
l
>> column. Now since the disk is fully saturated and has no free cycles
>> for the next dd command , I can see the %iowait went to around 70.00
>> and was fluctuating between and 50 and 70.
>>
>> I terminated the second dd command and can see value of %iostat comi=
ng
>> down .
>>
>> Is my understanding clear . Please clarify
>>
>> Thanks in Advance
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-admi=
n" in
>> the body of a message to [email protected]
>> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>>
>
> It is exactly what the man page says: =A0it's the time the CPU was id=
le
> and has to wait on the results of an I/O request before it can
> continue its operation.
> More concretely, if you'd give it something else to do in the
> meantime, it'd be happy to work on that.
>
> Linux is a time-sharing OS. =A0It means that it tries to give a fair
> chunk of cpu time (known as a time slice) to all the tasks that are
> ready to run on the cpu.
>
> For the sake of simplicity, let's assume we have a computer with only
> one cpu and two tasks waiting on the cpu.
>
> The scheduler starts task 1 on the cpu, until its time slice is
> consumed. =A0At that time, the scheduler will interrupt it, and give
> task 2 its fair chunk.
>
> Now, suppose that task 2 requires data to be read from the disk. =A0D=
isk
> access is still the slowest operation on the system. =A0So, task 2 wi=
ll
> be put on hold (uninterruptible sleep, i.e. the "D" status in e.g. "p=
s
> auxw", i.e. the "b" column in "vmstat") until that I/O is ready to be
> delivered. =A0It will also increase the priority of that task.
>
> If there is no other task ready to run on the cpu, the cpu is idle,
> waiting on I/O, and your iowait counter will go up.
>
> If task 1 has unfinished business, that task will get the cpu, until
> the I/O is ready to be delivered. =A0At that time, task 2 will change
> state from sleeping to runable, and as it has a higher priority than
> task 1, the scheduler will interrupt task 1 and place it back on the
> runable queue, and give the cpu back to task 2 where it can now finis=
h
> its time slice, and lower its priority back to normal. =A0The cpu has=
n't
> been idle, so your counter won't go up.
>
> Hope this helps.
>
> Kind regards,
>
> Herta
>
> --
> "Life on Earth may be expensive,
> =A0but it comes with a free ride around the Sun."
>
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" =
in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html