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@xxxxxxxxx> wrote: > On 10 January 2011 11:40, Ask Questions <askqzama@xxxxxxxxx> 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
