From: Ask Questions <askqzama@gmail.com>
To: Herta Van den Eynde <herta.vandeneynde@gmail.com>
Cc: linux-admin@vger.kernel.org
Subject: Re: Interpreting iowait value from output of iostat
Date: Tue, 11 Jan 2011 15:02:04 +0530 [thread overview]
Message-ID: <AANLkTikjpTZDeeGwtEwp9ihRkDps3aBn-VMh1F0RBF0C@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=PFix0c5WsP4P2WMO0zLAM4hm12xkQerS4F01D@mail.gmail.com>
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
<herta.vandeneynde@gmail.com> wrote:
> On 10 January 2011 11:40, Ask Questions <askqzama@gmail.com> wrote:
>> Hi,
>>
>> Need some clarifications on my understanding of iostat command.
>>
>> Pasting the first line of output from this command .
>>
>> $iostat
>> Linux 2.6.32-21-generic (desktop) Monday 10 January 2011 _i686_ (2
>> CPU)
>>
>> avg-cpu: %user %nice %system %iowait %steal %idle
>> 0.09 0.03 0.74 0.07
>> 0.00 99.08
>>
>> My confusion is with the %iowait column. The man page says : iostat
>> "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 there 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 request
>> 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 , we need to check the
>> CPU and memory utilization . There might me a possibility of bad
>> blocks in the disk also .
>>
>> To simulate this , I tried the following .
>>
>> I executed dd if=/dev/zero of=/home/test till the disk is saturated.
>> disk saturation I identified by running the iostat command on another
>> terminal and looking at the %util column after every 5 secs. %iowait
>> was mostly fluctuating within 35.00 when the disk was 100% saturated.
>>
>> After waiting for around 3 minutes , I fired another IO intensive
>> command using dd . The disk was already 100% busy as per the %util
>> 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 coming
>> down .
>>
>> Is my understanding clear . Please clarify
>>
>> Thanks in Advance
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-admin" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> It is exactly what the man page says: it's the time the CPU was idle
> 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. It 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. At 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. Disk
> access is still the slowest operation on the system. So, task 2 will
> be put on hold (uninterruptible sleep, i.e. the "D" status in e.g. "ps
> auxw", i.e. the "b" column in "vmstat") until that I/O is ready to be
> delivered. It 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. At 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 finish
> its time slice, and lower its priority back to normal. The cpu hasn't
> been idle, so your counter won't go up.
>
> Hope this helps.
>
> Kind regards,
>
> Herta
>
> --
> "Life on Earth may be expensive,
> but 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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2011-01-11 9:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-10 10:40 Interpreting iowait value from output of iostat Ask Questions
2011-01-10 21:53 ` Herta Van den Eynde
2011-01-11 9:32 ` Ask Questions [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTikjpTZDeeGwtEwp9ihRkDps3aBn-VMh1F0RBF0C@mail.gmail.com \
--to=askqzama@gmail.com \
--cc=herta.vandeneynde@gmail.com \
--cc=linux-admin@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).