%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。
