Understanding%iowait (%wio)

%iowait is a metric that is displayed when a tool such as "sar-u" Checks CPU usage, is displayed as%iowait on Linux, is displayed as%wio on some UNIX versions, and the meaning is the same, and this indicator is often misread. Many people regard it as a symptom of I/O problem, I myself every once in a while will encounter to%iowait nervous of customers, have to try to explain repeatedly, in fact, this indicator contains very little information, can not be used alone to determine whether the system has I/O problem, here we discuss the real meaning of it in detail, Start with the explanation on the man page:

09:35:06 am CPU%user%nice%system%iowait%steal%idle 09:35:07 am All 0.00 0.00 0.00 0.00 0.00 100.00 09:35:08 am all 0 . Wuyi 0.00 2.53 13.13 0.00 83.84 09:35:09 am All 1.54 0.00 7.69 39.49 0.00 51.28 09:35:10 AM All 2.04 0.00 9.18 39.80 0.00 4 8.98 09:35:11 AM All 1.02 0.00 7.65 40.31 0.00 51.02

Here is some explanation in the man page:

• Linux:

%iowait Percentage of time, the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

1. HP-UX:

%wio idle with some process waiting for I/O (only block I/O, raw I/O, or VM pageins/swapins indicated). 

The Linux and HP-UX Man page describes this metric from two perspectives: Linux looks at I/O and emphasizes that there are still outstanding I/O requests, while HP-UX focuses on processes, emphasizing that there are still processes waiting for I/O, The two are talking about two aspects of the same thing, if it is complete together, that is: at least one I/O request has not been completed and there is a process waiting for it to hibernate , we might as well adopt the wording of Linux,%iowait Indicates that a percentage of the time within a sample period is the following: The CPU is idle and there are still outstanding I/O requests.
There are two common misconceptions about%iowait:

• is to mistakenly assume that%iowait indicates that the CPU is not working

this misunderstanding is too low, the first condition of%iowait is CPU idle, since idle of course can accept running task, just because no process can run, the CPU will enter the idle state. Then why is there no process to run it? Because the process is dormant, waiting for a specific event, such as waiting for a timer, or data from the network, or keyboard input, or waiting for the I/O operation to complete, and so on.

• is to mistakenly assume that%iowait represents a bottleneck for I/O.

Why do people think%iowait is a sign of an I/O problem? Their reason is: "The first condition of the%iowait is that the CPU is idle, meaning that all processes are dormant, the second condition is that there are still outstanding I/O requests, which means that the cause of process hibernation is waiting for I/O, while the%iowait elevation indicates that the number of processes that are dormant due to waiting for I/O is more, Or the process sleeps longer because it waits for I/O. "It sounds plausible, but it's not right: first%iowait does indicate that the CPU is idle, all processes are dormant, and indeed some processes are waiting for I/O, but the%iowait rise does not justify an increase in the number of processes waiting for I/O, nor does it prove that the total waiting time for I/O increases.

Why is it? Take a look at the following two pictures to understand:

The first illustration shows that the changes in the CPU's busy state can affect the size of the%iowait when I/O is exactly the same, and we see that the I/O, regardless of how much, the%iowait value is not affected when the CPU is busy (because%iowait The first prerequisite is that the CPU must be idle), and when the CPU is busy, a portion of I/O falls into the CPU idle time period, which leads to the%iowait rise, and the I/O does not change, but the%iowait is raised, only because the CPU idle time increases, Keep in mind that there are hundreds of processes in the system, and any process can cause changes in CPU and I/O, as%iowait,%idle,%user,%system, and so on are all global, not specific to a process.

Looking at the second picture, it describes another scenario: assuming that the CPU's busy condition remains the same, even if the%iowait rise does not indicate that the I/O load is aggravated, if 2 I/O requests are submitted sequentially, so that I/O is always present throughout the time, then%iowait is 100% If 3 I/O requests are committed at the same time, because the system has the ability to handle multiple I/O simultaneously, the 3 concurrent I/O from start to finish is just like an I/O, with a result of only 50%%iowait, 2 I/O enabling%iowait to reach 100%, 3 I/O%iowait But only 50%, it is obvious that the height of the%iowait and I/O is not necessarily related, but with the concurrency of I/o correlation, so, only by the rise of%iowait can not draw the conclusion that I/O load increases.

This is why the%iowait contains a very small amount of information, it is a very vague indicator, if you see%iowait rise, also need to check the I/O volume has not increased significantly, avserv/avwait/avque and other indicators have not significantly increased, the application has not felt slow, If not, there's nothing to worry about.

This article was reproduced from:http://www.linuxprobe.com/understand-iowait.html

more Linux Dry Goods visit:http://www.linuxprobe.com/

Understanding%iowait (%wio)