IO等待过长表现为响应慢、CPU空闲但任务卡住、%wa偏高；需先确认IO瓶颈，再用iostat -x 1查%util、await、r_await/w_await、avgqu-sz，结合iotop、pidstat定位进程，lsof查文件设备，lsblk/dmesg/smartctl/nvme检查底层状态，并区分突发/持续、随机/顺序IO场景。
IO等待过长通常表现为系统响应变慢、CPU空闲但任务卡住、top中%wa值持续偏高。核心思路是：先确认是否真为IO瓶颈，再定位是哪类设备、哪个进程、哪类操作导致的高延迟。
看iostat输出，聚焦关键指标
iostat -x 1（每秒刷新一次扩展统计）重点关注以下几列：
- %util：设备忙于处理IO请求的时间百分比。接近100%说明设备饱和，但不绝对等于瓶颈（如队列深、SSD并发高时可能仍健康）
- await：IO请求平均等待+服务时间（毫秒）。>10ms（HDD）或 >1ms（SSD）需警惕；持续 >50ms 基本确认存在严重延迟
- r_await / w_await：分别看读/写请求平均耗时，可判断是读密集还是写密集引发的问题
- avgqu-sz：平均队列长度。明显大于设备并行能力（如NVMe常支持数百，SATA盘一般为1~8），说明请求在排队
- svctm（已弃用，新内核常为0）：忽略；以await为准
结合pidstat和iotop定位“罪魁进程”
iostat只告诉你“设备忙”，不告诉你“谁在忙”。需进一步下钻：
- 运行 iotop -oP：只显示正在执行IO的进程，按实际IO速率（BYTES/s）排序，一眼识别高IO消耗者
- 运行 pidstat -d 1：输出每个进程的读写字节数、读写次数，适合观察趋势和对比历史基线
- 对可疑进程，用 lsof -p PID 查看它打开的文件及对应设备（如 /dev/sdb1、/dev/nvme0n1p2）
检查存储栈底层状态
即使iostat显示某盘高await，也要排除路径问题：
- 运行 lsblk 确认设备拓扑（是否LVM、RAID、multipath？逻辑盘背后物理盘是否异常？）
- 检查 dmesg | grep -i "error\|fail\|timeout"：是否有硬盘掉线、链路重置、SMART告警等内核级错误
- 对SATA/SAS盘，用 smartctl -a /dev/sdX 查看Reallocated_Sector_Ct、Pending_Sector等关键属性
- 对NVMe盘，用 sudo nvme smart-log /dev/nvme0n1 关注critical_warning、media_errors
区分场景：突发 vs 持续，随机 vs 顺序
IO模式决定排查方向：
- 若await高但r/s、w/s很低（如少量大IO或随机小IO打满单队列深度，常见于数据库索引扫描、小文件遍历
- 若await高且r/s、w/s极高（如>10k IOPS），可能是硬件吞吐达上限或驱动/队列参数不合理（如noop调度器用于高并发SSD）
- 用 iostat -xmt 1 观察 rrqm/s、wrqm/s：若合并率低（
