iostat
IOSTAT输出结果解析
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)
[oracle@ora9i ~]$ iostat -x
Linux 2.6.9-78.ELsmp (ora9i.rui) 08/03/2009
avg-cpu: %user %nice %sys %iowait %idle
0.10 0.28 3.18 0.55 95.88
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
hdc 0.01 0.00 0.01 0.00 0.05 0.00 0.03 0.00 8.31 0.00 1.51 1.51 0.00
sda 0.17 3.54 1.57 2.63 43.42 49.40 21.71 24.70 22.07 0.02 4.34 2.27 0.96
sda1 0.14 3.54 1.57 2.63 43.34 49.40 21.67 24.70 22.06 0.02 4.34 2.27 0.96
sda2 0.03 0.00 0.00 0.00 0.04 0.00 0.02 0.00 28.38 0.00 6.09 2.69 0.00
sdb 0.03 0.00 0.00 0.00 0.12 0.01 0.06 0.00 43.85 0.00 7.37 3.45 0.00
sdb1 0.02 0.00 0.00 0.00 0.06 0.01 0.03 0.00 33.11 0.00 10.49 4.64 0.00
Device:
This column gives the device (or partition) name, which is dis-
played as hdiskn with 2.2 kernels, for the nth device. It is dis-
played as devm-n with 2.4 kernels, where m is the major number of
the device, and n a distinctive number. With newer kernels, the
device name as listed in the /dev directory is displayed.
tps
Indicate the number of transfers per second that were issued to
the device. A transfer is an I/O request to the device. Multiple
logical requests can be combined into a single I/O request to the
device. A transfer is of indeterminate size.
Blk_read/s
Indicate the amount of data read from the drive expressed in a
number of blocks per second. Blocks are equivalent to sectors
with 2.4 kernels and newer and therefore have a size of 512
bytes. With older kernels, a block is of indeterminate size.
Blk_wrtn/s
Indicate the amount of data written to the drive expressed in a
number of blocks per second.
Blk_read
The total number of blocks read.
Blk_wrtn
The total number of blocks written.
kB_read/s
Indicate the amount of data read from the drive expressed in
kilobytes per second. Data displayed are valid only with kernels
2.4 and newer.
kB_wrtn/s
Indicate the amount of data written to the drive expressed in
kilobytes per second. Data displayed are valid only with kernels
2.4 and newer.
kB_read
The total number of kilobytes read. Data displayed are valid only
with kernels 2.4 and newer.
kB_wrtn
The total number of kilobytes written. Data displayed are valid
only with kernels 2.4 and newer.
rrqm/s
The number of read requests merged per second that were issued to
the device.
wrqm/s
The number of write requests merged per second that were issued
to the device.
r/s
The number of read requests that were issued to the device per
second.
w/s
The number of write requests that were issued to the device per
second.
rsec/s
The number of sectors read from the device per second.
wsec/s
The number of sectors written to the device per second.
rkB/s
The number of kilobytes read from the device per second.
wkB/s
The number of kilobytes written to the device per second.
avgrq-sz
The average size (in sectors) of the requests that were issued to
the device.
avgqu-sz
The average queue length of the requests that were issued to the device.
await
The average time (in milliseconds) for I/O requests issued to the
device to be served. This includes the time spent by the requests
in queue and the time spent servicing them.
svctm
The average service time (in milliseconds) for I/O requests that
were issued to the device.
%util
Percentage of CPU time during which I/O requests were issued to
the device (bandwidth utilization for the device). Device satura-
tion occurs when this value is close to 100%.
如果 %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。
5. iostat 的 bug 修正
iostat.c 中是这样计算avgqu-sz的:
((double) current.aveq) / itv
aveq 的单位是毫秒，而 itv 是两次采样之间的间隔，单位是 jiffies。必须换
算成同样单位才能相除，所以正确的算法是:
((double) current.aveq) / itv * HZ / 1000
这样，上面 iostat 中输出的 avgqu-sz 值应为 2.23，而不是 22.3。
另外，util值的计算中做了 HZ 值的假设，不是很好，也需要修改。
--- sysstat-4.0.7/iostat.c.orig 2004-07-15 13:31:27.000000000 +0800
+++ sysstat-4.0.7/iostat.c 2004-07-15 13:37:34.000000000 +0800
@@ -370,7 +370,7 @@
nr_ios = current.rd_ios + current.wr_ios;
tput = nr_ios * HZ / itv;
- util = ((double) current.ticks) / itv;
+ util = ((double) current.ticks) / itv * HZ / 1000;
/* current.ticks (ms), itv (jiffies) */
svctm = tput ? util / tput : 0.0;
/* kernel gives ticks already in milliseconds for all platforms -> no need for further scaling */
@@ -387,12 +387,12 @@
((double) current.rd_sectors) / itv * HZ, ((double) current.wr_sectors) / itv * HZ,
((double) current.rd_sectors) / itv * HZ / 2, ((double) current.wr_sectors) / itv * HZ / 2,
arqsz,
- ((double) current.aveq) / itv,
+ ((double) current.aveq) / itv * HZ / 1000, /* aveq is in ms */
await,
/* again: ticks in milliseconds */
- svctm * 100.0,
+ svctm,
/* NB: the ticks output in current sard patches is biased to output 1000 ticks per second */
- util * 10.0);
+ util * 100.0);
}
}
}
一会儿 jiffies, 一会儿 ms，看来 iostat 的作者也被搞晕菜了。
这个问题在 systat 4.1.6 中得到了修正:
* The average I/O requests queue length as displayed by iostat -x was
wrongly calculated. This is now fixed.
但 Redhat 的 sysstat 版本有些太过时了 (4.0.7)。