【转载】iostat输出解析

【转载】iostat输出解析

2009-10-22 20:26

iostat在内核2.4和内核2.6中数据来源不太一样，所以我们分别就这两中系统介绍iostat的输出。     1. 内核2.4 iostat输出解析 对于kernel 2.4, iostat 的数据的主要来源是 /proc/partitions。 1.1   /proc/partition 先看看 /proc/partitions 中有些什么。 # cat /proc/partitions major     minor     #blocks     name     rio       rmerge     rsect     ruse 3         0       19535040     hda     12524     31127     344371   344360 wio       wmerge   wsect       wuse     running   use       aveq 12941     25534     308434     1097290   -1       15800720   28214662 下面是每项数据的说明： major:   主设备号。 minor:   次设备号。 #blocks: 设备总块数 (1024 bytes/block)。 name:     设备名称。如 hda7。 rio:     完成的读 I/O 设备总次数。指真正向 I/O 设备发起并完成的读操作数目，        也就是那些放到 I/O 队列中的读请求。注意很多进程发起的读操作        (read())很可能会和其他的操作进行 merge，不一定每个 read() 调用        都引起一个 I/O 请求。 rmerge:   进行了 merge 的读操作数目。 rsect:   读扇区总数 (512 bytes/sector) ruse:     从进入读队列到读操作完成的时间累积 (毫秒)。上面的例子显示从开机          开始，读 hda7 操作共用了约340秒。 wio:     完成的写 I/O 设备总次数。 wmerge:   进行了 merge 的写操作数目。 wsect:   写扇区总数 wuse:     从进入写队列到写操作完成的时间累积 (毫秒) running: 已进入 I/O 请求队列，等待进行设备操作的请求总数。上面的例子显        示 磁盘上请求队列长度为 0。 use:     扣除重叠等待时间的净等待时间 (毫秒)。一般比 (ruse+wuse) 要小。比        如5 个读请求同时等待了 1 毫秒，那么 ruse值为5ms, 而 use值为          1ms。use 也可以理解为I/O队列处于不为空状态的总时间。hda7 的I/O          队列非空时间为 509 秒，约合8分半钟。     aveq:     在队列中总的等待时间累积 (毫秒) (约等于ruse+wuse) 1.2   iostat 结果解析 # iostat   -x Linux 2.4.21-9.30AX (localhost)         avg-cpu:   %user   %nice     %sys   %idle            3.85     0.00     0.95   95.20 Device:     rrqm/s     wrqm/s     r/s       w/s     rsec/s     wsec/s     /dev/hda     1.70         1.70       0.82     0.82     19.88     20.22 rkB/s       wkB/s       avgrq-sz   avgqu-sz   await   svctm       %util 9.94         10.11       24.50     11.83     57.81   610.76     99.96 每项数据的含义如下， rrqm/s:     每秒进行 merge 的读操作数目。即 rmerge/s wrqm/s:     每秒进行 merge 的写操作数目。即 wmerge/s r/s:       每秒完成的读 I/O 设备次数。即 rio/s w/s:       每秒完成的写 I/O 设备次数。即 wio/s rsec/s:     每秒读扇区数。即 rsect/s wsec/s:     每秒写扇区数。即 wsect/s rkB/s:     每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。 wkB/s:     每秒写K字节数。是 wsect/s 的一半。 avgrq-sz:   平均每次设备I/O操作的数据大小 (扇区)。即 (rsect+wsect)/(rio+wio) avgqu-sz:   平均I/O队列长度。即 aveq/1000 (因为aveq的单位为毫秒)。 await:     平均每次设备I/O操作的等待时间 (毫秒)。即 (ruse+wuse)/(rio+wio) svctm:     平均每次设备I/O操作的服务时间 (毫秒)。即 use/(rio+wio) %util:     一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O队列是非空的,即use/1000 (因为use的单位为毫秒), 如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。      svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)， svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多 也会间接导致 svctm 的增加。 await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。    队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是 按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。 1.3   一个例子 # iostat -x 1 avg-cpu:   %user   %nice     %sys   %idle            16.24     0.00     4.31   79.44 Device:     rrqm/s     wrqm/s       r/s         w/s     rsec/s     wsec/s   /dev/cciss 0.00       44.90         1.02       27.55     8.16       579.59 rkB/s       wkB/s       avgrq-sz     avgqu-sz   await   svctm       %util 4.08       289.80     20.57         22.35       78.21     5.00       14.29                上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: io/s = r/s +w/s = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。    平均每次设备 I/O 操作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是 同时发出的，那么平均等待时间可以这样计算:      平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数.      应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 给出的 78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。      每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)， 这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。      一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。    (ruse+wuse)/io = await = 78.21 => (ruse+wuse)/s =78.21 * (io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。      iostat.c 中是这样计算avgqu-sz的:          ((double) current.aveq) / itv      aveq 的单位是毫秒，而 itv 是两次采样之间的间隔，单位是 jiffies。必须换 算成同样单位才能相除，所以正确的算法是:      (((double) current.aveq)/1000) / (itv /HZ) 这样，上面 iostat 中输出的 avgqu-sz 值应为 2.23，而不是 22.3。 2. 内核2.6 iostat输出解析 在2.6中，数据来源主要是/proc/diskstats和/sys/block/sd*/stat这两个文件，下面分别介绍这两个文件中各项数据的含义。 2.1 /proc/diskstats cat /proc/diskstats | grep sda 8     0   sda   470792   145771   62327442   3897542   11350   2076   276664 326820 0 2416014 4224415    8     1 sda1 7386 252826 7444 65336      8     2 sda2 609103 62074384 4220 197216      其信息与2.4中/proc/partition类似，但没有标题栏，上面的信息中首先是磁盘的信息，后面接着的是磁盘分区的信息。 我们首先看磁盘的信息，总共有14列信息(标记为红色的部分)。 Field 1 : 磁盘主设备号(major) Field 2 : 磁盘次设备号(minor) Field 3 : 磁盘的设备名(name) Field 4 : 读请求总数(rio) Field 5 : 合并的读请求总数(rmerge) Field 6 : 读扇区总数(rsect) Field 7 :   读数据花费的时间，单位是ms.(从__make_request到 end_that_request_last)(ruse) Field 8 :   写请求总数(wio) Field 9 :   合并的写请求总数(wmerge) Field 10 : 写扇区总数(wsect) Field 11 : 写数据花费的时间，单位是ms. (从__make_request到 end_that_request_last)(wuse) Field 12 : 现在正在进行的I/O数(running),等于I/O队列中请求数 Field 13 : 系统真正花费在I/O上的时间，除去重复等待时间(aveq) Field 14 : 系统在I/O上花费的时间(use)。 我们再看分区信息（标记为紫色的部分） 这部分信息比较简单，除了前面的主次设备号和设备名外，后面依次分别是：读请求数，读扇区数，写请求数，写扇区数。 2.2 /sys/block/sd*/stat Cat /sys/block/sda/stat 470792   145771 62327442   3897542     11359     2078   276752   327045         0   2416053   4224640 这些数据其实与/proc/diskstats中除设备号与设备名外的其它数据是一一对应关系，只是统计的方法略有差别而已。   1. /proc/partitions iostat 的数据的主要来源是 /proc/partitions，所以需要先看看 /proc/partitions 中有些什么。 # cat /proc/partitions major minor #blocks name rio rmerge rsect ruse wio wmerge wsect wuse running use aveq 3 0 19535040 hda 12524 31127 344371 344360 12941 25534 308434 1097290 -1 15800720 28214662 3 1 7172991 hda1 13 71 168 140 0 0 0 0 0 140 140 3 2 1 hda2 0 0 0 0 0 0 0 0 0 0 0 3 5 5116671 hda5 100 477 665 620 1 1 2 30 0 610 650 3 6 265041 hda6 518 92 4616 2770 257 3375 29056 143880 0 46520 146650 3 7 6980211 hda7 11889 30475 338890 340740 12683 22158 279376 953380 0 509350 1294120 major: 主设备号。3 代表 hda。 minor: 次设备号。7 代表 No.7 分区。 #blocks: 设备总块数 (1024 bytes/block)。19535040*1024 => 20003880960(bytes) ~2G name: 设备名称。如 hda7。 rio: 完成的读 I/O 设备总次数。指真正向 I/O 设备发起并完成的读*作数目， 也就是那些放到 I/O 队列中的读请求。注意很多进程发起的读*作 (read())很可能会和其他的*作进行 merge，不一定每个 read() 调用 都引起一个 I/O 请求。 rmerge: 进行了 merge 的读*作数目。 rsect: 读扇区总数 (512 bytes/sector) ruse: 从进入读队列到读*作完成的时间累积 (毫秒)。上面的例子显示从开机 开始，读 hda7 操作共用了约340秒。 wio: 完成的写 I/O 设备总次数。 wmerge: 进行了 merge 的写操作数目。 wsect: 写扇区总数 wuse: 从进入写队列到写*作完成的时间累积 (毫秒) running: 已进入 I/O 请求队列，等待进行设备*作的请求总数。上面的例子显 示 hda7 上的请求队列长度为 0。 use: 扣除重叠等待时间的净等待时间 (毫秒)。一般比 (ruse+wuse) 要小。比 如 5 个读请求同时等待了 1 毫秒，那么 ruse值为5ms, 而 use值为 1ms。use 也可以理解为I/O队列处于不为空状态的总时间。hda7 的I/O 队列非空时间为 509 秒，约合8分半钟。 aveq: 在队列中总的等待时间累积 (毫秒) (约等于ruse+wuse) 2. iostat 结果解析 # iostat -x Linux 2.4.21-9.30AX (localhost) 2004年07月14日 avg-cpu: %user %nice %sys %idle 3.85 0.00 0.95 95.20 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util /dev/hda 1.70 1.70 0.82 0.82 19.88 20.22 9.94 10.11 24.50 11.83 57.81 610.76 99.96 /dev/hda1 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 12.92 0.00 10.77 10.77 0.00 /dev/hda5 0.02 0.00 0.00 0.00 0.03 0.00 0.02 0.00 6.60 0.00 6.44 6.04 0.00 /dev/hda6 0.01 0.38 0.05 0.03 0.43 3.25 0.21 1.62 46.90 0.15 193.96 52.25 0.41 /dev/hda7 1.66 1.33 0.76 0.79 19.41 16.97 9.70 8.49 23.44 0.79 51.13 19.79 3.07 rrqm/s: 每秒进行 merge 的读*作数目。即 delta(rmerge)/s wrqm/s: 每秒进行 merge 的写*作数目。即 delta(wmerge)/s r/s: 每秒完成的读 I/O 设备次数。即 delta(rio)/s w/s: 每秒完成的写 I/O 设备次数。即 delta(wio)/s rsec/s: 每秒读扇区数。即 delta(rsect)/s wsec/s: 每秒写扇区数。即 delta(wsect)/s rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。 wkB/s: 每秒写K字节数。是 wsect/s 的一半。 avgrq-sz: 平均每次设备I/O*作的数据大小 (扇区)。即 delta(rsect+wsect)/delta(rio+wio) avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。 await: 平均每次设备I/O*作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio) svctm: 平均每次设备I/O*作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio) %util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。 即 delta(use)/s/1000 (因为use的单位为毫秒) 如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘 可能存在瓶颈。 svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)， svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多 也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用 得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑 更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。 队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标，但由于 avgqu-sz 是 按照单位时间的平均值，所以不能反映瞬间的 I/O 洪水。 3. I/O 系统 vs. 超市排队 举一个例子，我们在超市排队 checkout 时，怎么决定该去哪个交款台呢? 首当 是看排的队人数，5个人总比20人要快吧? 除了数人头，我们也常常看看前面人 购买的东西多少，如果前面有个采购了一星期食品的大妈，那么可以考虑换个队 排了。还有就是收银员的速度了，如果碰上了连钱都点不清楚的新手，那就有的 等了。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人 去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情 比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。 I/O 系统也和超市排队有很多类似之处: r/s+w/s 类似于交款人的总数 平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数 平均服务时间(svctm)类似于收银员的收款速度 平均等待时间(await)类似于平均每人的等待时间 平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少 I/O 操作率 (%util)类似于收款台前有人排队的时间比例。 我们可以根据这些数据分析出 I/O 请求的模式，以及 I/O 的速度和响应时间。 4. 一个例子 # iostat -x 1 avg-cpu: %user %nice %sys %idle 16.24 0.00 4.31 79.44 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util /dev/cciss/c0d0 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29 /dev/cciss/c0d0p1 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29 /dev/cciss/c0d0p2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: delta(io)/s = r/s + w/s = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1)。 平均每次设备 I/O *作只需要 5ms 就可以完成，但每个 I/O 请求却需要等上 78ms，为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个)，假设这些请求是 同时发出的，那么平均等待时间可以这样计算: 平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + ... + 请求总数-1) / 请求总数 应用到上面的例子: 平均等待时间 = 5ms * (1+2+...+28)/29 = 70ms，和 iostat 给出的 78ms 的平均等待时间很接近。这反过来表明 I/O 是同时发起的。 每秒发出的 I/O 请求很多 (约 29 个)，平均队列却不长 (只有 2 个 左右)， 这表明这 29 个请求的到来并不均匀，大部分时间 I/O 是空闲的。 一秒中有 14.29% 的时间 I/O 队列中是有请求的，也就是说，85.71% 的时间里 I/O 系统无事可做，所有 29 个 I/O 请求都在142毫秒之内处理掉了。 delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s = 78.21 * delta(io)/s = 78.21*28.57 = 2232.8，表明每秒内的I/O请求总共需 要等待2232.8ms。所以平均队列长度应为 2232.8ms/1000ms = 2.23，而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35，为什么?! 因为 iostat 中有 bug，avgqu-sz 值应为 2.23，而不是 22.35。