iowait
Contents
iowait
iowait 表示在一个采样周期内有百分之几的时间属于以下情况: CPU空闲、并且有仍未完成的 I/O 请求。
对 %iowait 常见的误解有两个: 一是误以为 %iowait 表示 CPU不能工作的时间, 二是误以为 %iowait 表示 I/O有瓶颈。
首先 %iowait 升高并不能证明等待 I/O的进程数量增多了, 也不能证明等待 I/O的总时间增加了。 例如, 在 CPU繁忙期间发生的 I/O, 无论IO是多还是少, %iowait都不会变；当 CPU繁忙程度下降时, 有一部分 IO落入CPU空闲时间段内, 导致%iowait升高。 再比如, IO的并发度低, %iowait就高；IO的并发度高, %iowait可能就比较低。
可见 %iowait是一个非常模糊的指标, 如果看到 %iowait 升高 ,还需检查I/O量有没有明显增加, avserv/avwait/avque 等指标有没有明显增大, 应用有没有感觉变慢,如果都没有,就没什么好担心的。
iowait 的含义为有进程在等 io操作结束 (备份进程) , 并且在等待 io操作结束的过程中, 无其他进程占用cpu, cpu处于空闲状态, 故根据iowait参数无从判断io负载情况,还需要通过iostat来判断备份期间io负载情况 (如备份期间磁盘写性能是否已达瓶颈等)
%iowait = (cpu idle time)/(all cpu time) 说明: 高速cpu会造成很高的 iowait值,但这并不代表磁盘是系统的瓶颈。唯一能说明磁盘是系统瓶颈的方法,就是很高的read/write时间,一般来说超过20ms,就代表了不太正常的磁盘性能。为什么是20ms呢？一般来说,一次读写就是一次寻到+一次旋转延迟+数据传输的时间。由于,现代硬盘数据传输就是几微秒或者几十微秒的事情,远远小于寻道时间 (seek time) 2~20ms和旋转延迟4~8ms,所以只计算这两个时间就差不多了,也就是15~20ms。只要大于20ms,就必须考虑是否交给磁盘读写的次数太多,导致磁盘性能降低了。
iostat 分析
如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
idle小于70% IO压力就较大了,一般读取速度有较多的wait。
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
await 的参数也要多和 svctm 来参考。差的过高就一定有 IO 的问题。
avgqu-sz 也是个做 IO 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 IO 也会很小.如果数据拿的大,才IO 的数据会高。也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的。
另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间；如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。
别人一个不错的例子(I/O 系统 vs. 超市排队)
举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了。还有就是收银员的速度了,如果碰上了连 钱都点不清楚的新手,那就有的等了。另外,时机也很重要,可能 5 分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。
Author -
LastMod 2017-03-31