wa值是否真高需结合cpu核数判断：单核>20%、4核>5%持续1分钟即需排查；wa高但load低多为后台刷盘，非并发瓶颈；iostat -x 1 5看后4组数据，%util>70%、await超阈值、avgqu-sz>1可定位磁盘瓶颈。
怎么看 top 里的 wa 值是不是真高
直接看 top 输出顶部的 %Cpu(s) 行，重点盯 wa 字段（比如 96.0 wa）。这个值不是“越高越危险”，而是要结合 CPU 核数和业务场景判断：
• 单核机器上 wa > 20% 就值得查；
• 4 核机器上 wa > 5% 持续超过 1 分钟，说明 I/O 已开始拖慢整体响应；
• 如果 wa 高但 load average 很低（比如 0.15），大概率是某进程在后台刷盘，不是并发瓶颈；
• 注意别被第一个 iostat 报告骗——它统计的是系统启动以来的平均值，直接忽略。
怎么用 iostat -x 1 5 锁定问题磁盘
iostat -x 1 5 每秒刷新一次，共 5 组，只看后 4 组（跳过首行）。关键指标就三个：
• %util > 70%：磁盘忙到没空闲时间，基本可判定为瓶颈设备；
• await > 10ms（HDD）或 > 1ms（SSD）：请求排队太久，不是设备慢就是队列堵了；
• avgqu-sz > 1：平均队列长度持续大于 1，说明请求在内核 block 层就开始积压。
如果看到 sda 的 %util 是 99.8%，而 dm-0（LVM 或加密卷）的 %util 只有 5%，那问题一定在物理盘层，不用往下查逻辑卷。
怎么用 iotop -o 找出真正刷盘的进程
iotop -o 只显示当前有 I/O 活动的进程，比 ps aux --sort=-%cpu 有用得多：
• 关注 WRITE 列，数值大的优先看（单位是 KiB/s）；
• 如果看到 java 进程 WRITE 持续在 20MiB/s 以上，且 COMMAND 显示带 -Dlogback.configurationFile=...，大概率是日志同步刷盘导致；
• 注意区分 IO> 和 SWAP：如果 iotop 显示大量 swapper 或 kswapd0 在写，说明内存不足，正在疯狂换页；
• 容器环境里，iotop 显示的 PID 是宿主机视角的，别直接进容器 exec 查，先记下 PID 再用 ps -p PID -o pid,ppid,comm,args 看父进程和启动命令。
怎么用 lsof -p PID 确认文件级行为
拿到可疑 PID 后，lsof -p PID 不是扫一眼完事：
• 先过滤掉 /dev/zero、/dev/null、socket 这类非磁盘项；
• 重点关注 REG 类型文件，尤其是路径含 /var/log、/data、/tmp 的；
• 如果看到大量 deleted 状态文件（如 /var/log/app.log.1 (deleted)），说明程序没关文件句柄，还在往已删文件写，会持续触发元数据更新；
• Kubernetes 场景下，若 lsof 输出里出现 /var/lib/kubelet/pods/.../volume-subpaths/... 或大量 overlay 路径，基本可断定是 overlayfs + 小文件写入引发的 iowait，这时候调参数不如改挂载方式。
wa 高的时候 sy（系统态 CPU）是否也同步飙升。如果两者一起涨，问题可能不在磁盘本身，而在内核路径——比如 XFS 日志刷盘卡住、ext4 的 journal 提交延迟、或者 overlayfs 的 upperdir 元数据锁争用。这种情况下，iostat 和 iotop 看起来都“正常”，但 perf record -e block:block_rq_issue -g -a sleep 10 才能暴露真实瓶颈。
