Linux 磁盘 I/O 性能瓶颈排查

%wa高而cpu不满说明磁盘i/o瓶颈，非cpu或内存问题；需用iostat -x、iotop、lsof +l1等工具分层定位，dd测速需加oflag=direct和conv=fdatasync才准。

top 里 %wa 高但 CPU 不满，说明什么

这代表内核正在大量时间等待磁盘 I/O 完成，%wa（wait time）高而 %us/%sy 低，基本可锁定是磁盘慢，不是 CPU 或内存问题。常见于数据库写入、日志刷盘、大文件拷贝等场景。

注意：top 默认不显示 %wa，需按 1 切换到多核视图，再按 f → 选中 WA 字段；或者直接用 htop（需安装），它默认显示该列。

• iostat -x 1 比 top 更准：看 %util 是否持续 >80%，再结合 await（平均响应时间）是否 >10ms（HDD）或 >1ms（SSD）
• 如果 %util 低但 await 高，可能是单个请求慢（如 NFS 延迟、存储阵列故障），而非设备饱和
• iotop 可定位具体进程和线程：加 -o 只显示有 I/O 的进程，-P 显示线程级 I/O

df -h 显示已满，但 lsof + grep deleted 找不到大文件

linux 下文件被删除后，只要还有进程打开着它，磁盘空间就不会释放——df 统计的是块占用，不是文件系统目录树里的可见文件。

典型现象：日志轮转后空间没释放、应用未关闭旧日志句柄、容器内进程长期运行但日志被宿主机 logrotate 清理。

• 运行 lsof +L1 直接列出所有“已删除但仍被打开”的文件（+L1 是关键参数）
• 重点看 SIZE/OFF 列，单位是字节；挑大的杀掉对应进程，或让其重载日志（如 kill -USR1 给 nginx）
• 别只信 du -sh /* 2>/dev/NULL | sort -h ——它扫的是目录树，看不见被 hold 住的 deleted 文件

dd 测速结果不准，为什么 iostat 看起来更慢

dd 默认使用缓存（buffered I/O），测的是内存+磁盘联合速度，尤其小块写时可能全走 page cache，根本没落盘；而 iostat 统计的是实际发给设备的 I/O，含 sync 开销、队列等待、RAID/加密层延迟等。

真实瓶颈永远在 iostat -x 和 blktrace，而不是 dd。

• 要逼 dd 走直写：加 oflag=direct（绕过 page cache），再加 conv=fdatasync（强制刷盘），例如：dd if=/dev/zero of=/tmp/test bs=4M count=512 oflag=direct conv=fdatasync
• dd 单次测试波动大，至少跑 3 次取中位数；避免用 /tmp（可能是 tmpfs）或 LVM 快照卷
• SSD 上 bs=4K 和 bs=1M 结果能差 10 倍——iostat 的 r/s 和 w/s 才反映随机/顺序负载的真实压力

iotop 显示某进程 I/O 很高，但 strace -p 看不到 read/write

因为很多 I/O 并不走 glibc 的 read/write 系统调用：比如 mmap 内存映射文件后直接指针读写、异步 I/O（io_submit）、或者语言 runtime 自己管理缓冲区（Java nio、Go 的 os.File.Read 底层可能批量调用 preadv2）。

strace 默认只抓同步阻塞式系统调用，对 mmap、io_uring、splice 等透明 I/O 模式无感。

• 用 perf record -e block:block_rq_issue -p PID 抓块层下发事件，比 strace 更底层、更可靠
• 查 /proc/PID/io：看 rchar（用户态读字节数）和 read_bytes（实际从磁盘读字节数）差多少，差得多说明大量数据来自 page cache
• 如果是 Java 进程，优先看 jstack + GC 日志：频繁 CMS GC 或 G1 Mixed GC 会触发大量对象复制，间接导致 I/O（如写 heap dump、JFR 录制）

事情说清了就结束。真正卡住的从来不是工具不会用，而是忘了 I/O 路径上有太多层：page cache、block layer、driver、HBA、RAID、网络存储协议……每一层都可能吃掉毫秒级延迟，而人眼只能看到最终的 await。