诊断带宽饱和需综合吞吐（rkb/s+wkb/s）、await（ssd>20ms/hdd>10ms）和avgqu-sz是否同步异常，三者匹配才表明真饱和；%util=100%但await正常则多为小文件写入问题。
诊断存储带宽饱和导致的延迟，不能只看 %util 是否接近 100%，而要验证实际吞吐是否已逼近设备理论上限，同时 await 和 avgqu-sz 是否同步异常升高——三者不匹配，才是带宽真正吃紧的信号。
盯住吞吐量与理论带宽的差距
带宽饱和的本质是“想写/读的比设备能吞下的多”。先确认设备理论极限：
- SATA SSD：约 500 MB/s（即 500,000 kB/s）
- NVMe Gen3 x4：约 3.5 GB/s → 3,500,000 kB/s
- NVMe Gen4 x4：约 6–7 GB/s → 6,000,000–7,000,000 kB/s
运行 iostat -xmk 1（-m 以 MB/s 显示，-k 确保单位统一），观察 rkB/s + wkB/s 总和。若该值长期稳定在理论带宽的 85% 以上，且 await > 20ms（SSD）或 > 10ms（HDD），就说明带宽已实质饱和。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
识别“高吞吐 + 高延迟”的典型组合
带宽饱和时，iostat -x 输出常呈现以下特征组合：
- rkB/s 或 wkB/s 极高（例如 NVMe 上持续 > 4000 MB/s）
- await 和 w_await 同步抬升（如从 0.3ms 涨到 15ms+）
- avgqu-sz 显著大于 1（NVMe 常见 >10，SATA SSD >4）
- %util 接近 100%——此时它反而成了佐证，而非主因
注意：若 %util 100% 但 await 正常（
排除其他干扰因素
高吞吐未必等于带宽饱和，也可能是小块 IO 堆积或软件层阻塞：
- 检查 r/s + w/s（IOPS）是否异常高：若吞吐高但 IOPS 更高（如 >100K），大概率是大量小文件写入，问题在应用逻辑或文件系统，而非带宽本身
- 对比 w_await 和 svctm：svctm 已废弃，但若 w_await 是 svctm 的几十倍（如 w_await=92，svctm=0.1），说明请求卡在队列，非设备响应慢
- 用 iotop -o 确认是否单个进程持续打满写入，再用 lsof -p PID 查它是否在往同一块盘反复刷日志或临时文件
验证是否真被带宽卡住
最直接的方法是做轻量级带宽探测：
- 用 fio 模拟纯顺序写： fio --name=seqwrite --ioengine=libaio --rw=write --bs=1M --size=2G --runtime=30 --time_based --direct=1 --filename=/dev/your_disk
- 观察 fio 报出的 write: io=2048.0MB, bw=4256MiB/s —— 若接近理论值，说明硬件正常；若远低于（如仅 800MB/s），且 iostat 同时显示高 await+高 avgqu-sz，则带宽路径中存在隐性限制（如 RAID 卡缓存关闭、PCIe 通道降速、驱动限频）
