Linuxvmstat命令详解与使用方法

本文深入解析了Linux中vmstat命令的正确使用方法与常见误区，强调首行数据仅为系统启动以来的平均值、不具备实时参考价值，真正关键的是第二行起的周期采样结果；通过厘清r（就绪队列）、us/sy（CPU态占比）、si/so（换页活动）、bi/bo（磁盘I/O）等核心字段的真实含义，帮助读者精准识别CPU瓶颈、内存压力、I/O阻塞等底层性能问题，并针对性指出其在容器环境中的局限性、与top/htop的互补关系，以及如何结合其他工具进行交叉验证——让运维人员不再被数字迷惑，而是从噪声中捕获真正的系统健康信号。

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 同时升高时，到底是磁盘慢、内存紧，还是调度器被压垮，得靠多工具交叉验证。

终于介绍完啦！小伙伴们，这篇关于《Linuxvmstat命令详解与使用方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！