vmstat首行是系统启动以来的平均值，非实时状态；应关注第二行起的采样数据，其中r为就绪队列长度，us/sy为CPU用户/内核态占比，si/so高表明内存压力大，bi/bo大说明磁盘I/O密集。
vmstat 输出字段怎么看才不懵
直接看 vmstat 第一行数字容易误判，因为那是系统启动至今的平均值，不是实时状态。真正该盯的是第二行及以后的数据——它们才是采样周期内的实际表现。
关键字段含义要记牢：r 是就绪队列长度（不是 CPU 使用率），us/sy 才是用户态/内核态 CPU 占用，si/so 高说明在疯狂换页（内存压力大），bi/bo 大代表磁盘 I/O 密集。
- 运行
vmstat 1每秒刷新一次，跳过首行再观察 -
r > CPU 核心数表示有任务在排队，不一定是 CPU 瓶颈，也可能是 I/O 等待拖住进程 -
free列数值持续低于几百 MB（比如 < 200），且si/so> 0，基本可断定内存不足
为什么 vmstat 1 5 的第五次输出总不准
vmstat 1 5 会输出 6 行：第 1 行是平均值，后 5 行是每秒采样。很多人误把第 1 行当“初始状态”，其实它包含从开机到此刻的所有统计，完全不能反映最近一秒负载。
更糟的是，如果系统刚启动不久，第 1 行的 in（中断次数）、cs（上下文切换）等指标会被严重拉低，导致后续对比失真。
- 想看稳定周期数据，用
vmstat 1 5 | tail -n +2 | head -n 5跳过首行 - 生产环境排查突发抖动，至少采集 30 秒以上（如
vmstat 1 30），再人工扫尾部 10 行 - 不要依赖单次
vmstat快照做容量评估，它没有历史趋势，容易漏掉尖峰
和 top、htop 比，vmstat 少了啥又多了啥
top 和 htop 能看到具体哪个进程吃 CPU 或内存，vmstat 做不到；但它能暴露这两者看不到的底层资源流转问题——比如 CPU 看似空闲（id 高），但 wa（I/O wait）也高，说明进程卡在磁盘读写上，而 top 只显示该进程为 “D” 状态，不告诉你原因。
- 查 CPU 是否真空闲？看
us+sy+id+wa总和是否接近 100%，若远低于，可能是采样间隙错过活动 - 怀疑内存泄漏？连续跑
vmstat 2，观察free是否线性下降、si是否缓慢爬升（而非突增） -
vmstat不依赖 /proc，对极低配容器或 chroot 环境更可靠；但没进程维度，必须配合pidstat -r或ps aux --sort=-%mem定位
vmstat 在容器里为啥数值怪怪的
宿主机上运行 vmstat 看到的是整个物理机视图；进容器执行，多数情况下仍显示宿主机数据（除非用了 cgroups v2 + 特定内核配置），所以你看到的 free 内存可能远大于容器内存限制，r 队列也可能包含其他容器的进程。
更隐蔽的问题是：容器若设置了 --memory 限制，内核会通过 memory cgroup 控制分配，但 vmstat 的 swpd、free 等字段不会自动按容器视角缩放。
- 在容器中排查，优先用
cat /sys/fs/cgroup/memory/memory.usage_in_bytes和memory.limit_in_bytes - 宿主机上监控容器负载，用
docker stats或cgroup工具比vmstat更准 - 某些老内核（如 3.10）+ systemd 启动的容器，
vmstat的bi/bo甚至会把 overlayfs 元数据操作也算作磁盘 I/O，造成误报
r 和 wa 同时升高时，到底是磁盘慢、内存紧，还是调度器被压垮，得靠多工具交叉验证。 
