在具有8个EBS卷和大量磁盘stream量的8路Amazon EC2实例（运行Linux 2.6.21）中，我们看到顶级（30-40％）和高负载平均（8-9）的高％wa。 我的理解是，等待来自EBS卷的I / O的进程被计入负载平均值（一个ps显示D状态中的几个进程，大约与负载平均值一样多）。
但是，不清楚％wa是什么意思。 CPU是否真的被占用，等待EBS卷的响应，还是内核调度另一个进程？ 我预料会有另一个进程安排; 但是我不明白为什么iowait时间会以占CPU总时间的百分比表示（除非百分比加起来超过100％）。
只要我们不关心EBS卷的I / O容量，我并不担心，但是如果CPU等待I / OI，我认为我们的机器在用完之前会耗尽CPU容量/ O容量。
如果至less有一个进程已准备好接收CPU时间，则CPU可以并将用于其他进程。 有蹭 – 你可以有一个I / O绑定的系统，每个进程等待I / O完成，由于没有任何等待CPU时间，没有任何理由安排（和利用）CPU除了内核的活动…因此，术语，I / O 等待 。
尝试运行vmstat 1并定期查看“b”列（第二列）中是否有大于0的数字。 如果是这样，你可能是I / O绑定的。 偶尔看一下并不是什么大不了的事情，看到这个数字在2-3的范围内是可以忍受的，但是不可取，而超过5+就意味着你可能太忙了（尽pipe这取决于多lessI / O你的系统可以容纳，所以它可以更多或更less，具体取决于）。 “b”的意思是“进程被阻塞”，如“计划运行的进程数量，但被阻塞，等待I / O完成”。
跟进：
在2.6系列的内核中，有一个已知的重大I / O和更新的调度器的bug 。 尝试改变您的调度程序，看看它是否有影响。
man vmstat指出：“wa：等待IO的时间，在Linux 2.5.41之前，包含在空闲中。