近些年，存储技术飞速发展，有些OS命令的输出结果如果用老的思路去分析，就很容易进入误区。本文不是一篇iostat的科普文，我将深入解析的是大家使用iostat时常遇的问题。iostat 是sysstat工具包中重要的一员，而sysstat工具包在各类Linux操作系统中都适用，所以本文具有一定的普适性。
本文核心内容是，iostat实时看到的util%和svctm值只适用于传统硬盘时代，现在已不可取，需重新解读。
目录
通过SSD盘压测，解读util%的差异
Iostat命令核心条目解读
核心问题阐述及解释
正确解读iostat命令的方法
通过SSD盘压测，解读util%的差异
压测采用同一块SSD盘，SSD盘分配的盘符为sdb1，请注意两次压测的不同之处。
第一次压测结果（A）：
第一次压测命令：
第二次压测结果(B)：
第二次压测命令：
从这里我们可以明显看出，%util值和svctm值是存在很大问题的，都是100%，为什么IOPS一个只达到1416，而另外一个却可以达到9342。
通过下面一步步的解释，希望可以帮助大家解除疑惑。
Iostat命令核心条目解读
在解释之前，首先简单科普一下相关条目的意思。
1、r/s + w/s：就是当前的IOPS（每秒IO数量）
2、await：请求队列中等待时间+svctm(服务时间) ，单位是毫秒，按照每次IO平均。
3、svctm:
IO平均服务时间指物理设备处理时间，不包含主机层面的排队等待时间，所以理论上应为不变值。
服务时间包括磁头寻道时间（目前平均为3毫秒）+旋转延迟时间（磁盘转速相关）+数据传输时间（简单计算时可忽略不计)
旋转延迟时间一般以旋转一周时间的1/2表示。
7200转的为 60/7200/2 =0.00416666..秒=4.17毫秒
15000转为 60/15000/2=0.002秒=2毫秒
4、%util：设备使用率，越接近100，表示压力越大。
核心问题阐述及解释
通过之前两次压测结果，我们初步得到以下两点：
1、%util达到100%并不能表示压力完全繁忙。
2、svctm理应为一个不变的物理执行时间，却发生了变化，这到底为什么？
1 为什么%util值不再代表正确繁忙度？之前有一个错误观点，认为%util达到100%磁盘就已经完全繁忙了，其实并不是。
机械硬盘时代（比如15000转的盘），在物理层面是串行的，一个时间只能干一个活。虽然有各种级别的concurrency，但并不是真正的并行。
SSD,RAID 则不同。他们可以真正在物理层面上并行执行多个IO。可以同时物理执行多个IO。
%util的计算 有一个简单的算法：
concurrency = (r/s + w/s) * (svctm / 1000)
%util = concurrency * 100%
然而这个concurrency 是个伪命题，因为svctm也是通过计算而来的，无论怎样压，算出来的concurrency都是1左右，那么自然util% 乘以出来就是100%
举例说明：
一个快递员的繁忙程度(uti%)是看这个快递员在一定时间内，真正用于工作的时间是多少。
统计时间为10分钟，如果10分钟内快递员一口水都没喝，都在跑来跑去地忙活。那么我们可以认定繁忙率是100%
这就是util%的计算方法。这种方法对于单块机械磁盘(串行IO)没有任何问题。
技术在进步，出现了SSD以及RAID后，我们就可以并行的执行IO。
在刚刚的例子中，这个快递员变成了漩涡鸣人，会分身术，它可以分出15个分身，一起出去送快递。
但原本的算法，只盯着漩涡鸣人本身，10分钟内跑来跑去，就认为他100%繁忙。
其实他真正的百分百繁忙时，应该是本身和15个分身，总计16个漩涡鸣人全部跑来跑去送快递。
在快递员会分身术后，util%算法便有了局限性。
看了这个例子，大家应该知道通过查看%util来确认压力大小已经非常不可取了。
2 为什么svctm值会发生变化？上面解释%util就已经说到了，因为svctm是被计算出来的。而这个算法对于非单块机械盘（RAID,SSD）并不适用。
这一点在sysstat最新文档中已经注明。
正确解读iostat命令的方法
1 我们怎样获得真正的serviice time(svctm)?这里给大家提供一个得到真正svctm的办法。
我们可以通过fio等压测工具，通过设置为同步IO，仅设置一个线程，io_depth也设置为1，压测出来的就是真正的service time(svctm)，如果结果1
2 我们怎样获得某磁盘或lun的io最大并行度，如何获得真正的util%使用率？我们继续看算出util%的公式是什么：
concurrency = (r/s + w/s) * (svctm / 1000) %util = concurrency * 100%
这个公式的前提是svctm是个不变的固定物理处理时间。但是我们可以从上面的两次压测结果看出其时间也是计算出来，随着iops增加，svctm相应减少。自然该公式无论如何算都是100%。
我们首先带入第二次压测结果
concurrency = (9342 + 0) * (0.11 / 1000)
concurrency = 1.02762
第二次util%还是显示100%，这是根据公式推出的答案，但是此结果是错误的。
我想到一个办法，我们将svctm带入成一个常量，即我们之前第一次压测出来的真正物理处理时间。结果如下：
concurrency = （9342+0） * (0.61 / 1000) =5.63762
concurrency = 5.63762
util% = 563.762%
我们可以通过写小工具，调用iostat -x的结果，并且将实时svctm替换为事先压测好的真实svctm（实际物理处理时间），这样就可以算出真实的util%时间
3 算出真实的最大并行度有什么用？那么现在，如果我们不写工具，怎么根据现有的iostat值，加上之前的压测成果，判断是否繁忙呢？
现在已知util% ，svctm 都不准确。我们这里应该参考avgqu-sz。
avgqu-sz：超过处理能力的请求数目，待处理的 I/O 请求，当请求持续超出磁盘处理能力，该值将增加。
我们通过实际经验得到，当该值持续超过读写能力的1.5倍时，就表示磁盘十分繁忙。
网上的一些文章中会写到，如果该值超过2那么可以认定磁盘繁忙，其实这是一种过时的理论。
这里的2，也是基于单块机械硬盘的IO能力得出的经验结论。我们之前说过，单块机械硬盘为串行化IO，物理层面同时只能有一个IO在处理（即处理能力为1）。
那么这里的等待处理为2，是对应于磁盘处理能力为1。
那么当RAIDs 或者 SSD等并行方式，如我们压测的磁盘通过上面带入正确值的公式，我们可以实现并行度为5.63，根据之前理论，应该是超过5.63的两倍，如11.26，而不再是一个固定的值2。是否为2在当前情况已经无法判断是否繁忙。
我们这里通过压测得知，在ssd或raid情况下，等待基本不可能达到读写能力的两倍，1.5倍基本就代表非常繁忙， 而1倍的时候就需要注意了。
这里我们看第二个压测结果的qvgqu-sz值为9.21。
压测满时的等待处理io值为9.21，并行度为5.63。
9.21/5.63=1.63
从值看出，在压满的情况下，avgqu-sz为并行度的1.6倍左右。
我们可以得出结论：在事先有压测结果，知道并行度的情况下，我们可以通过查看avgqu-sz是否为并行度的1.5倍来判断该磁盘是否繁忙。
还有一个更简单主观的识别方法，即当svctm和await时间相差过大（await>>svctm）时，就可判断系统层面已经排队时间过高了，此时系统IO压力很大，要引起注意了。
但是该方法只适合经验派使用，因为它无法给出一个精准的值作为参考，也无法作为问题的发现依据写入文档。
如果你还有什么疑惑，可以将问题写在评论中，我们可以一起探讨分析。
作者介绍：代海鹏
新炬网络资深数据库工程师。
5年+Oracle维护经验，曾为中国人寿、中国移动、国家电网等大型企业提供数据库技术支持服务。
擅长数据库性能优化、故障诊断。
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-03-15
