iostat用于监控cpu的统计信息和磁盘的统计信息
[oracle@localhost ~]$ iostat
Linux 2.6.9-78.ELsmp (localhost) 09/29/2010
avg-cpu: %user %nice %sys %iowait %idle
0.18 0.00 0.08 0.02 99.72
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 8.48 26.06 111.87 6429617 27601457
sda1 0.00 0.00 0.00 628 0
sda2 0.00 0.01 0.00 1654 33
sda3 8.48 26.05 111.87 6426351 27601424
dm-0 14.65 26.04 111.87 6425698 27601424
dm-1 0.00 0.00 0.00 360 0
cpu的统计信息,如果是多cpu系统,显示的所有cpu的平均统计信息。
%user:用户进程消耗cpu的比例
%nice:用户进程优先级调整消耗的cpu比例
%sys:系统内核消耗的cpu比例
%iowait:等待磁盘io所消耗的cpu比例
%idle:闲置cpu的比例(不包括等待磁盘io的s)
磁盘的统计信息:
Device:设备的名称
Tps:设备上每秒的io传输(可能多个io被组成一个io)的次数
Blk_read/s:每秒从设备读取block(kernel 2.4以上,block=512byte)的数量
Blk_wrtn/s:每秒写到设备block(kernel 2.4以上,block=512byte)的数量
Blk_read:间隔时间内,从设备读取总的block数量
Blk_wrtn:间隔时间内,写到设备总的block数量
默认iostat不带任何参数显示的是概要信息,如果要看更比较详细的信息,可以用“iostat –x“,例子如下:
[root@localhost ~]# iostat -x
Linux 2.6.9-78.ELsmp (localhost) 09/30/2010
avg-cpu: %user %nice %sys %iowait %idle
0.14 0.00 0.07 0.01 99.78
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.04 5.08 0.46 6.74 19.21 94.55 9.60 47.27 15.80 0.01 0.93 0.18 0.13
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 26.17 0.00 3.08 2.83 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 17.57 0.00 0.99 0.84 0.00
sda3 0.03 5.08 0.46 6.74 19.20 94.55 9.60 47.27 15.80 0.01 0.93 0.18 0.13
dm-0 0.00 0.00 0.49 11.82 19.19 94.55 9.60 47.27 9.24 0.36 29.58 0.11 0.13
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 8.00 0.00 6.22 0.62 0.00
字段说明:
rrqm/s:每秒进行merge(多个io的合并)读操作的数量
wrqm/s:每秒进行merge(多个io的合并)写操作的数量
r/s:每秒完成读io设备的次数
w/s:每秒完成写io设备的次数
rsec/s:每秒读扇区的次数
wsec/s:每秒写扇区的次数
rkB/s:每秒读多少k字节,在kernel2.4以上,rkB/s=2×rsec/s,因为一个扇区为512bytes
wkB/s:每秒写多少k字节,在kernel2.4以上,wkB/s =2×wsec/s,因为一个扇区为512bytes
avgrq-sz:平均每次io设备的大小(以扇区为单位),因为有merge读或写,所以每次io大小需要计算
avgqu-sz:平均I/O队列长度
await:每次io设备的等待时间,也包括io服务时间(毫秒)。
await的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。
如果 svctm 比较接近 await,说明I/O 几乎没有等待时间;
如果 await 远大于 svctm,说明 I/O队列太长,应用得到的响应时间变慢,
如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator算法,优化应用,或者升级 CPU。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水
svctm:每次io设备的服务时间(毫秒),它的大小一般和磁盘性能有关:CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加
%util:处理io操作的cpu比例,如果这个着接近100%,说明io请求非常多,cpu的所有时间都用来处理io请求,io系统负载很大(也有可能cpu资源不足),磁盘可能存在瓶颈;在%util等于70%的时候,io的读取就会有很多等待。
下面是别人写的这个参数输出的分析
# 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 操作: 总IO(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 是空闲的。