iostat -x是必须的，因不加-x仅显示吞吐量和合并后请求次数，无法反映延迟、队列长度或设备饱和度；加-x才能获取await、%util、avgqu-sz、r_await/w_await等关键瓶颈指标。
iostat 是最直接有效的命令，但**不加 -x 参数基本没用**——它只显示吞吐量和简单请求次数，看不出延迟、队列或饱和度。
为什么 iostat -x 是必须的
默认 iostat 输出里没有关键瓶颈指标。只有加 -x 才能拿到：await（平均I/O耗时）、%util（设备忙时百分比）、avgqu-sz（平均队列长度）、r_await/w_await（读写分离延迟）。这些才是判断“磁盘是不是真卡住”的依据。
常见错误是只跑 iostat 或 iostat -k 1，结果看到 rKB/s 很高就以为IO爆了，其实可能只是缓存读，根本没落盘。
-
iostat -xk 1：每秒刷新一次，单位 KB，含全部扩展字段 -
iostat -dx 1：加-d排除 CPU 行，避免干扰；-x和-d可共存 -
iostat -xk 1 /dev/sdb：聚焦单块盘，排除其他设备噪音 -
iostat -xk 1 -p ALL：查看 LVM 逻辑卷或分区级数据，对多挂载点环境很关键
iotop -o 总是空？先检查权限和模式
非 root 用户运行 iotop 会静默跳过所有用户进程，只显示几个内核线程——这不是工具坏了，是权限不足导致读不到 /proc/*/io。
-o 模式只显示“当前有 I/O 活动”的进程，如果某进程刚写完一批日志、正空闲，它就不会出现。这不是漏报，是设计如此。
- 必须用
sudo iotop -o，否则看不到真实情况 - 按
p键切回 PID 视图，别被同一进程的几十个 TID 刷屏 - 按
O（Shift+o）按带宽降序，快速定位大户 - 容器环境里，
iotop显示的是宿主机视角，PID 和容器内不一致，得用docker top或crictl ps对齐
pidstat -d 监控指定进程时容易踩的坑
想盯住 java 或 nginx 的实时读写速率，pidstat -d 最准，但参数错一步就白忙。
常见错误是只输 pidstat -d，它执行完立刻退出；或者用 pidstat -d 0，这会让内核疯狂采样，终端卡死甚至触发 OOM。
- 必须带采样间隔：
pidstat -d 1表示每秒刷新一次 - 用
pgrep -f定位 PID 更可靠：pidstat -d 2 -p "$(pgrep -f 'java.*-Dspring')" - 输出中只认
rkB/s和wkB/s，别误读成 MB/s（单位是 KB） - CentOS 7.9 等老系统仍广泛使用，但已停止维护，
pidstat在这类系统上行为稳定，无需额外适配
单看一个工具容易误判，交叉验证才靠谱
iostat 显示 %util 很低，但 iotop 看到某个进程狂写——这时要查 vmstat 1 的 bi/bo 是否同步升高。若不升高，说明还在 page cache 里，压力还没到磁盘层；若同步升高，才是真实落盘压力。
更隐蔽的问题是：NVMe 设备支持多队列，%util 失效，得靠 avgqu-sz > 1 来判断排队；而 await 高但 svctm 低，说明卡在队列里，不是磁盘慢，可能是上层锁竞争或调度问题——这个差值经常被忽略。
