iostat -xz 1重点看 %util(磁盘有多忙)和 await(每次 I/O 等多久)。
约 1185 字大约 4 分钟
2026-05-14
I/O 是最容易被忽略的瓶颈。CPU 和内存有明显的数字告警,I/O 慢却常常表现为“说不上哪里坏,就是整体卡”。学会看 I/O 指标,你才能解释 CPU 与 load average 里那个“load 高但 CPU 不满”的谜题。
理解 I/O 瓶颈如何表现为响应慢和高 load,会用 iostat 看磁盘利用率和延迟,用 iotop 定位是哪个进程在猛读写。
iostat -xz 1重点看 %util(磁盘有多忙)和 await(每次 I/O 等多久)。
iotop -o-o 只显示真正有 I/O 的进程,定位元凶。
vmstat 1wa 列就是 CPU 等 I/O 的占比,持续高说明卡在 I/O。
dmesg | tailI/O 异常慢时,看内核有没有报磁盘读写错误。
I/O 慢不像 CPU 100% 那么直观,它的典型表现是:
load average 很高,但 top 里 CPU 使用率并不满top 的 %wa(I/O wait)很高——CPU 在干等磁盘看到“高 load + CPU 不满 + %wa 高”这个组合,基本就锁定 I/O 了。接下来用专门的工具看细节。
iostat -xz 1 每秒刷新一次磁盘统计,几个关键列:
| 列 | 含义 | 怎么看 |
|---|---|---|
%util | 磁盘繁忙时间占比 | 接近 100% = 磁盘几乎没空闲 |
await | 每次 I/O 平均耗时(毫秒) | 明显偏大 = 单次 I/O 很慢 |
r/s、w/s | 每秒读 / 写次数 | 看读多还是写多 |
rkB/s、wkB/s | 每秒读 / 写的数据量 | 看吞吐量 |
判断要点:%util 高 + await 大,说明磁盘既忙又慢,是真瓶颈。光 %util 高但 await 正常,可能只是吞吐打满,不一定是问题。
知道磁盘忙,下一步是揪出是谁在制造 I/O:
sudo iotop -o # -o 只看真正在读写的进程它像 top,但排序的是 I/O。常见的 I/O 大户:数据库(查询、写日志)、备份任务、日志疯狂打印的应用、find / du 这种全盘扫描的命令。
排查 I/O 别只盯一个数字,要把吞吐、延迟、利用率放一起:
%util)高、延迟(await)正常 → 磁盘在满负荷干活,但还算健康,可能只是任务量大dmesg 有没有报错结合 iotop 找到的进程,再判断:是正常的业务高峰、是某个任务该错峰、还是磁盘该升级。
I/O 排查命令只读,但要注意别火上浇油
iostat、iotop、vmstat、dmesg 都是只读观察,放心用。但要注意:在一个已经 I/O 打满的系统上,你再去跑 du -sh /、find / 这种全盘扫描,等于火上浇油,会让情况更糟、排查更难。I/O 紧张时,优先用 iotop 这种轻量观察工具定位进程,别用重型扫描命令。真要处理元凶进程(限速、错峰、kill),属于有副作用的操作,先确认它是不是关键业务。
| 误区 | 更稳妥的做法 |
|---|---|
| load 高只查 CPU 和内存 | %wa 高就是 I/O 信号,转去 iostat / iotop |
只看 %util 一个数字下结论 | 吞吐、延迟(await)、利用率一起看才准 |
I/O 满的系统上还跑 du -sh / 全盘扫 | 用 iotop 等轻量工具,别用重型扫描雪上加霜 |
| 磁盘慢只怀疑负载 | await 异常大、dmesg 有报错时,考虑硬件问题 |
版权归属:Shuo Liu