目录
iostat主要用于监控系统设备的IO负载情况，iostat首次运行时显示自系统启动开始的各项统计信息，之后运行iostat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。
iostat 例子
-
下面给出几个例子：
# 显示一条包括所有的CPU和设备吞吐率的统计信息 # iostat Linux 2.6.18-53.el5 (cnetos5) 01/21/2008 avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.04 0.37 0.07 0.00 99.42 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sda 1.44 16.79 10.58 800430 504340 sdb 0.01 0.07 0.00 3314 8 sdc 0.86 8.56 0.00 407892 24 # 每隔5秒显示一次设备吞吐率的统计信息（单位为 块/s） iostat -d 5 # 每隔5秒显示一次设备吞吐率的统计信息（单位为 KB/s），共输出3次 iostat -dk 5 3 # 每隔2秒显示一次 sda 及上面所有分区的统计信息，共输出5次 iostat -p sda 2 5 # 每隔2秒显示一次 sda 和 sdb 两个设备的扩展统计信息，共输出6次 iostat -x sda sdb 2 6 Linux 2.6.18-53.el5 (cnetos5) 01/21/2008 avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.04 0.37 0.07 0.00 99.42 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.17 0.84 0.96 0.47 16.67 10.56 19.01 0.01 7.11 1.25 0.18 sdb 0.00 0.00 0.01 0.00 0.07 0.00 5.16 0.00 0.22 0.19 0.00 ………… >iostat -t 5 -x > iostat.out -t是输出时间和日期，5是代表5秒一次，-x是详细情况都输出 主要查看cpu的idle和磁盘的util -
深入理解：深入理解iostat ：深入理解iostat
https://bean-li.github.io/dive-into-iostat/
iostat 的输出项说明
rrqm/s：每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并。每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；
wrqm/s：每秒对该设备的写请求被合并次数/每秒这个设备相关的写入请求有多少被Merge了。
r/s： 该设备的每秒完成的读请求数（merge合并之后的）
w/s: 该设备的每秒完成的写请求数（merge合并之后的）
rKB/s：rkB/s: 每秒读数据量(kB为单位)，每秒发送给该设备的总读请求数 #rMB/s
wKB/s：每秒写数据量(kB为单位)，每秒发送给该设备的总写请求数 #wMB/s
avgrq-sz 平均请求扇区的大小，平均每次IO操作的数据量(扇区数为单位)
avgqu-sz 是平均请求队列的长度。毫无疑问，队列长度越短越好。 平均等待处理的IO请求队列长度
await:平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)。每一个IO请求的处理的平均时间（单位是微秒毫秒）。这里可以理解为IO的响应时间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。
这个时间包括了队列时间和服务时间，也就是说，一般情况下，await大于svctm，它们的差值越小，则说明队列时间越短，反之差值越大，队列时间越长，说明系统出了问题。
r_await:读IO的响应时间
w_await:写IO的响应时间
（该参数已经废止，不可信）svctm: 表示平均每次设备I/O操作的服务时间（以毫秒为单位）。如果svctm的值与await很接近，表示几乎没有I/O等待，磁盘性能很好，如果await的值远高于svctm的值，
则表示I/O队列等待太长，系统上运行的应用程序将变慢。
svctm: 平均每次IO请求的处理时间(毫秒为单位) （该参数已经废止，不可信）
%util： 在统计时间内IO操作的时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒有IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，但不代表已经到达了磁盘性能极限的80%，因为现在的磁盘大多可以并行的，详情见末尾）。
rsec/s：每秒读取的扇区数；
wsec/：每秒写入的扇区数。
-
avg-cpu 部分输出项说明：
%user 在用户级别运行所使用的 CPU 的百分比。 %nice nice 操作所使用的 CPU 的百分比。 %system 在核心级别（kernel）运行所使用 CPU 的百分比。 %iowait CPU 等待硬件 I/O 所占用 CPU 的百分比。 %steal 当管理程序（hypervisor）为另一个虚拟进程提供服务而等待虚拟 CPU 的百分比。 %idle CPU 空闲时间的百分比。 Device 部分基本输出项说明：
tps 每秒钟物理设备的 I/O 传输总量。 Blk_read 读入的数据总量，单位为块。 Blk_wrtn 写入的数据总量，单位为块。 kB_read 读入的数据总量，单位为KB。 kB_wrtn 写入的数据总量，单位为KB。 MB_read 读入的数据总量，单位为MB。 MB_wrtn 写入的数据总量，单位为MB。 Blk_read/s 每秒从驱动器读入的数据量，单位为 块/s。 Blk_wrtn/s 每秒向驱动器写入的数据量，单位为 块/s。 kB_read/s 每秒从驱动器读入的数据量，单位为KB/s。 kB_wrtn/s 每秒向驱动器写入的数据量，单位为KB/s。 MB_read/s 每秒从驱动器读入的数据量，单位为MB/s。 MB_wrtn/s 每秒向驱动器写入的数据量，单位为MB/s。 Device 部分扩展输出项说明：
rrqm/s 将读入请求合并后，每秒发送到设备的读入请求数。 wrqm/s 将写入请求合并后，每秒发送到设备的写入请求数。 r/s 每秒发送到设备的读入请求数。 w/s 每秒发送到设备的写入请求数。 rsec/s 每秒从设备读入的扇区数。 wsec/s 每秒向设备写入的扇区数。 rkB/s 每秒从设备读入的数据量，单位为 KB/s。 wkB/s 每秒向设备写入的数据量，单位为 KB/s。 rMB/s 每秒从设备读入的数据量，单位为 MB/s。 wMB/s 每秒向设备写入的数据量，单位为 MB/s。 avgrq-sz 发送到设备的请求的平均大小，单位为扇区。 avgqu-sz 发送到设备的请求的平均队列长度。 await I/O请求平均执行时间。包括发送请求和执行的时间。单位为毫秒。 svctm发送到设备的I/O请求的平均执行时间。单位为毫秒。（该参数已经废止，不可信）
iostat 中的 %util 指标说明
判断磁盘极限性能误区：只通过iostat 中的 %util 指标确定磁盘是否达到带宽或iops极限
背景：
在判断磁盘是否达到极限性能时，总有人通过 iostat -x 中的 %util 指标来确认磁盘是否带宽带宽或IOPS瓶颈，其实这是不对的，特做如下说明：
结论：
iostat 中的 %util 基本已经没有任何作用了，svctm也没什么参考意义
磁盘是否达到真正极限瓶颈，需要参考通过fio等工具压测出的极限带宽和IOPS值
%util与硬盘设备饱和度
%util表示该设备有I/O（即非空闲）的时间比率，不考虑I/O有多少，只考虑有没有。
对于以上示例输出，我们可以获取到以下信息：
每秒向磁盘上写30M左右数据(wkB/s值)
每秒有91次IO操作(r/s+w/s)，其中以写操作为主体
平均每次IO请求等待处理的时间为120.57毫秒，处理耗时为6.33毫秒
等待处理的IO请求队列中，平均有11.79个请求驻留
以上各值之间也存在联系，我们可以由一些值计算出其他数值，例如：
util = (r/s+w/s) * (svctm/1000)
对于上面的例子有：util = (1+90)*(6.33/1000) = 0.57603
由于现代硬盘设备都有并行处理多个I/O请求的能力，所以%util即使达到100%也不意味着设备饱和了。
举个简化的例子：某硬盘处理单个I/O需要0.1秒，有能力同时处理10个I/O请求，那么当10个I/O请求依次顺序提交的时候，需要1秒才能全部完成，在1秒的采样周期里%util达到100%；而如果10个I/O请求一次性提交的话，0.1秒就全部完成，在1秒的采样周期里%util只有10%。可见，即使%util高达100%，硬盘也仍然有可能还有余力处理更多的I/O请求，即没有达到饱和状态。
那么iostat(1)有没有哪个指标可以衡量硬盘设备的饱和程度呢？很遗憾，没有。
参考文章：
【1】容易被误读的IOSTAT： http://linuxperf.com/?p=156
【2】深入理解iostat： https://bean-li.github.io/dive-into-iostat/
-----------------------------------
©著作权归作者所有：来自51CTO博客作者党志强的原创作品，如需转载，请注明出处，否则将追
https://blog.51cto.com/dangzhiqiang/2440962