判断磁盘i/o瓶颈的核心是await、avgqu-sz与吞吐量是否匹配：await>30ms且avgqu-sz>8(nvme)或>4(ssd)、吞吐远低于理论带宽时表明存在真实瓶颈；高await低%util指向内核或文件系统层问题，而非磁盘物理能力不足。
直接用 iostat -x 1 看实时指标，关键不是单看某个数字，而是盯住 await、avgqu-sz 和吞吐量（rMB/s + wMB/s）三者的匹配关系——不匹配，才是真实瓶颈。
怎么看读写吞吐量是否达标
吞吐量看 rMB/s 和 wMB/s（注意：加 -x 后单位是 MB，不是 kB），不是 rkB/s/wkB/s。
- 对比设备理论带宽：SATA SSD 约 500MB/s，NVMe Gen4 x4 约 3GB/s，PCIe 5.0 x4 可达 6–8GB/s。
- 如果
rMB/s + wMB/s远低于上限（比如 NVMe 只跑出 200MB/s），但await却很高，说明问题不在磁盘本身，而在上层——可能是小块 IO、同步写太多，或文件系统锁争用。 - 若
r/s高但rMB/s很低（比如每秒几万次读，但只读几百 KB），基本是小文件随机读（如数据库索引扫描），IO 效率极低。
怎么判断等待时间是否构成瓶颈
await 是平均每次请求从发出到完成的总耗时（毫秒），它包含排队时间和设备处理时间。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 机械盘持续 >15ms、SATA SSD >5ms、NVMe >1ms 就该警惕；稳定 >30ms 基本确认存在排队或响应变慢。
- 别只看
await，要和avgqu-sz（平均队列长度）一起看：- avgqu-sz >4（SATA SSD）或 >8（NVMe）且 await 同步升高 → 上层下发太快，设备或调度器跟不上；
- avgqu-sz 接近 1 但 await 却很高 → 可能是单个大 IO 或硬件响应异常（如坏块重试、链路不稳定）。
怎么区分是磁盘真慢，还是软件层卡住
单看 %util 容易误判，尤其对 NVMe 多队列设备，它已不具参考价值。重点看组合：
- 高 await + 高 %util + 低 r/s+w/s → 磁盘物理能力不足（如 HDD 随机写、SSD 老化、RAID 卡缓存关闭）；
- 高 await + 低 %util → 请求卡在内核层：常见于 ext4 journal 延迟、XFS 日志刷盘阻塞、频繁
fsync()、小文件密集同步写； - 低 await + 高 %util + 高 rMB/s/wMB/s → 正常高效顺序 IO（如备份、日志归档），无需干预；
- %util 接近 100% 但 await 正常、吞吐逼近理论值 → 现代 SSD/NVMe 的健康满载状态。
下一步必须做的定位动作
iostat 告诉你“哪块盘忙”，但不告诉你“谁在忙”：
- 运行
sudo iotop -o，按 IO_RATE 排序，快速找出当前最猛的进程； - 再用
pidstat -d 1 5按进程维度确认它的读写速率、IOPS 和平均等待时间； - 对高 IO 进程执行
lsof -p [PID]，看它正在操作哪些文件——如果集中在/var/log/、数据库数据目录或临时文件区，就要检查日志轮转策略、数据库sync_binlog或fsync设置是否过于激进。
不复杂但容易忽略
