真正说明IO瓶颈的是await、r_await/w_await和avgqu-sz三者组合：await超阈值（SSD>20ms/HDD>50ms）且%util≈100%表明延迟实质性升高；r_await高而w_await正常指向读路径问题；avgqu-sz>HDD 2或SSD 1说明请求已排队，处理能力不足。
iostat -x 输出里哪些字段真能说明IO瓶颈
别只盯着 %util 看——它只是设备“有活干”的时间占比，不是“干得动还是干不动”的判决书。SSD 上 %util 长期 100% 很可能完全正常；而 HDD 上 %util >80% 就该拉响警报。
真正要盯的是这三列组合：
-
await：平均每次 IO 的等待+处理时间（毫秒）。SSD 超过 20ms、HDD 超过 50ms 且%util≈ 100%，才说明延迟已实质性升高 -
r_await/w_await：分开看读/写延迟。若r_await高但w_await正常，问题大概率在读路径（比如慢查询扫表、大文件顺序读） -
avgqu-sz：平均队列长度。HDD >2 或 SSD >1 就代表请求开始排队，不是设备忙，是处理不过来
执行命令：iostat -xk 1（每秒刷新，单位 KB），重点关注这几列，其他如 svctm 已弃用，忽略即可。
sar -d 查历史 IO 数据总为空或 DEV 显示不全
这不是命令写错了，而是数据源没准备好。sar 依赖 sysstat 后台服务持续采集，没开服务就查不到历史。
先确认服务状态：systemctl is-active sysstat。如果返回 inactive，必须运行：systemctl enable --now sysstat。
常见坑点：
- 设备名缺失（DEV 列为空）：老版本 sysstat（nvme0n1）或多路径设备，升级 sysstat 或加
-p参数强制显示全名 - 逻辑卷（如
dm-0）默认不采集：需编辑/etc/sysconfig/sysstat，把DISKSTATS改为yes并重启服务 - 跨日查询失败：比如查 23:59 到 00:05，
sar不自动拼接两个saXX文件，得手动查sa$(date -d "yesterday" +%d)和sa$(date +%d)再合并
为什么 %util 高但业务不卡，或者 %util 低却卡顿
这两种情况都说明你只看了表象，没挖底层原因。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
%util 高但 await stat() 扫目录、日志框架每条消息都 fsync。这不是磁盘不行，是代码或配置太激进。
%util 低但业务卡顿：磁盘本身没饱和，问题往往在别处：
- 文件系统层阻塞：ext4 journal 满、xfs log buffer 等待刷盘
- 内存页缓存不足：频繁触发
pdflush或直接direct I/O，绕过缓存放大 IO 压力 - IO 被抢占：用
iotop -oP看是否有后台任务（如 backup、logrotate）偷偷吃掉带宽
此时 vmstat 的 bi/bo（块入/出）和 iowait 可能异常高，但 iostat 却显得“很闲”。
dd 测试结果和 iostat 数值对不上怎么办
这是必然的，因为两者测量对象完全不同：dd iflag=direct 测的是裸设备物理吞吐极限；iostat 统计的是内核 IO 栈全程（含 page cache、调度器、驱动）的真实负载。
所以：
- dd 写 500MB/s，
iostat却只看到 80MB/s：说明应用走的是缓存路径，大量写被 delay write 暂存，还没真正落盘 - dd 读只有 100MB/s，但
iostatrkB/s达到 400MB/s：大概率是 page cache 在起作用，读请求直接从内存满足，没走磁盘 - 想验证真实磁盘能力，必须清缓存：
echo 3 | sudo tee /proc/sys/vm/drop_caches，再跑 dd；但生产环境慎用
日常监控永远以 iostat -x 为准，dd 只用于基准测试或故障复现，不能用来解释实时性能现象。
