Linux磁盘IO瓶颈排查方法

本文深入剖析了Linux系统中磁盘IO瓶颈的精准识别与根因定位方法，打破仅依赖%util等单一指标的常见误区，强调需综合iostat -x中的r/s、w/s、r_await/w_await、await及IO>等关键字段交叉验证；指出iotop中IO>列比吞吐量更能反映进程真实阻塞程度，揭示短生命周期文件、内核行为（如JBD2日志、内存回收）、云盘限速、inode耗尽、挂载参数陷阱等隐蔽诱因，并提供strace、pidstat、/proc/pid/stack、perf等实战级诊断手段，帮助运维和开发人员穿透表象，直击高IO问题的本质根源。

磁盘IO瓶颈的典型信号是 %wa 持续高于 15%～20%，同时 %util 接近或等于 100%，且 await > 50ms —— 这三者同时出现，基本可以判定为真实IO瓶颈，而非瞬时抖动或误报。

iostat -x 输出里哪些字段真正反映IO压力

很多人只盯着 %util，但单看它容易误判。比如机械盘在大量小随机写时 %util 可能不到 60%，但 await 已飙到 200ms，应用早已卡死。

• r/s 和 w/s：反映实际 IOPS，比吞吐量更能暴露随机IO问题；SSD 上持续 > 10k 需警惕，HDD 超过 150 就算高负载
• rkB/s、wkB/s：看吞吐是否逼近设备理论上限（如 NVMe PCIe 4.0 x4 理论约 7GB/s）
• await：必须结合 svctm（已废弃）或 r_await/w_await 分开看；若 w_await 显著高于 r_await，大概率是写密集型脏页刷盘或日志同步拖慢
• %util：仅表示“设备忙的时间占比”，不等于“设备能力用尽”；云盘（如 Alibaba Cloud cloud_ssd）受后台限速影响，%util 95% 但实际 IOPS 却只有规格的 30%，得去控制台核对“实际IOPS”

iotop -o 显示的 IO> 列为什么比 DISK READ/WRITE 更关键

IO> 是进程等待IO完成的时间占总调度时间的百分比，它直接体现线程被IO卡住的程度。一个进程 DISK WRITE 很高，但 IO> 只有 2%，说明它用的是异步写或缓冲写，对系统响应影响有限；反之，IO> > 70% 的进程哪怕带宽只有 1MB/s，也会让整个应用线程池堵死。

• MySQL 单个慢查询线程可能 DISK READ 不高，但因全表扫描+临时文件排序，IO> 长期 > 85%
• Java 应用开启 log4j.appender.file.sync=true 后，IO> 会随日志量陡增，而 DISK WRITE 数值反而平缓
• 使用 sudo iotop -o -P 可过滤掉内核线程（如 kswapd0、ksmd），避免干扰判断

为什么 lsof +D /path 经常漏掉真正的高IO文件

lsof +D 只列出当前打开的文件，但很多高IO行为来自短生命周期文件：比如 MySQL 的 /tmp/#sql_* 临时表、Python 的 tempfile.NamedTemporaryFile、或 logrotate 切割瞬间创建又立即 unlink 的日志文件 —— 它们存在时间太短，lsof 很难捕获。

• 更可靠的方式是结合 pidstat -d 1 定位 PID 后，用 strace -p -e trace=write,open,openat,fsync -f 2>&1 | grep -E "(\/var|\/tmp|\/data)" 抓实时系统调用
• 对数据库类进程，优先查内部状态：SHOW ENGINE INNODB STATUS\G 中的 FILE I/O 段，或 PostgreSQL 的 pg_stat_bgwriter 视图
• 如果 iostat 显示某设备 %util 高，但 iotop 找不到对应进程，大概率是内核行为：如内存回收触发的 pgpgout（vmstat 1 观察）、或 ext4 的 journal 提交（dmesg | tail -20 查 “JBD2” 关键字）

df -h 看起来空间充足，为什么还出现IO瓶颈

磁盘空间（inodes 或 block）未满 ≠ IO 不会瓶颈。常见情况包括：

• 文件系统 inode 耗尽：df -i 显示 Use% 100%，即使 df -h 只有 30% 空间，也会导致新建文件失败、日志写入阻塞
• 挂载选项限制：如 /data 挂载时用了 barrier=1（默认），在写入元数据前强制刷盘，大幅拉高 await；而 noatime 对读密集型场景有效，但对写密集无效
• 底层存储限速：云盘的“突发IOPS”用完后进入限速模式，iostat 看起来稳定，但 await 波动剧烈；此时必须查云厂商监控，不能只信本地指标
• RAID 卡电池未就绪（BBU not ready）会导致 write-back 缓存被禁用，所有写变成同步落盘，%util 和 await 同时飙升

真正麻烦的从来不是指标怎么看，而是当 iostat 和 iotop 都指向某个进程，你却无法确认它在写什么——因为文件句柄可能已被关闭，或路径被容器 overlayFS 隐藏。这时候得靠 /proc//stack 看内核栈，或者直接上 perf record -e block:block_rq_issue -p 抓块层请求源头。

理论要掌握，实操不能落！以上关于《Linux磁盘IO瓶颈排查方法》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！