排查磁盘I/O瓶颈需四步：先用top看%wa>30%确认I/O问题；再用iostat -x 2查%util≥80%和await>50ms锁定高负载磁盘；接着用iotop -o定位高IO进程；最后用lsof -p PID和strace分析具体读写文件与行为。
排查磁盘 I/O 性能瓶颈，核心是“先定方向、再锁进程、最后挖根因”，不能一上来就盯着某个进程猛查。关键在于分层确认：系统是否真被 I/O 拖慢？是哪块盘在扛不住？谁在持续写/读它？行为是否合理？
第一步：确认是不是 I/O 问题导致的卡顿
先别急着看磁盘，用 top 快速扫一眼 CPU 等待状态：
- 运行 top，关注右上角的 %wa（I/O wait）列
- %wa > 30%：说明 CPU 大量时间在等磁盘响应，I/O 很可能已是瓶颈
- 同时看 load average —— 如果负载高但 %us（用户态）和 %sy（内核态）都不高，而 %wa 突出，基本可锁定 I/O 方向
第二步：定位压力最大的磁盘设备
用 iostat -x 2（每 2 秒刷新一次）观察各磁盘的扩展指标：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 重点看 %util：持续 > 80% 表示该磁盘已饱和
- 看 await：平均每次 I/O 请求等待时间，> 50ms 说明队列堆积严重
- 对比 r/s 和 w/s：判断是读多还是写多；结合 rkB/s 和 wkB/s 看吞吐压力
- 注意设备名，如 sda、nvme0n1 或云环境下的 vda
第三步：找出吃掉 I/O 的具体进程
确认目标磁盘后，用 iotop -o（只显示正在做 I/O 的进程）实时抓活跃者：
- 按 WRITE 或 READ 列排序，找数值最高的进程
- 关注 IO> 列：该值越高，说明进程花在 I/O 等待上的时间占比越大
- 记下 PID，后续深入分析用
- 如果看到 jbd2/sda-8 这类内核线程长期高写入，说明 ext4 日志在疯狂刷盘，不是普通应用问题，需单独排查元数据操作激增原因
第四步：分析进程到底在读写什么
拿到 PID 后，用 lsof -p [PID] 查它打开的文件：
- 重点关注大文件、日志文件（如 *.log）、数据库文件（如 *.ibd）、临时文件（/tmp/xxx）
- 配合 strace -p [PID] -e trace=write,read 2>&1 | head -20 看它最近在写哪些内容、每次写多大
- 如果是数据库进程，检查慢查询日志；如果是应用，确认日志级别是否设为 DEBUG、是否缺少轮转、是否有同步刷盘逻辑
