iostat vmstat系统分析

iostat
[root@hqu-mysql ~]# iostat -x
Linux 2.6.9-89.0.15.ELsmp (hqu-mysql)   2009年11月25日

avg-cpu:  %user   %nice    %sys %iowait   %idle
                   7.95       0.00       5.96       1.24      84.85

Device:    rrqm/s wrqm/s   r/s   w/s  rsec/s  wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz await  svctm  %util
ida/c0d0     0.03   7.54  6.29  7.11   94.87  117.22    47.44    58.61    15.84     1.09       81.67   4.51   6.04
ida/c0d0p1   0.03   7.54  6.29  7.11   94.87  117.22    47.44    58.61    15.84     1.09       81.68   4.51   6.04
ida/c0d0p2   0.00   0.00  0.00  0.00    0.00    0.00     0.00     0.00        45.66     0.00       12.72  10.03   0.00
数据库应该是有硬盘io延迟问题的。

结果详解：
% user      显示了在用户级（应用程序）执行时产生的 CPU 使用率百分比。
% sys       显示了在系统级（内核）执行时产生的 CPU 使用率百分比。
% idle       显示了在 CPU 空闲并且系统没有未完成的磁盘 I/O 请求时的时间百分比。
% iowait   显示了 CPU 空闲期间系统有未完成的磁盘 I/O 请求时的时间百分比。

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 洪水。

vmstat
[root@sends ~]# vmstat -a 2
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r  b   swpd   free  inact active   si   so    bi    bo   in    cs us sy id wa
2  0      0 589428 847744 2391492    0    0     1    21    3     6 23 13 64  0
2  0      0 585972 848296 2394760    0    0     0    62 1076   754 21 33 46  0
1  0      0 589108 848796 2390680    0    0     0     0 1077   702 22 33 46  0
1  0      0 629604 825368 2374436    0    0     0    30 1024   685 20 32 47  0
1  0      0 631012 825368 2372948    0    0     0    20 1029   682 21 33 46  0


结果分析：
Procs
r:等待执行的任务数
b:处在非中断睡眠状态的进程数
展示了正在执行和等待CPU资源的任务个数。当这个值超过了CPU数目，就会出现CPU瓶颈了

Memory
swpd:正在使用的swap大小单位K
free:空闲的内存空间
buff:已使用的buff大小，对块设备的读写进行缓冲
cache:已使用的cache大小，文件系统的cache
inact:
active:

Swap
si:交换内存使用，由磁盘调入内存
so:交换内存使用，由内存调入磁盘

IO
bi:从块设备读入的数据总量(读磁盘) (KB/s)
bo:写入到块设备的数据总理(写磁盘) (KB/s)

System
in:每秒产生的中断次数
cs:每秒产生的上下文切换次数
上面这2个值越大，会看到由内核消耗的CPU时间会越多

CPU
us:用户进程消耗的CPU时间百分比
us 的值比较高时，说明用户进程消耗的CPU时间多，但是如果长期超过50% 的使用，那么我们就该考虑优化程序算法或者进行加速了
sy:内核进程消耗的CPU时间百分比
sy 的值高时，说明系统内核消耗的CPU资源多，这并不是良性的表现，我们应该检查原因。
id:空闲
wa:IO等待消耗的CPU时间百分比
wa 的值高时，说明IO等待比较严重，这可能是由于磁盘大量作随机访问造成，也有可能是磁盘的带宽出现瓶颈(块操作)。