深入理解iostat

iostat算是比较重要的查看块设备运行状态的工具，相信大多数使用linux的同学都用过这个工具，或者听说过这个工具。但是对于这个工具，引起的误解也是最多的，大多数人对这个工具处于朦朦胧胧的状态。现在我们由浅到深地介绍这个工具，它输出的含义什么，介绍它的能力边界，介绍关于这个工具的常见误解。

iostat的用法比较简单，一般来说用法如下：

iostat -mtx 2

含义是说，每2秒钟采集一组数据：

输出的结果如下所示：

注意，上图是在对sdc这块单盘（RAID卡上的单盘）做4KB的随机写入测试：

fio --name=ranDWrite --rw=ranDWrite --bs=4k --size=20G --runtime=1200 --ioengine=libaio --iodepth=64 --numjobs=1 --rate_iops=5000 --filename=/dev/sdf --direct=1 --group_reporting 

因此上图中只有sdc在忙。

如何阅读iostat的输出，各个参数都是什么含义，反映了磁盘的什么信息？

第一列Device比较容易理解，就是说这一行描述的是哪一个设备。

首先我们用超市购物来比对iostat的输出。我们在超市结账的时候，一般会有很多队可以排，队列的长度，在一定程度上反应了该收银柜台的繁忙程度。那么这个变量是avgqu-sz这个输出反应的，该值越大，表示排队等待处理的io越多。

我们搞4K的随机IO，但是iodepth=1 ，查看下fio的指令和iostat的输出：

fio --name=ranDWrite --rw=ranDWrite --bs=4k --size=20G --runtime=1200 --ioengine=libaio --iodepth=1 --numjobs=1 --filename=/dev/sdc --direct=1 --group_reporting 

同样是4K的随机IO，我们设置iodepth=16， 查看fio的指令和iostat的输出：

fio --name=ranDWrite --rw=ranDWrite --bs=4k --size=20G --runtime=1200 --ioengine=libaio --iodepth=16 --numjobs=1 --filename=/dev/sdc --direct=1 --group_reporting 

注意，内核中有I/O Scheduler队列。我们看到因为avgqu-sz大小不一样，所以一个IO时间（await）就不一样。就好像你在超时排队，有一队没有人，而另一队队伍长度达到16 ，那么很明显，队伍长队为16的更繁忙一些。

avgrq-sz这个值反应了用户的IO-Pattern。我们经常关心，用户过来的IO是大IO还是小IO，那么avgrq-sz反应了这个要素。它的含义是说，平均下来，这这段时间内，所有请求的平均大小，单位是扇区，即（512字节）。

上面图中，sdc的avgrq-sz总是8，即8个扇区 = 8*512（Byte） = 4KB，这是因为我们用fio打io的时候，用的bs=4k。

下面我们测试当bs=128k时候的fio指令：

fio --name=ranDWrite --rw=ranDWrite --bs=128k --size=20G --runtime=1200 --ioengine=libaio --iodepth=1 --numjobs=1 --filename=/dev/sdc --direct=1 --group_reporting 

注意sdc的avgrq-sz这列的值，变成了256，即256 个扇区 = 256* 512 Byte = 128KB，等于我们fio测试时，下达的bs = 128k。

注意，这个值也不是为所欲为的，它受内核参数的控制：

这个值不是最大下发的IO是256KB，即512个扇区。当我们fio对sdc这块盘做测试的时候，如果bs=256k，iostat输出中的avgrq-sz 会变成 512 扇区，但是，如果继续增大bs，比如bs=512k，那么iostat输出中的avgrq-sz不会继续增大，仍然是512，表示512扇区。

fio --name=ranDWrite --rw=ranDWrite --bs=512k --size=20G --runtime=1200 --ioengine=libaio --iodepth=1 --numjobs=1 --filename=/dev/sdc --direct=1 --group_reporting 

注意，本来512KB等于1024个扇区，avgrq-sz应该为1204，但是由于内核的max_sectors_kb控制参数，决定了不可能：

另外一个需要注意也不难理解的现象是，io请求越大，需要消耗的时间就会越长。对于块设备而言，时间分成2个部分：

注意此处的寻道不能简单地理解成磁盘磁头旋转到指定位置，因为后备块设备可能是RAID，可能是SSD，我们理解写入前的准备动作。准备工作完成之后，写入4K和写入128KB，明显写入128KB的工作量要更大一些，因此很容易理解随机写入128KB给块设备带来的负载要比随机写入4K给块设备带来的负载要高一些。

对比生活中的例子，超时排队的时候，你会首先查看队列的长度来评估下时间，如果队列都差不多长的情况下，你就要关心前面顾客篮子里东西的多少了。如果前面顾客每人手里拿着一两件商品，另一队几乎每一个人都推这满满一车子的商品，你可能知道要排那一队。因为商品越多，处理单个顾客的时间就会越久。IO也是如此。

块设备有相应的调度算法。如果两个IO发生在相邻的数据块时，他们可以合并成1个IO。

这个简单的可以理解为快递员要给一个18层的公司所有员工送快递，每一层都有一些包裹，对于快递员来说，最好的办法是同一楼层相近的位置的包裹一起投递，否则如果不采用这种算法，采用最原始的来一个送一个（即noop算法），那么这个快递员，可能先送了一个包括到18层，又不得不跑到2层送另一个包裹，然后有不得不跑到16层送第三个包裹，然后包到1层送第三个包裹，那么快递员的轨迹是杂乱无章的，也是非常低效的。

linux常见的调度算法有： noop deadline和cfq。此处不展开了。

我们还是以超时购物为例，比如一家三口去购物，各人买各人的东西，最终会汇总到收银台，你固然可以每人各自付各自的，但是也可以汇总一下，把所有购买的东西放在一起，由一个人来完成，也就说，三次收银事件merge成了一次。

至此，我们以超时购物收银为例，介绍了avgqu-sz 类比于队伍的长度，avgrq-sz 类比于每个人购物车里物品的多少，rrqm/s和wrqm/s 类比于将一家购得东西汇总一起，付费一次。还有svctm和%util两个没有介绍。

按照我们的剧情，我们自然而然地可以将svctm类比成收银服务员服务每个客户需要的平均时间，%util类比成收银服务员工作的繁忙程度。

注意这个类比是错误的，就是因为类似的类比，容易让人陷入误区不能自拔。不能简单地将svctm理解成单个IO被块设备处理的有效时间，同时不能理解成%util到了100% ，磁盘工作就饱和了，不能继续提升了，这是两个常见的误区。

svctm和%util是iostat最容易引起误解的两个输出。为了准确地评估块设备的能力，我们希望得到这样一个数值：即一个io从发给块设备层到完成这个io的时间，不包括其他在队列等待的时间。从表面看，svctm就是这个值。实际上并非如此。

linux下iostat输出的svctm并不具备这方面的含义，这个指标应该非废弃。iostat和sar的man page都有这方面的警告：

那么iostat输出中的svctm到底是怎么来的，%util又是怎么算出来的，进而iostat的输出的各个字段都是从哪里拿到的信息呢？

iostat数据的来源是linux *** 作系统的/proc/diskstats:

注意，procfs中的前三个字段：主设备号、从设备号、设备名。这就不多说了。

从第四个字段开始，介绍的是该设备的相关统计：

这些字段大多来自内核的如下数据：

除了in_flight来自：

内核相关的代码如下：

因为你上课讲话， 让老师批评你5分钟，班里有50人，50个人你就浪费了全班250分钟。

注意avgrq-sz来自xds的argsz变量，该变量是通过该函数计算得到的：

注意nr_ios来自如下运算，即读IO和写IO的和

那么xds->arqsz 的计算就是如下含义：

OK非常容易理解，而且计算也是很合理的。

平均队列长度的计算，这个计算就用到了diskstats中time_in_queue这个值。

这个值的计算来自这句话：

S_VALUE(ioj->rq_ticks,ioi->rq_ticks,itv) / 1000.0) 

其中rq_ticks即diskstats中的time_in_queue。

我们考虑如下的场景，如果IO请求有一个burst，同一时间来了250个IO请求，后续再也没有新的请求到来。这种情况下，每个请求处理时间都是4ms，那么所有IO的平均等待时间为：

平均等待时间 = 单个请求处理时间*(1+2+3+4...+(请求总数-1))/请求总数

对于我们这个例子而言，平均等待时间是4*125 = 500 ms

那么所有IO花费的总时间为250*500=125000毫秒，这个时间除以1000毫秒：

125000/1000 = 125

即平均下来，队列的长度是125 ，这个值很明显是符合直观的。排在队列最前端的IO认为，队列的长度是0，第2个IO认为队列的长度是1，第3个IO认为队列的长度是2，最后一个认为队列的长度是249。

我们换一种思路来考虑，即diskstats中time_in_queue的思路。

当第一个IO完成的时候，队列中250个IO，250个IO都等了4ms，即time_in_queue + = (250*4) ，当第二个IO完成的时候，time_in_queue += (249*4)，当所有IO都完成的时候，time_in_queue = 4*(250+249+248….+1)， …

根据time_in_queue/1000,殊途同归地获得了平均队列长度。

这个没啥好说的了：

await = ((所有读IO的时间)+(所有写IO的时间))/((读请求的个数) + (写请求的个数)) 

注意一点就行了，这个所有读IO的时间和所有写IO的时间，都是包括IO在队列的时间在内的。不能一厢情愿地认为，是磁盘控制器处理该IO的时间。

注意，能不能说，await比较高，所以武断地判定这块盘的能力很菜？答案是不能。await这个值不能反映硬盘设备的性能。await的这个值不能反映硬盘设备的性能，await这个值不能反映硬盘设备的性能，重要的话讲三遍。

我们考虑两种IO的模型：

第一种情况await高达500ms，第二个情况await只有4ms，但是都是同一块盘。

但是注意await是相当重要的一个参数，它表明了用户发起的IO请求的平均延迟：

await = IO 平均处理时间 + IO在队列的平均等待时间 

因此，这个指标是比较重要的一个指标。

注意，%util是最容易让人产生误解的一个参数。很多初学者看到%util 等于100%就说硬盘能力到顶了，这种说法是错误的。

%util数据源自diskstats中的io_ticks，这个值并不关心等待在队里里面IO的个数，它只关心队列中有没有IO。

和超时排队结账这个类比最本质的区别在于，现代硬盘都有并行处理多个IO的能力，但是收银员没有。收银员无法做到同时处理10个顾客的结账任务而消耗的总时间与处理一个顾客结账任务相差无几。但是磁盘可以。所以，即使%util到了100%，也并不意味着设备饱和了。

最简单的例子是，某硬盘处理单个IO请求需要0.1秒，有能力同时处理10个。但是当10个请求依次提交的时候，需要1秒钟才能完成这10%的请求，，在1秒的采样周期里，%util达到了100%。但是如果10个请一次性提交的话， 硬盘可以在0.1秒内全部完成，这时候，%util只有10%。

因此，在上面的例子中，一秒中10个IO，即IOPS=10的时候，%util就达到了100%，这并不能表明，该盘的IOPS就只能到10，事实上，纵使%util到了100%，硬盘可能仍然有很大的余力处理更多的请求，即并未达到饱和的状态。

下一小节有4张图，可以看到当IOPS为1000的时候%util为100%，但是并不意味着该盘的IOPS就在1000，实际上2000，3000,5000的IOPS都可以达到。根据%util 100%时的 r/s 或w/s 来推算磁盘的IOPS是不对的。

那么有没有一个指标用来衡量硬盘设备的饱和程度呢。很遗憾，iostat没有一个指标可以衡量磁盘设备的饱和度。

对于iostat这个功能而言，%util固然会给人带来一定的误解和苦扰，但是svctm给人带来的误解更多。一直以来，人们希望了解块设备处理单个IO的service time，这个指标直接地反应了硬盘的能力。

回到超市收银这个类比中，如果收银员是个老手， *** 作流，效率很高，那么大家肯定更愿意排这一队。但是如果收银员是个新手，各种 *** 作不熟悉，动作慢，效率很低，那么同样多的任务，就会花费更长的时间。因此IO的平均service time（不包括排队时间）是非常有意义的。

但是service time和iostat无关，iostat没有任何一个参数能够提供这方面的信息。而svctm这个输出给了人们这种美好的期待，却只能让人空欢喜。

从现在起，我们记住，我们不能从svctm中得到自己期待的service time这个值，这个值其实并没有什么意义，事实上，这个值不是独立的，它是根据其他值计算出来的。

如果一个盘的能力很强悍，随机小IO（4K）fio测试中我们会看到如下现象：当IOPS为1000的时候，iosta输出的svctm为1(ms)，当IOPS为2000的时候，iostat输出的svctm为0.5(ms),当IOPS为3000的时候，iostat输出的svctm为0.33。原因其实无他，因为这种情况下%util都是100%，即当采样周期是1秒的时候，用满了1秒，tput就是fio指定的–rate-iops 即1000、2000、3000，因此算出来svctm为对应的1、0.5、0.33。

（注意上面的盘sdg是iSCSI，存储空间是由分布式存储提供，不要问我为什么单个盘随机IOPS能无压力的到5000）

因此从这个例子看，把iostat的输出中的svctm看作是IO的处理时间是相当不靠谱的。为了防止带来的误解，可以直接忽略这个参数。

既然svctm不能反映IO处理时间，那么有没有一个参数可以测量块设备的IO平均处理时间呢？很遗憾iostat是做不到的。但是只要思想不滑坡，办法总比困难多，blktrace这个神器可能得到这个设备的IO平均处理时间。

接下来我们就可以进入另一个天地。

iostat能够提供给我们的信息就这么多了，通过分析我们期待能够得到块设备处理IO的时间，这就要靠blocktrace这个工具了。blktrace可以讲IO路径分段，分别统计各段的消耗的时间。

本文大量参考vmunix的容易被误读的IOSTAT，以及深入分析diskstats，其中第二篇文章给出了一个很详细的IO PATH的流程图，非常有用。第二篇文章中随着代码演进有一些变化，本文采用的比较新的linux Kernel code做介绍，同时演算io_ticks和time_in_queue部分第二篇文章也有错误，也一并修正了。不过瑕不掩瑜，这两篇都是非常棒的文章。向前辈致敬。

以上是内存溢出为你收集整理的深入理解iostat全部内容，希望文章能够帮你解决深入理解iostat所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。