判断磁盘i/o瓶颈的核心是await、avgqu-sz与吞吐量是否匹配：await>30ms且avgqu-sz>8(nvme)或>4(ssd)、吞吐远低于理论带宽时，表明存在真实瓶颈；高await低%util指向内核或文件系统层问题，而非磁盘物理能力不足。
iostat -x 1 看设备级瓶颈，别只盯 %util
看到 %util 接近 100% 就以为磁盘卡死？错。现代 NVMe 上 %util 长期 100% 可能完全正常；而机械盘上 %util 持续 >80% 才真要警觉。关键得看三者联动：
-
await：平均每次 I/O 请求耗时（毫秒）。SSD >20ms、HDD >50ms 且稳定存在，说明延迟已起——不是“忙”，是“慢” -
avgqu-sz：平均队列长度。NVMe >8、SATA SSD >4、HDD >2 就表明上层下发太快，设备或调度器跟不上 -
rkB/s + wkB/s：实际吞吐。和理论带宽比（如 NVMe Gen4 x4 ≈ 3GB/s）——如果吞吐远低于上限，但await和avgqu-sz却很高，问题不在磁盘，而在内核或文件系统层
执行 iostat -x 1，重点关注这三列是否“不匹配”。比如 await=42ms、avgqu-sz=12、wkB/s=80MB/s（而该盘理论写入应达 2.5GB/s），这就是典型软件层瓶颈。
iotop -o 找不到高 IO 进程？权限和过滤逻辑常被忽略
iotop -o 启动后一片空白，不是没 IO，而是两个硬性条件没满足：
- 必须用
sudo iotop -o：非 root 无法读取/proc/*/io，会静默跳过所有用户进程 -
-o只显示“此刻正在发起 I/O”的进程——刚写完一页、正休眠的进程不会出现；去掉-o能看到全量，但噪音大；更稳妥的是先sudo iotop -o -d 1，再按O（Shift+o）按 IO 带宽降序
注意：容器进程在 cgroup v2 下可能被归为统一 IO 组，iotop 显示的是宿主机视角，不代表容器内实际受限后的用量。若怀疑容器，需进容器 ns 或查 /sys/fs/cgroup/io.pressure。
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
pidstat -d 1 定位进程真实 IO 延迟，而非仅看字节数
iotop 告诉你谁在猛写，pidstat -d 1 才告诉你它是不是真拖慢了系统：
- 运行
pidstat -d 1 5，重点看avgwq-sz（平均写队列长度）和avgrq-sz（平均请求大小）——小值（如 4KB）+ 高avgwq-sz表明是随机写风暴 - 对比
wait字段（单位 ms）：若某进程wait持续 >10ms，说明它的 I/O 请求长期排队，即使总字节数不高，也可能成为延迟源 - 对数据库或日志服务，检查其配置：是否启用了
fsync、sync_binlog=1或journal=ordered，这些会把异步写变同步，直接抬高await
别只信 IO_RATE 数值——一个每秒写 1MB 但平均等待 30ms 的进程，比每秒写 100MB 但等待 0.2ms 的进程更可能是瓶颈。
别跳过基础配置：调度器、挂载选项和 deleted 文件
很多“IO 瓶颈”根本不是硬件问题，而是可调项没对：
- 查当前调度器：
cat /sys/block/sda/queue/scheduler。SSD/NVMe 推荐none（即 mq-deadline 或 kyber），传统 HDD 可用deadline；cfq在新内核已移除 - 检查挂载选项：
mount | grep sda。关键项包括：noatime（避免每次读都更新时间戳）、barrier=1（影响 journal 性能）、commit=60（ext4 默认 5 秒提交，可调大缓解小写压力） - 空间明明够但 IO 卡顿？运行
lsof +L1查“已删除但仍被打开”的文件——常见于 logrotate 后 nginx/java 进程未 reload 日志句柄，几十 GB 空间被 hold 住却不释放
最易被忽略的点：iostat 的 await 是端到端耗时，包含内核路径、文件系统锁、块层队列、甚至存储网络（如 iSCSI）。单靠工具输出无法区分层级，必须配合 blktrace 或 bpftrace 进一步下钻——但那已是另一层问题了。
