wa高但si/so低说明I/O等待集中在磁盘而非内存换页，需用iostat -x排查磁盘延迟，而非盲目调内存参数。
vmstat 输出里 wa 高但 si/so 很低，说明什么
这通常意味着 I/O 等待集中在磁盘（尤其是慢盘或高延迟设备），而不是内存换页。wa 是 CPU 等待 I/O 完成的时间百分比，它和磁盘响应时间强相关；而 si/so 低说明 swap 活动几乎为零，内存压力不大。
常见错误现象：误以为 wa 高 = 内存不足，于是盲目加内存或调 swappiness，结果毫无改善。
- 先确认是不是某块盘卡住：
iostat -x 1看%util和await，单盘%util持续 >90% 或await>50ms 就是瓶颈 -
wa高但iostat显示各盘%util都很低？可能是 NVMe 多队列或 SCSI 多路径下的统计偏差，改用iostat -xz 1看更细粒度的r_await/w_await - 注意 vmstat 默认采样间隔是 1 秒，短时尖峰容易漏掉；生产排查建议用
vmstat 1 10抓连续 10 秒，避免只看单次瞬时值
iostat 的 -x 和 -d 参数到底该用哪个
-x 开启扩展统计（包括 await、svctm、%util），是定位 I/O 延迟问题的必备选项；-d 则跳过 CPU 统计，只输出设备行——但它不自动开启扩展字段，单独用 iostat -d 会丢失关键延迟指标。
使用场景：日常巡检用 iostat -dx 2，既省去 CPU 行干扰，又拿到完整磁盘性能维度；写监控脚本时如果只要吞吐量（r/s, w/s），可用 iostat -d -k 1 1（-k 统一单位为 KB）。
-
svctm在 Linux 2.6.32+ 已被内核弃用，实际显示的是估算值，不可信；专注看await和r_await/w_await - SSD 场景下
%util可能失真（队列深度大时利用率仍低），此时更要结合avgqu-sz（平均队列长度）判断是否压满 - 容器环境里，
iostat默认统计的是宿主机设备；想看某个容器的磁盘行为，得进容器 ns 或用cgroup的io.stat，iostat本身做不到
为什么 vmstat 1 和 iostat -x 1 看到的 I/O 数值经常对不上
根本原因是数据来源不同：vmstat 读的是 /proc/stat 的汇总计数器（含所有块设备 + swap I/O），而 iostat 解析的是 /proc/diskstats，按设备逐个统计，且默认排除了 loop、ram、zram 等伪设备。
典型差异点：当系统有大量 swap I/O 或使用了 device-mapper（如 LVM、加密卷），vmstat 的 bi/bo 会包含这些，但 iostat 只显示底层物理盘（比如 sda）或 mapper 设备（如 dm-0），取决于你是否加了 -p 参数。
- 查具体设备对应关系：
ls -l /sys/block/*/dev或lsblk -d -o NAME,MAJ:MIN - 想让 iostat 包含所有块设备（含 loop、zram），加
-p ALL，但注意 zram 的 I/O 实际是内存压缩，和磁盘无关 - vmstat 的
bi/bo单位是块（512 字节），iostat 默认是扇区（也是 512 字节），数值可比；但若 iostat 加了-k或-m，单位就变了，直接对比会差 1024 倍
生产环境跑 iostat -x 1 会不会影响性能
几乎无影响。iostat 本身不触发 I/O，只是定时读取内核暴露的统计接口（/proc/diskstats），开销远低于一次 stat() 系统调用。即使在万 IOPS 的 NVMe 服务器上，持续运行 iostat -x 1 也看不到可观测的 CPU 或延迟变化。
真正要小心的是误操作：比如在高负载机器上同时跑 iostat -x 1、vmstat 1、pidstat -d 1、iotop 四个工具，它们底层都频繁读 /proc，可能造成轻微的 page cache 挤出，尤其在内存吃紧时。
- 监控采集推荐用
iostat -x -y 1 1（-y跳过首行初始值），配合awk提取关键字段，避免全量输出刷屏 - 不要在 crontab 里写
* * * * * iostat -x 1 5 > /tmp/iostat.log—— 这会启动 5 个 iostat 进程，且日志不断追加，文件会滚大 - 如果发现 iostat 自身延迟变高（比如预期 1s 一刷，实际卡 3s），大概率是系统已经严重卡顿，iostat 只是第一个暴露问题的工具，不是原因
事情说清了就结束。真正难的不是看懂数字，而是把 await 高和业务慢联系起来，再定位到具体 SQL、日志轮转策略或者那个忘了关 sync 的 rsync 进程。
