在 Linux 服务器运维、高并发业务上线或数据库性能巡检中，当机器出现响应变慢或资源告警时，我们往往需要在最短的时间内定位出瓶颈究竟出在 CPU、内存、磁盘 I/O 还是线程调度 上。

能够一秒纵览全局宏观状态的看家底命令，非 vmstat 莫属。本文以一线生产数据库服务器的真实 vmstat 1 5 输出为切入点，带你抽丝剥茧，彻底读懂每一个指标背后的系统真相。

一、vmstat 1 5 命令参数深度拆解

vmstat 1 5

该命令的语法结构非常直观：vmstat [采样间隔秒数] [采样总次数]。

1. vmstat：全称是 Virtual Memory Statistics（虚拟内存统计）。虽然名字带 Memory，但它实际上是操作系统的全能体检仪，能同步监控进程队列、内存利用、Swap 换页、磁盘吞吐、系统中断与 CPU 耗时。
2. 1（采样间隔）：代表每隔 1 秒采集并输出一行实时数据。
3. 5（采样次数）：代表连续输出 5 次后自动停止退出。

第一行数据的特殊含义

任何执行 vmstat 的输出，第一行数据永远是自开机以来的“历史平均值”（通常没有实时参考意义）。因此，在排查即时性能问题时，必须从第二行开始观察分析！

常见调用姿势对比：

命令形式	行为表现	典型应用场景
vmstat	仅输出 1 行历史平均值后立即退出	快速查看系统自开机以来的宏观状态。
vmstat 1	每秒刷新一次，无限循环，直到手动 Ctrl + C	压测时实时盯盘、观察流量波峰波谷。
vmstat 1 5	每秒刷新一次，采满 5 次自动交卷退出	日常巡检、脚本自动采样分析的首选。

二、真实生产回显样本全景呈现

以下是采集自某台高配置企业级数据库服务器的两次连续真实实测数据（已脱敏）：

[appuser@db-master-01 ~]$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 7  0      0 1836100 335504 74362400    0    0    40   124    0    0  6  0 94  0  0
 6  0      0 1827076 335504 74371120    0    0     0     0 8060 3419 19  0 81  0  0
 6  0      0 1818148 335504 74379872    0    0     0    32 8123 3548 19  0 81  0  0
 6  0      0 1810144 335504 74388552    0    0     0     0 8012 3371 19  0 81  0  0
 6  0      0 1799540 335504 74397248    0    0     0     0 7987 3372 19  0 81  0  0

[appuser@db-master-01 ~]$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 7  0      0 1400580 335504 74831120    0    0    40   124    0    0  6  0 94  0  0
 6  0      0 1392148 335504 74839872    0    0     0   116 7976 3377 19  0 81  0  0
 6  0      0 1383164 335504 74848576    0    0     0 429680 9403 6176 19  0 80  0  0
 6  0      0 1376220 335504 74855776    0    0     0     8 7914 3351 19  0 81  0  0
 7  0      0 1365400 335504 74864456    0    0     0   112 9472 5703 19  0 81  0  0

面对这一整屏密密麻麻的数字，我们来按板块进行地毯式拆解。

三、六大核心板块指标深度拆解

1. procs（进程调度与排队队列）

• r（Running / Runnable）：正在 CPU 上运行或在就绪队列中等待分配时间片的线程总数。
  • 回显分析：数值稳定在 6 ~ 7。对于一台多核（如 16 核或 32 核）的大型数据库服务器，始终有 6~7 个活跃工作线程在并发处理请求，处于健康而饱满的工作状态。
  • 警戒线：如果 r 长期显著大于当前服务器的 CPU 总逻辑核心数，说明 CPU 算力已严重超载，进程在排大队堵车。
• b（Blocked）：处于不可中断睡眠状态（通常是在等待磁盘 I/O 或硬件响应）的进程数。
  • 回显分析：全程稳定为 0！这证明当前没有任何进程被慢 I/O 阻塞挂起。

2. memory（物理内存分配，单位均为 KB）

• swpd：已使用的 Swap 虚拟内存大小。
  • 回显分析：0。说明完全没有动用磁盘 Swap，物理内存充裕。
• free：绝对空闲未被分配的物理内存。
  • 回显分析：约 1.8GB ~ 1.3GB。
• cache：被操作系统用作文件页缓存（Page Cache）的内存大小。
  • 回显分析：高达 74362400 KB ≈ 74.3 GB！
  • 核心知识点：很多初学者看到 free 只有 1.3G 就慌了，以为“内存爆了”。其实完全相反！在 Linux 哲学中，“空闲内存就是最大的浪费”。Linux 会把没用到的 74GB 内存统统拿来缓存热点文件与数据库数据；当业务程序需要新内存时，系统能在毫秒级瞬间回收 cache 吐出来给业务用。因此：可用内存 = free + cache，这台机器实际拥有 70GB+ 的可用弹性！

3. swap（交换分区 —— 内存生死线）

• si（Swap In）：每秒从硬盘 Swap 换入到内存的数据大小（KB/s）。
• so（Swap Out）：每秒从内存换出到硬盘 Swap 的数据大小（KB/s）。
• 回显分析：全程 0！
  • 诊断铁律：一旦 si 和 so 持续大于 0，说明物理内存被真正榨干，系统被迫使用磁盘模拟内存，整机性能将呈断崖式暴跌。

4. io（磁盘块设备吞吐，单位为 Blocks/s）

• bi（Blocks In）：每秒从磁盘读入系统的数据块数。
  • 回显分析：除首行外几乎全为 0。说明刚才提到的 74GB Page Cache 极为有效，读请求几乎 100% 命中了内存缓存，根本不需要物理读盘！
• bo（Blocks Out）：每秒写入磁盘的数据块数。
  • 回显分析：平时是 0 或几十，但在第 2 次采样的第 3 行出现了一次极为壮观的暴涨（后文深度剖析）。

5. system（系统活动与上下文开销）

• in（Interrupts）：每秒产生的硬件中断次数。日常基线约 8000 次/秒。
• cs（Context Switches）：每秒发生的线程上下文切换次数。日常基线约 3400 次/秒。
  • 回显分析：对于高负载多线程服务，这个量级的上下文切换属于完全正常的平稳开销。

6. cpu（CPU 算力耗时比例，各项总和 100%）

• us（User）：用户态 CPU 占用率。稳定在 19%，说明业务代码逻辑运行正常。
• sy（System）：内核态系统调用耗时。为 0%，极度平稳。
• id（Idle）：CPU 完全空闲率。稳定在 80% ~ 81%，说明计算资源极其宽裕！
• wa（Wait IO）：CPU 等待磁盘 I/O 的时间百分比。为 0%，磁盘没有任何拖后腿现象。
• st（Steal）：虚拟机被宿主机偷走的 CPU 时间。为 0%，说明所在宿主机毫无超卖干扰。

四、高能现场推演：第 2 次采样第 3 行发生了什么？

仔细观察第 2 次输出中的这极其特殊的一行：

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0      0 1383164 335504 74848576    0    0     0 429680 9403 6176 19  0 80  0  0

在这短短的 1 秒钟之内，系统数据发生了极其剧烈的异动：

1. 异动特征一览

• bo 瞬间飙升至 429680： 在 Linux 默认块大小为 1KB 的场景下，429,680 Blocks/s 意味着在这一秒内，系统向底层磁盘写入了大约 420MB 的海量数据！
• in（中断）飙升到 9403：磁盘控制器向 CPU 密集报告写完成中断。
• cs（上下文切换）翻倍至 6176：大量负责刷盘的后台内核线程被密集唤醒与切换。
• 随后的下一秒瞬间恢复平静：下一行 bo 立即回落至 8。

2. 这到底是什么业务行为？

这种**“平时波澜不惊，突发以 400MB/s 狂暴刷盘 1 秒，随后立刻收工”**的特征，是企业级系统中最经典的现象：

1. 数据库 Checkpoint（检查点刷脏页）：
   以 MySQL InnoDB 或 Oracle 为例，平时写入事务时只写内存 Buffer Pool 和 Redo Log；当达到特定时间窗口或脏页阈值时，后台刷盘线程（page_cleaner）会瞬间将内存中的大量脏页批量 Dump 写入底层表空间文件。
2. Linux OS Dirty Page 周期性回写：
   Linux 内核参数（如 vm.dirty_background_ratio）触发了后台 flusher 线程，将系统 Page Cache 中累积的写脏缓存集中同步刷盘。
3. 大日志或批处理文件 Flush / 切割：
   程序在短时间内完成了大批量数据导出或日志落盘。

3. 底层存储性能评估（硬核结论）

最让人惊叹的是指标 wa（Wait IO）与 b：
即使在瞬时吞吐高达 420MB/s 的极限制压下，该服务器的 wa 依然死死保持在 0%，b 依然保持在 0！
这有力地证明：该服务器底层挂载的磁盘存储（高性能 SSD、阵列或优质云盘 LVM 卷）具备极佳的瞬时 I/O 吞吐带宽，400MB+ 的数据几乎是瞬间被硬件缓存与闪存吃下，完全没有造成任何线程阻塞！

五、老运维的“3 秒快速望闻问切”口诀

在日常救火排障时，无需逐行死抠，牢记以下三秒速查口诀：

诊断方向	核心观察指标	异常告警判定特征
查 CPU 算力瓶颈	r 与 us	r 持续大于逻辑 CPU 核数；或者 us 长期处于 90% 以上。
查 磁盘 I/O 瓶颈	wa 与 b	wa > 15% ~ 20% 且 b > 0（CPU 不干活都在等盘，必卡无疑）。
查 内存爆满衰竭	si 与 so	si 或 so 持续大于 0（发生频繁换页，硬盘在当内存用，系统必卡）。
查 线程过度颠簸	cs 与 sy	cs 达到数万至数十万，且 sy 内核态 CPU 占比异常升高（线程池开太大）。

六、排障联动：宏观定性后的下钻工具

vmstat 最大的价值在于**“一秒宏观定性”**，帮你立刻锁定问题的大方向。一旦通过 vmstat 发现了异常，可以配合以下专项命令深度下钻：

• 如果发现 CPU us 很高：执行 top 后按 P，或执行 pidstat -u 1，抓出吃 CPU 的具体进程与线程；
• 如果发现磁盘 wa 很高、bo 极大：执行 iostat -xz 1，定位究竟是哪一块物理硬盘（vda、vdc 还是 dm-0）被写爆；
• 如果发现 b 阻塞进程很多：执行 iotop -o，在微观层面抓出到底是谁在疯狂读写硬盘。