排查磁盘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、是否缺少轮转、是否有同步刷盘逻辑