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
