要判断Linux存储性能是否出现瓶颈，不能只看单一数值，得把iostat的%util、await、r/s、w/s及avgrq-sz等指标结合分析，同时配合iotop、biotop等工具定位进程级IO行为。
要判断Linux存储性能是否出现瓶颈，不能只看单一数值，得把
iostat看设备层压力，重点盯这几个字段
- rKB/s 和 wKB/s：反映真实吞吐量。若接近磁盘标称上限（如SATA SSD约500MB/s），说明带宽已满；但也要结合IOPS（r/s、w/s）看——小文件随机写可能吞吐不高，却把IOPS拉满
- await：平均I/O耗时（ms）。HDD超过10ms、SATA SSD超1ms、NVMe超0.1ms就要警惕；若r_await远大于svctm（服务时间），说明等待队列在堆积
- avgqu-sz：平均队列长度。值＞1且持续上升，等于系统在“堵车”；对NVMe等多队列设备，这个值比%util更可靠
- rrqm/s 和 wrqm/s：每秒合并的读/写请求数。值高是好事，说明内核成功合并了相邻IO，对HDD尤其有利
iotop找进程级元凶，操作比想象中简单
iotop必须用root权限运行，否则看不到完整数据。启动后默认按实时IO速率排序，但真正高效用法在于几个快捷键：
- 按o键：只显示当前有实际I/O活动的进程，瞬间过滤掉90%的干扰项
- 按P键：切换为按PID显示（而非TID线程），避免同一进程的几十个线程刷屏
- 按a键：切换到累计I/O视图，适合排查长时间跑的任务（比如备份脚本写了6小时才写完）
- 按T键：开启树状模式，能看清哪个父进程拉起了大量子线程在刷盘
注意：如果iotop里没看到明显大户，但iostat显示%util很高，大概率是内核线程（如kswapd内存回收、jbd2日志提交）或Direct I/O类应用（如MySQL裸设备访问）在干活。
查出高IO之后，下一步不是杀进程，而是问三个问题
定位到进程只是开始，真正的问题常藏在路径上：
-
挂载点空间还够吗？执行
df -h，特别关注/var/log、/tmp、业务数据目录。空间低于10%会触发频繁元数据更新和block回收，引发IO放大 -
它在写什么文件？对高IO进程PID执行
lsof -p PID，重点看.log、.tmp、.journal、.binlog这类易膨胀文件；用ls -laSh /path/to/dir | head -10快速找出最大文件 - 是缓存IO还是直写？如果iotop显示高读写但iostat几乎无响应，说明数据全走page cache——此时瓶颈不在磁盘，而在内存或应用设计
云环境和新型存储下的特别提醒
传统指标在现代环境中需要重新解读：
- NVMe设备支持多队列，%util失去意义。应优先看r_await/w_await和aqu-sz，延迟才是核心瓶颈
- 容器环境里，iotop可能无法正确映射cgroup I/O限制。此时要查
cat /sys/fs/cgroup/io.stat确认实际配额与使用量 - 云盘（如AWS EBS、阿里云ESSD）的IO表现受网络延迟和IOPS配额影响。需同步查看云平台监控，确认是否触及QoS上限
- 遇到可疑IO但工具都抓不到来源？试试biosnoop（eBPF工具），它能零开销捕获每个I/O的发起进程和精确延迟
