来！递进下你和iostat的塑料友谊！

       iostat 熟吗？熟又不熟，塑料假闺蜜描述再合适不过。

       熟---体现在使用频率相当高，不熟---很多人都只知其一--util高低代表io的压力大小，但却不知其二，三，四。。。。

        为什么要了解二，三，四等，因为一只是表现，二，三，四等才是因。

        其实网上有太多iostat介绍的文章，篇复一篇，但是正因为多，所以猜更多的人除了uitl指标之外的其他指标都不熟，因为没看到有什么收益，结果就是util简直是iostat代言人。

       下面就结合一个mysql实际案例来助其他指标坐上c位：

        案例背景：1 两台主机，业务指标形态完全相同，表记录数量不分伯仲，但同一个时间分析                                 binlog写入相同表，相同记录数量，一个io util 将近90% ，一个io只有28%左右；

                           2 机型相同，且磁盘都是ssd盘，文件系统也一致，但厂家不同。

                           3  主机侧检查没有raid充放电之类导致io写磁盘等性能降低，也无其他方面故障。

         所以从分析下iostat的各个指标来下手,当时对比看到如下：

   

对应各指标如下：

指标序号	指标意义	io高负载异常机器 具体值	io正常机器具体值	分析	备注
① Device：	对应的设备名称	/sda /nvme0n1	/sda /nvme0n1	io负载高的为nvme0n1， 都是db的数据盘	可结合df -h具体定位是那快盘io高，再根据盘承载的数据，粗略判断是什么数据导致的，比如该案例  sda对应日志表盘， nvme0n1 对应数据盘， 发现是nvme0n1 util高，所以是写数据导致的。
② rrqm/s:	每秒对该设备的读请求被合并次数	0.00	0.00	都无合并	（文件系统会对读取同块(block)的请求进行合并，当 系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）
③ wrqm/s:	每秒对该设备的写请求被合并次数	0.00	0.00	都无合并
④ r/s:	每秒读取的扇区数；	51.00	70.00	高负载：低负载约 1:1
⑤ w/s:	每秒写入的扇区数。	767.00	2030.00	高负载：低负载约 1:3	sector（扇区）是硬件读写的最小操作单元，例如如果一个sector是512字节，fidsk -l 查看两天机器扇区都为512Byte 相同个大小
⑥ rMB/s:	每秒读数据量(MB为单位)	0.80	0.94	高负载：低负载约 1:1
⑦ wMB/s:	每秒写数据量(MB为单位)	9.74	14.59	高负载：低负载约 1:1.5
⑧ avgrq-sz:	平均每次IO操作的数据量(扇区数为单位)	26.39	15.14	高负载：低负载约 1.8：1
⑨ avgqu-sz:	平均等待处理的IO请求队列长度， 毫无疑问，队列长度越短越好	0.91	0.30	高负载：低负载约 3：1
⑩ await:	平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)每一个IO请求的处理的平均时间（单位是微秒毫秒）。	1.11	0.14	高负载：低负载约 10：1	这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。这个时间包括了队列时间和服务时间，也就是说，一般情况下，await大于svctm，它们的差值越小，则说明队列时间越短，反之差值越大，队列时间越长，说明系统出了问题
⑪ r_await	:每个读操作的平均耗时	0.63	0.31	高负载：低负载约 2：1
⑫ w_await：	每个写操作的平均耗时	1.14	0.14	高负载：低负载约8：1
⑬ svctm:	平均每次IO请求的处理时间	1.08	0.14	高负载：低负载约 10：1
⑭ %util:	一秒中有百分之多少的时间用于 I/O 操作	88.20	28.90	高负载：低负载约 3：1	在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）
结合⑧ 、⑪和⑫ ：虽然高负载的每次io操作的扇区是低负载的1.8倍，但是其消耗的时间却是（0.63+1.08/0.31+0.14)约等于3.7，所以io的繁忙指标util 88:20:28.90约等于3.1，由于这是单次统计，和3.7有点偏差，其实大数据多次统计下基本是比较吻合的，所以高负载的机器io读取速度能力较差，

 所以最后结论是：两个机器品牌不同，导致高负载机器尽管每次io读取扇区多，但是耗费时间却长，从而导致util就会一直工作，表现出来就是util 很高，所以最后换了一个和低负载同品牌的机器，io恢复。