iostat vmstat系统分析

最新推荐文章于 2025-08-13 18:01:09 发布

原创最新推荐文章于 2025-08-13 18:01:09 发布 · 131 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#MySQL #算法 #Linux #Cache

linux常用命令专栏收录该内容

8 篇文章

订阅专栏

本文通过iostat和vmstat工具详细分析了Linux系统的CPU利用率、磁盘I/O性能及内存使用情况等关键指标，并提供了判断系统瓶颈的方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

[size=medium][b]iostat[/b][/size]
# 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延迟问题的。

[b]结果详解：[/b]
% 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的单位为毫秒)

[b]简单分析：[/b]
如果 %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 洪水。

[size=medium][b]vmstat[/b][/size]
# 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

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

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

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

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

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

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