iostat -dx 1 是观测设备级瞬时读取峰值最直接低开销的方式，每秒刷新一次，rkb/s 列即当前每秒读取kb数，其跳动最高值即为峰值；需加-d纯看磁盘、-x显示指标、指定设备或分区可聚焦目标，同时配合pidstat -d 1定位高读进程。
用 iostat -dx 1 看设备级瞬时读取峰值
系统级“读取速率峰值”不是某个固定值，而是动态出现的瞬时高点，iostat -dx 1 是最直接、开销最低的观测方式。它每秒刷新一次，rkB/s 列就是当前设备每秒读取的 KB 数——这个值跳得最高的那几秒，就是你想要的“峰值”。
注意别被默认输出干扰：iostat 默认带 CPU 行，加 -d 才纯看磁盘；-x 必须带上，否则看不到 rkB/s；1 是采样间隔，太长会漏掉尖峰，太短（如 0.1）可能刷屏且无实际意义。
- 聚焦某块盘：用
iostat -dx 1 /dev/sdb，避免被其他空闲盘干扰 - 想看 LVM 或分区拆分数据：加
-p ALL，例如iostat -dx 1 -p ALL - 别只盯
%util：HDD 和 SSD 对队列容忍度不同，%util高不等于读取瓶颈；rkB/s突然冲到理论带宽 80% 以上，再结合r_await > 20ms，才是真实读取压力信号
用 pidstat -d 1 定位哪个进程在制造读取峰值
iostat 告诉你“哪块盘在狂读”，但不知道“谁干的”。这时候必须切到进程维度，pidstat -d 1 是唯一能给出实时、按 PID 拆分的读写速率的工具。
关键点在于：它输出的 rkB/s 和 wkB/s 是真实瞬时值（单位 KB/s），不是累计或平均——所以盯着它滚动，哪个 PID 的 rkB/s 突然飙到几百甚至几千，基本就是罪魁。
- 必须带采样间隔，
pidstat -d单独执行完就退出，看不到峰值变化 - 别用
pidstat -d 0：内核会疯狂上报，终端卡死，还可能触发 OOM - 精准指定进程：用
pgrep -f配合，比如pidstat -d 1 -p "$(pgrep -f 'mysqld')"，比ps aux | grep抗干扰强得多 - 注意 TID/ PID 切换：按快捷键
p可切换线程视图，避免把一个 Java 进程的多个 GC 线程当成多个独立高读进程
为什么 iotop -o 容易错过读取峰值
iotop 界面友好，但它的设计逻辑和“峰值观测”天然冲突：-o 参数只显示“当前有 IO 活动”的进程，而真实业务中，一次大读往往由单次系统调用触发（比如 mmap + readahead），持续几十毫秒就结束——iotop 每秒刷新一次，大概率刚好错过。
更麻烦的是权限问题：非 root 用户运行 iotop 会静默跳过所有用户进程的 IO 数据，只显示内核线程（如 kswapd），看起来一片空白，误以为没读压力。
- 必须用
sudo iotop -o，否则数据残缺 - 去掉
-o能看到全量进程，但噪音极大，峰值容易被淹没 - 容器环境尤其不准：cgroup v2 下，
iotop显示的是宿主机视角的合并 IO，不反映容器实际被限制后的读取能力 - 如果真要用，按
O（Shift+O）按读带宽降序，再盯住 top 3 的DISK READ列跳动，比默认排序更有效
dd 和 hdparm 测不出“系统运行时的读取峰值”
dd if=/dev/sda of=/dev/null bs=1M 或 hdparm -t /dev/sda 测的是磁盘理论顺序读能力，属于“空载最大吞吐”，和系统真实负载下的读取峰值不是一回事。它们会压满 IO 队列、绕过 page cache、干扰正常业务，测出来的是“我能塞多快”，不是“现在正有多快”。
真正要观察系统运行中的读取峰值，核心是两个动作：一是用 iostat -dx 1 锁定设备层瞬时 rkB/s，二是用 pidstat -d 1 同步抓对应进程。两者时间戳对齐、数值趋势一致，才能确认是哪个进程在哪块盘上打出了真实峰值。
复杂点在于：峰值往往是短时突发，持续不到 1 秒；而多数工具默认刷新节奏或权限控制，会让它一闪而过。所以别依赖单一命令，也别指望“一键出峰值”，必须组合、同步、带权限地看。
