引言：CPU和内存都正常，业务却卡成PPT？

IDC运维最头疼的一类问题：应用响应慢、数据库查询超时，top 一看 CPU 空闲、内存充足，问题出在哪？十有八九是磁盘IO。机械盘、共享存储、IO被打满的宿主机，都可能成为性能黑洞。这一篇从 iostat 全局诊断、iotop 定位进程、pidstat 深挖细节，讲清楚磁盘IO排查的完整思路。

一、先确认：瓶颈真的是磁盘吗

别急着看磁盘，先排除其他嫌疑：

# CPU和负载情况
top -bn1 | head -15
# 内存和swap
free -h
# 是不是在等IO（R状态进程多、wa高）
vmstat 1 5

vmstat 输出里重点关注：wa（CPU等待IO的时间占比） 和 b（不可中断睡眠的进程数，典型就是等磁盘）。wa 持续高于 30%、b 列长期有值，基本可以断定IO是瓶颈，进入第二步。

二、iostat 看全局：哪个盘在拖后腿

# 每秒刷新一次，持续观察
iostat -x 1 5

重点看这几列：

  • %util：设备繁忙度。持续接近100%说明磁盘接近饱和。
  • await：平均IO响应时间（毫秒）。SSD一般应低于5ms，机械盘几十ms正常，超过100ms基本就是异常。
  • svctm：IO服务时间。svctm远小于await，说明大量时间耗在排队上，磁盘确实忙不过来。
  • r/s、w/s、rkB/s、wkB/s：每秒读写次数和吞吐量，判断是读多还是写多。
  • rrqm/s、wrqm/s：合并率。机械盘场景下合并率高是好事，说明IO调度在帮你减少寻道。

判断思路：%util高 + await高 = 磁盘饱和，要么换盘、要么减负载；%util不高但await高 = 可能队列里有慢IO（比如某块盘快挂了，或者共享存储抖动），继续往下查。

三、iotop 抓进程：到底是谁在疯狂读写

# 需要root，按IO排序显示
iotop -o -P -d 2

iotop 按实时IO大小排序，一眼就能看到是哪个进程在刷盘。常见嫌疑犯：

  • 数据库（MySQL/PostgreSQL）：大量落盘、刷redo log。
  • 日志服务：rsyslog、应用日志疯狂写入。
  • 备份任务：rsync/tar 定时任务撞上业务高峰。
  • Java/Python应用：GC频繁写日志，或者内存不足疯狂swap。

抓到进程后，结合业务排期看它是否应该在此时运行，再决定是优化还是错峰。

四、pidstat 深挖：单进程的读写细节

# 查看指定进程的IO统计（每秒，持续10次）
pidstat -d -p PID 1 10
# 或者直接看全进程
pidstat -d 1 10

关注 kB_rd/s、kB_wr/s、iodelay（进程等待IO的时间）。iodelay 持续很高，说明这个进程就是IO大户，且正在被磁盘拖慢。结合 lsof -p PID | grep -E '\.(log|data|ibd)' 看看它到底在写哪些文件，就能定位到具体的目录和文件。

五、区分读和写：对症下药的前提

同样是磁盘慢，读和写的解法完全不同：

# 看IO是读多还是写多
iostat -x 1 | grep -E 'Device|sda'
  • 读瓶颈：优先加内存做缓存（page cache），热点数据上 Redis，或者换 NVMe SSD。数据库场景加大 buffer pool 往往立竿见影。
  • 写瓶颈：检查 fsync 频率（数据库可以把 log 刷盘策略调优）、日志落盘策略，必要时把日志和数据分开放在不同物理盘。
  • 随机小IO：机械盘的死穴。大量随机读写场景，唯一的出路就是换SSD或者用缓存层。

六、常见场景实战

场景一：MySQL 写入慢，%util 100%

检查 innodb_flush_log_at_trx_commit 是否每笔事务都强制刷盘；确认 redo log 和数据文件是否在同一块盘；看 buffer pool 是否太小导致频繁写脏页。优化方向：调大 buffer pool、把 redo log 放到独立的SSD、评估读写分离。

场景二：凌晨备份把业务拖垮

rsync/tar 全量备份挤在业务高峰期，IO被打满。解法：备份错峰到低峰期、用 ionice 给备份任务降优先级（ionice -c 2 -n 7 rsync ...）、增量备份替代全量。

场景三：某块盘 await 异常高

同一阵列里某块盘慢，可能盘要坏了。用 smartctl 检查健康状态（参考之前磁盘巡检那篇），必要时热替换。共享存储场景还要检查存储网络（光纤/万兆网）是否拥塞。

七、预防：IO监控要建起来

等IO被打满再排查就晚了，日常监控必须覆盖：

  • 每台机器的 %util、await、吞吐量纳入监控（node_exporter + Prometheus + Grafana）。
  • 设置告警：%util 持续 >90% 超10分钟、await 超阈值、磁盘预测寿命告警。
  • 定期用 fio 做基准测试，记录每台机器的IO能力基线，出问题时对比基线就知道退化多少。

结语

磁盘IO排查的套路很清晰：vmstat 确认是IO问题 → iostat 定位到盘 → iotop/pidstat 抓到进程 → 区分读写对症下药。难的不是命令，而是把「现象 → 工具 → 结论 → 方案」这条链路走通。配合监控体系提前预警，大部分IO事故都能在影响业务之前被摁灭。