判断磁盘是否过载只需关注%util和avgqu-sz：若%util长期＞80%，说明磁盘持续高负载；avgqu-sz持续＞2（hdd）或＞1（ssd），表明i/o请求排队，已出现性能瓶颈。
怎么看磁盘是不是快扛不住了
直接看 %util 和 avgqu-sz 两个值就够了。如果 %util 长期 >80%，说明磁盘几乎一直在干活；如果 avgqu-sz 持续 >2（机械盘）或 >1（SSD），代表请求排队变长，I/O 开始堵车。这时候哪怕 CPU、内存都空闲，应用也会卡——因为数据还没从磁盘吐出来。
-
%util = 100%不等于“完全不能写”，而是“没空闲窗口处理新请求”，响应时间会陡增 -
await超过 50ms（HDD）或 10ms（SSD）就该警觉，svctm接近await说明瓶颈真在磁盘本身，不是队列积压 - 别只盯
kB_read/s或kB_wrtn/s：吞吐高≠性能好，可能只是大块顺序读写掩盖了随机 IOPS 不足
iostat 怎么用才不漏关键指标
默认跑 iostat 只给基础信息，对排查问题基本没用。必须加 -x（扩展统计）+ -k（KB 单位）+ 时间间隔，比如：iostat -xk 1 —— 每秒刷新一次，带完整 I/O 细节。
-
-c和-d不能同时用，但-x默认包含设备统计，所以不用额外加-d - 想看某块盘（如
sdb）及其分区，用iostat -xk 1 /dev/sdb；想看所有块设备（含 LVM 逻辑卷），加-p ALL，但注意-p和-x冲突，得二选一 - 生产环境慎用
iostat -xz 1（-z忽略空闲设备）：它会跳过暂时没 IO 的盘，可能让你错过“间歇性打满”的隐患盘
常见误读和真实含义对照
r/s 和 w/s 是每秒请求数，不是每秒完成数；rrqm/s 高说明系统在合并读请求（通常是小文件/随机读多），这不是错，但可能暴露应用层未做批量读优化。
-
avgrq-sz单位是扇区（512 字节），值为 64 ≈ 32KB，值为 128 ≈ 64KB——这个大小能反映 workload 类型（小 IO 密集 or 大块流式） -
%iowait高 ≠ 磁盘慢，也可能是进程频繁发小 IO 请求让 CPU 等着，此时要结合r/s和avgrq-sz看请求模式 -
Blk_read/s这类字段没加-k或-m时单位是“块”（512B），容易误判成 KB，数值会大一倍
装不上 iostat 怎么办
CentOS/RHEL 用 yum install sysstat -y；Ubuntu/Debian 是 apt-get install sysstat -y。个别系统（如某些 Alpine 容器镜像）可能只有 pcp 提供的 iostat，行为略有差异：它默认不输出 %util，需确认是否含 /proc/diskstats 支持。
- 运行
iostat -V查版本，sysstat ≥ 10.0 才稳定支持-x下的%util - 如果提示
command not found但which iostat有输出，可能是 PATH 未更新，或者 cron 没启用 sysstat 数据采集（/etc/cron.d/sysstat需存在且生效） - 容器环境若无法安装，可用
cat /proc/diskstats手动算：第 4 列（读完成数）、第 8 列（写完成数）、第 10 列（读毫秒）、第 14 列（写毫秒）是核心原始数据
真正难的不是看懂数字，而是把 r_await 偏高和应用日志里的“timeout after 30s”联系起来，再定位到某张 MySQL 表没建索引导致全表扫描刷盘——这时候 iostat 只是第一扇门，别停在门口。
