判断磁盘性能瓶颈需综合await、avgqu-sz和吞吐量（rkB/s+wkB/s）三者联动关系，而非单看%util；结合iostat -x、iotop、pidstat等工具定位进程与配置问题。
判断磁盘是否存在性能瓶颈，不能只看单一指标，关键在于几个核心指标的联动关系是否“失衡”。重点不是%util是否接近100%，而是await、avgqu-sz和实际吞吐量（rkB/s + wkB/s）三者是否匹配。
盯住三个关键指标组合
运行 iostat -x 1 每秒刷新一次扩展统计，重点关注以下字段的协同表现：
- await：平均每次I/O请求从发出到完成的耗时（毫秒）。机械盘持续超过15ms、SSD超过5ms就需警惕；若稳定高于30ms，基本说明请求在排队或响应变慢。
- avgqu-sz：平均队列长度。值大于1是常态，但长期大于4（NVMe上大于8）说明上层下发过快，设备或调度器已跟不上。
- rkB/s + wkB/s：实际吞吐量。要和设备理论带宽对比（如SATA SSD约500MB/s，NVMe Gen4 x4约3GB/s）。如果吞吐远低于上限，但await和avgqu-sz却很高，问题不在磁盘本身，而在软件层。
区分四类典型异常模式
单看一个数字容易误判，必须结合组合判断瓶颈位置：
- 高await + 高%util + 低r/s+w/s：磁盘物理能力不足。常见于机械盘随机写、SSD老化、RAID卡缓存关闭或失效。
- 高await + 低%util：请求卡在内核层。可能是文件系统锁争用（如ext4 journal延迟）、块设备队列拥塞，或应用频繁open/write/close小文件导致syscall过载。
- 高%util + 低await + 高rkB/s或wkB/s：设备正在高效处理大块顺序IO（如备份、日志归档），属于健康高负载，无需干预。
- %util接近100%但await正常、吞吐逼近上限：现代SSD/NVMe的正常状态。%util在Linux 5.0+多队列设备上已被标记为deprecated，此时更应关注D2C时间（需用blktrace补充）。
配合iotop和pidstat锁定具体进程
iostat告诉你“哪块盘忙”，但不告诉你“谁在忙”。下一步必须下钻：
- 运行 sudo iotop -o：只显示当前有I/O活动的进程，按IO_RATE排序，一眼找出写入最猛的PID。
- 运行 pidstat -d 1 5：按进程维度统计每秒读写字节数、IOPS和平均等待时间，确认该进程是否真的造成高延迟。
- 对可疑PID，用 lsof -p [PID] 查它正在操作哪些文件；若集中在/var/log或某个数据库路径，再检查日志轮转策略或数据库fsync设置是否过于激进。
别忽略基础配置与挂载选项
很多“I/O瓶颈”其实源于可调参数：
- 查看当前调度器：cat /sys/block/sda/queue/scheduler（注意路径完整，原知识库中截断）。
- 检查挂载选项是否启用noatime、barrier=0等优化项，尤其对高频写场景。
- 确认RAID卡缓存是否启用、电池/电容是否健康；云环境还需核对云盘类型（如SSD云盘 vs 普通云盘）及IOPS配额是否被占满。
