直接看%util列——它反映磁盘忙于处理i/o请求的时间占比，非容量占用而是饱和度指标；持续≥80%需警惕，≥90%基本过载，但须结合await、avgqu-sz等指标综合判断，尤其ssd和云环境/%util参考价值下降。
直接看 %util 列——它反映的是磁盘设备忙于处理 I/O 请求的时间占比，不是“用了多少容量”，而是“有没有空闲窗口响应新请求”。数值接近或等于 100%，说明设备已无余力，新请求只能排队等待。
什么时候算过载？
持续高于 80% 就需警惕；长期稳定在 90% 以上，基本可判定为过载。但要注意：这不是绝对阈值，得结合设备类型和业务场景看：
- 机械硬盘（HDD）：%util > 80% + await > 50ms，大概率已瓶颈
- 固态硬盘（SSD）：%util > 70% 就值得查，尤其当 avgqu-sz > 1 或 r_await/w_await > 10ms
- 云盘或 RAID 阵列：%util 参考价值下降，更要看 await、aqu-sz 和吞吐量是否触及厂商标称上限
别只盯 %util，必须搭配关键指标
%util 单独看容易误判，尤其在 SSD 或高并发场景下。真正说明问题的是组合信号：
- avgqu-sz（平均队列长度）：HDD 持续 > 2、SSD 持续 > 1，代表请求开始堆积
- await（平均等待时间）：显著高于正常基线（如 HDD > 50ms、SSD > 10ms），说明延迟飙升
- r_await / w_await：分开看读写延迟，能定位是读密集还是写密集导致卡顿
- svctm 接近 await：说明慢在磁盘本身；svctm 远小于 await：瓶颈在队列或上层调度
怎么用命令快速验证
运行 iostat -xk 1（每秒刷新一次扩展统计），重点关注目标设备行：
- 先扫一眼 %util 是否持续高位
- 再看 avgqu-sz 和 await 是否同步异常
- 对比 rKB/s、wKB/s 是否接近设备理论带宽（比如一块 SATA SSD 标称 550MB/s，wKB/s 长期超 500000 就可能到顶）
- 加 -p ALL 可查看各分区，确认是不是某个挂载点（如 /var/log）拖累整块盘
常见误判提醒
以下情况 %util 高但未必真过载：
- 短时突发写入（如日志刷盘、备份启动瞬间），%util 冲到 100% 几秒就回落，属正常
- SSD 处理大量小 IO 时，%util 可能偏低但延迟很高（并行能力强，但随机读写有物理限制）
- 虚拟化或云环境里，%util 反映的是虚拟设备忙时，不等于底层物理盘饱和
