Relevance of High %iowait in Server Performance
High
%iowait
has historically indicated a problem in I/O performance. However, due toadvances in CPU performance, high
%iowait
may be a misleading indicator, especially inrandom I/O workloads. It's misleading because
%iowait
measures CPU performance, notI/O. To be precise,
%iowait
measures the percent of time the CPU is idle, but waiting for an I/O to complete. As such, it is only indirectly related to I/O performance, which canresult in false conclusions. It is possible to have healthy system with nearly 100% iowait,or have a disk bottleneck with 0% iowait.High
%iowait
is becoming more common as processor speeds increase. Gains in processor performance have significantly outpaced disk performance. While processor performance has doubled every 12 to 18 months, disk performance (in IOPS per disk) hasremained relatively constant* . This imbalance has resulted in a trend toward higher
%iowait
on healthy systems. (* IOPS depend on seek time, which hasn't increased at therate of processor performance. The improvements in storage have been in areas such asareal density (MB/sq. in.) and rotational speed.)The following example illustrates how faster CPU's can increase
%iowait
. Assume weupgrade a system with CPU's that are 4 times faster. All else remains unchanged. Beforethe upgrade, a transaction takes 60 ms which includes 40 ms of CPU time plus 20 ms to perform an IO, and that our application performs one transaction after another in a serialstream.
Before CPU Upgrade
CPU time = 40 msIO time = 20 msTotal transaction time = CPU + IO = 40 + 20 = 60 ms
%iowait
= IO time/total time = 20/60 = 33%
After CPU Upgrade
CPU time = 40 ms/ 4 = 10 msIO time = 20 msTotal transaction time = CPU + IO = 10 + 20 = 30 ms
%iowait
= 20/30 = 66%In this example, transaction performance doubled, despite a 2x increase in
%iowait
. Inthis case, the absolute value of
%iowait
is a misleading indicator of an I/O problems.So, how do you identify an I/O problem if you can't rely on
%iowait
? The best way is tomeasure I/O response times using filemon. As a rule of thumb, read/write time shouldaverage 15-20 ms on non-cached disk subsystems. On cached disk subsystems, readsshould average 5-20 ms, and writes should average 2-3 ms. Higher response timesindicate the storage subsystem is possibly overloaded.Here's an example of a 90 second filemon trace from an actual customer system that washeavily utilized. The filemon command was:
Leave a Comment