IOSTAT中关于%util，svctm存在的陷阱及解决办法_iostat %util

在写瓶颈确认之IO瓶颈确认之第一篇这篇博客以前，自认为对IO情况确认还是没问题的。

在写博客时，对以前理解并不确切的地方进行了深入了解。 在经过理解后，发现之前并不是不确切，而是有部分理解错误的地方，现在特意在上一篇的基础上整改一篇出来，而不是进行直接在原基础修改，就是希望可以给大家提个醒，也给自己提个醒。

重点提示：实时看到的util%和svctm全部都不可取

------------------iostat -x 每项内容解释 可在上面所述blog中查看--

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdb1              0.01     0.44  0.24  0.57     3.44     8.14    14.34     0.00    2.28   0.66   0.05

avgrq-sz：就是当前每秒平均吞吐量 单位是扇区（512b)

await：请求队列中等待时间+svctm(服务时间)     单位是毫秒，按照每次IO平均。

svctm:IO平均服务时间

          服务时间包括:磁头寻道时间(目前平均为3毫秒)+旋转延迟时间（磁盘转速相关)+数据传输时间（简单计算时可忽略不计)

                                   旋转延迟时间详解：一般以旋转一周时间的1/2表示

                                                                       7200转的为 60/7200/2 =0.00416666..秒=4.17毫秒

                                                                      15000转为   60/15000/2=0.002秒=2毫秒

%util：之前最大的误解，错误观点 100%就是磁盘已经完全繁忙了，其实并不是。

             机械硬盘，在物理层面是串行的，既是一个时间只能干一个活，虽然有各种级别的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来确认压力是否大已经非常不可取了

 在sysstat网站的最新文档中也已经注明： But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.  文档地址：http://sebastien.godard.pagesperso-orange.fr/man_iostat.html

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           8.04    0.00   14.57   27.14    0.00   50.25

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
.
.
.
sdb1              0.00     0.00 1416.00  0.00 22656.00     0.00    16.00     0.86    0.61   0.61  100.00

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               7.00     0.00 20.00  0.00  1360.00     0.00    68.00     0.06    3.15   2.90   5.80
.
.
.
sdb1              0.00     0.00 9342.00  0.00 149472.00     0.00    16.00     9.21    0.99   0.11 100.10

我们这里应该参考avgqu-sz：超过处理能力的请求数目，待处理的 I/O 请求，当请求持续超出磁盘处理能力，该值将增加。

                                网上标准说持续超过2就应该警示，具体值大家在工作中自己摸索

                                具体指什么，如一块机械盘，串行IO(每次1个IO），那么avgqu-sz持续大于2既代表持续有两倍读写能力的IO请求在等待。

                                那么当RAIDs 或者 SSD等并行，这里假定并行度为5.63，那么 avgqu-sz持续大于10，才代表持续有两倍读写能力的IO请求在等待。