磁盘io长期100%不等于物理卡死，需先通过top看%wa是否高、iostat查await/avgqu-sz判断瓶颈类型，再用iotop定位进程，结合lsof、挂载参数和io调度器深入分析。
磁盘 I/O 长期处于 100%（即 %util ≈ 100%）并不一定代表磁盘“物理卡死”，而是说明该设备在采样周期内几乎持续忙于处理 I/O 请求。关键要区分是真实硬件瓶颈，还是队列堆积、调度不当或上层应用行为异常所致。排查需分层推进，避免直接升级磁盘或重启服务。
先确认是否真是 I/O 瓶颈
别急着查进程，先排除误判：
- 运行 top -c，看 %wa（I/O wait）是否持续高于 30% —— 若低于 10%，大概率不是 I/O 问题；若高达 50%+，且 CPU idle 很高，基本可锁定
- 用 iostat -x 1 5 观察多组数据，重点关注：
– await：平均等待时间。SSD/NVMe > 1ms、HDD > 20ms 就需警惕
– avgqu-sz：平均队列长度。持续 > 1 表示请求在排队
– r_await / w_await：分别看读/写延迟，定位是读压还是写压 - 注意：%util 接近 100% 但 await 很低（如 NVMe 下仅 0.3ms），可能是高并发小 IO 导致的“忙而不慢”，此时瓶颈可能在应用逻辑或文件系统层，而非磁盘本身
定位具体是哪个磁盘压力大
iostat 输出中，Device 列会显示设备名（如 nvme0n1、sda、vdb）。重点关注：
- 哪块设备的 %util 和 await 同时偏高
- 对应 wkB/s 或 rkB/s 是否远超该磁盘标称吞吐（例如普通云盘标称 200MB/s，实测持续写入 280MB/s）
- 如果是虚拟化环境（如 ECS），还要核对云盘类型（高效云盘、SSD云盘、ESSD）及其 IOPS/吞吐配额，确认是否已达上限
找出消耗 I/O 最多的进程
使用 iotop -o -P（只显示有实际 I/O 的进程，不含内核线程）：
- 按 DISK WRITE 或 DISK READ 列排序（左右箭头键），找速率最高者
- 同步关注 IO> 列（I/O 等待时间占比），>90% 表示该进程大部分时间卡在 I/O 上
- 若看到大量 jbd2、kworker 占比高，说明是文件系统日志或内核后台刷盘导致，需检查挂载参数和 ext4 日志模式
- 注意：MySQL、PostgreSQL 等启用 native AIO 时，iotop 能看到高 IO，但 strace -e trace=read,write 可能抓不到调用 —— 此时应查 cat /proc/
/io 中的 write_bytes 与 syscw 差值，若前者远大于后者，大概率是异步 I/O
深入分析进程行为与系统配置
拿到可疑 PID 后，进一步验证原因：
- 用 lsof -p PID 查看它正在读写的文件路径 —— 是否集中在日志目录、数据库数据目录或临时文件？
- 检查对应文件系统挂载选项：mount | grep
，确认是否含 noatime（避免读操作触发元数据更新） - 查看 IO 调度器：cat /sys/block/sdX/queue/scheduler，SSD/NVMe 建议用 none 或 mq-deadline，避免 CFQ 类调度器引入额外延迟
- 临时缓解可尝试：echo 'noop' | sudo tee /sys/block/sdX/queue/scheduler（需测试有效性）
