1. 从虚拟内存统计说起为什么需要一张系统运行快照前几天处理一个客户的服务器问题现象非常典型白天业务正常一到晚上跑批任务就卡顿top上看CPU和内存都正常但就是慢。现场同事折腾了半天没头绪我远程上去先敲了一条命令vmstat 2 5输出里wa列的数字让我立刻锁定了方向——CPU大量时间在等待I/O结合跑批任务的写入特征判断是磁盘队列拥塞。后来确认是某些批处理脚本产生了严重的随机写放大。最终的修复其实不复杂但如果没有vmstat这张系统运行快照排查还得绕好几个小时。这就是我写这篇文章的动机。很多运维同行习惯把top当作第一排查工具但在定位系统整体是否健康这类问题上vmstat提供的是完全不同的视角——它把CPU、内存、I/O、中断、上下文切换、交换分区等关键指标压缩到一张表里几秒钟就能判断病根在哪个子系统。这篇文章不是抄man page而是从实际使用角度把vmstat讲透每条输出代表什么、哪些指标组合能定位问题、最优参数怎么敲、常见误读怎么避开以及它和类似工具free、top、iostat、sar等如何配合。无论你是刚接手服务器的运维新手还是想加深系统调优理解的后端开发读完应该能把这工具用得比绝大多数同事更专业。2. 先弄明白vmstat的设计逻辑一屏数字背后的内核数据源vmstat全称是Virtual Memory Statistics名字里带virtual memory是因为它的历史渊源——早期版本是专门统计虚拟内存子系统行为的。但随着Linux内核的发展它逐渐演变成一台系统健康状态监视器虚拟内存相关指标只是其中一部分。它的工作原理非常简单vmstat通过读取/proc/vmstat、/proc/meminfo、/proc/stat这几个内核维护的计数器文件把原始计数换算成可读的指标再格式化成表格打印。你甚至可以不用vmstat命令直接看这几份文件也能得到同样信息但人肉换算太痛苦工具存在的意义就是把这些枯燥的计数器变成一眼能看懂的数值。2.1 三条命令区分使用场景# 一次性快照适合快速看一眼系统是否健康 vmstat # 每隔2秒采样一次共采集5次适合观察波动和短期趋势 vmstat 2 5 # 持续采样直到手动CtrlC终止适合长时间观察 vmstat 2注意第一和第二条的区别第一条输出的是自系统启动以来到当前时刻的平均值这个数据意义不大——毕竟它把昨天乃至上个月的负载都平均进去了第二条才是真正有用的实时采样。vmstat 2 5是我日常使用频率最高的一条命令它构建了两层信息第一条表头下方第一行依然是从开机到现在的平均值而后续每行则是上一个采样周期内的增量值。2.2 procs、memory、swap、io、system、cpu六大区域的完整解读vmstat输出分六个区域很多人记住表头就完事了但表头缩写背后对应的内核计数器你最好也搞清楚这样遇到异常指标时才能快速判断是内核哪个子系统出了状况。区域字段含义背后数据源procsr运行队列中的进程数含正在运行和等待CPU的/proc/stat中的procs_runningprocsb不可中断睡眠进程数典型是等I/O/proc/stat中的procs_blockedmemoryswpd已使用的交换空间总量KB/proc/meminfomemoryfree空闲物理内存KB/proc/meminfomemorybuff用作块设备缓存的物理内存KB/proc/meminfomemorycache用作页缓存的文件缓存KB/proc/meminfoswapsi从磁盘交换入内存的速率KB/s/proc/vmstat中的pswpinswapso从内存交换出到磁盘的速率KB/s/proc/vmstat中的pswpoutiobi从块设备接收的块数每秒/proc/vmstat中的pgpginiobo发送到块设备的块数每秒/proc/vmstat中的pgpgoutsystemin每秒中断数时钟中断硬件中断/proc/stat中的intr增量systemcs每秒上下文切换次数/proc/stat中的ctxt增量cpuus用户态CPU时间占比/proc/stat中的cpu逐项计算cpusy内核态CPU时间占比/proc/stat中的cpu逐项计算cpuid空闲时间占比/proc/stat中的cpu逐项计算cpuwa等待I/O完成的时间占比/proc/stat中的cpu逐项计算cpust被虚拟机管理程序偷走的时间占比/proc/stat中的cpu逐项计算这里我重点说几个容易被忽略的字段。procs下的b字段很多人只看r运行队列却不看b阻塞在I/O上的进程数。当b持续大于0尤其是耦合着cpu的wa偏高说明系统存在明显的I/O瓶颈。有一次排查数据库性能问题vmstat 1采样里b列长期在5以上wa在30%左右系统响应缓慢。那时top里看到的进程CPU占用并不高但大量线程在等磁盘。如果不看b和wa单纯优化SQL可能完全不解决问题。swap下的si和so这两个字段一出现非零值基本可以判定物理内存吃紧。特别是so换出持续大于0时说明内存压力已经很严重内核在不停地把匿名页写回交换分区。我见过不少服务器内存加到64G甚至128G但应用层存在内存泄漏导致si/so依然频繁跳动。system下的cs上下文切换次数是判断系统忙得有没有效率的关键指标。如果cs数值很高比如每秒几万甚至数十万但cpu的us和sy都不高说明系统可能出现了锁竞争或者过度调度大量CPU时间消耗在线程切换上。多线程应用优化时这个字段是衡量线程数量是否合理的一种参考。cpu下的st只有虚拟机或容器环境才会有明显数值st高意味着宿主机CPU资源被抢占。假如你在云主机上发现st长期超过10%应用再慢也别急着调优自己的代码先考虑是不是宿主机超卖太严重。2.3 一次输出实例的完整解读示范我在一台测试机上跑vmstat 2 3得到如下输出procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 6248620 86544 3114216 0 0 12 23 7 12 4 4 92 0 0 5 0 0 6243284 86544 3114268 0 0 912 5406 1102 2334 31 14 43 12 0 3 0 0 6239988 86544 3114300 0 0 724 4021 989 2102 28 13 50 9 0第一行是系统启动以来的平均值参考意义有限。从第二行开始才是真实采样r从2涨到5cs从12跳到2334说明系统并发负载明显上升io的bi和bo突然出现数百到数千的量级cpu的wa从0跳到12%明显在等I/O。此时如果鼠标再敲一条iostat -x 1大概率能抓到具体的磁盘设备利用率到瓶颈。这就是vmstat真正的用法——它告诉你哪里可能有问题再由更精细的工具去确认。3. 六类指标组合定位按场景拆解而不是孤立看数字vmstat的每个字段单独看价值有限真正值钱的是字段之间的组合关系。这就像看体检报告单一指标超标的信号和几个指标一起超标的信号诊断方向完全不同。我把常见场景拆成几类按这套思路去套排查效率会高很多。3.1 CPU瓶颈r和us/sy的组合解读当procs下的r持续大于CPU核数的2倍以上但us和sy都接近饱和合计接近100%基本可以认定是CPU计算资源不足。注意r不是正在运行的进程数而是正在运行等待运行的进程数所以r远大于核数意味着大量进程在排队。举个例子一台4核机器vmstat采样中r稳定在8左右us在70%以上。虽然sy不高但CPU已经明显超载。此时优化方向有两个先看看应用层有没有死循环或者无效计算如果没有那就得扩容。这里不要被id0欺骗——id为0说明CPU一点空闲都没有但这不等于所有核都在干活只是所有核都在排队干活。3.2 内存压力free、si、so三者联动很多人看到free剩下几百MB就开始紧张其实没必要。Linux对物理内存的使用策略是尽量多用free数值低恰恰说明缓存策略生效磁盘数据尽量缓存在内存里。真正需要紧张的是si和so连续出现非零值尤其是so。还是看组合free持续下降且si/so持续走高说明进程的匿名页开始被换到磁盘。此时top看单个进程的RES也许并不突出但系统的整体性能已经在下滑。我处理过一起案例Java应用因堆外内存增长过快内存逐渐被耗光swap活动频繁。当时vmstat 1里so已经到每秒几百KB但free还剩下几个G因为cache会先释放如果不看si/so很难发现内存已经告急后来加了一行内存监控告警才彻底解决。3.3 I/O瓶颈wa和bi/bo的组合wa持续偏高是典型I/O瓶颈信号。但wa高也可能是CPU在等待锁或磁盘控制器响应慢所以要看io区域的bi/bo是否真有大量数据传输。如果wa高但bi/bo都很低说明CPU阻塞在等待上而不是真正有I/O在跑这时要考虑是不是设备控制器卡了或者存在I/O路径上的锁竞争。有次现场环境让我印象很深某系统vmstat 1显示wa高达40%但bi/bo都不过百。我下意识以为是磁盘慢后来排查发现是存储适配器驱动有bug导致I/O请求经常超时。换驱动后wa立刻从40%掉到2%以下。这就是为什么不能只看wa必须把io字段组合着看。3.4 上下文切换风暴cs高但CPU空闲这个场景最迷惑人。你看到cs每秒几万次系统却像死了一样但us/sy都不高id还有余量。出现这种组合通常是线程数量过多导致的调度风暴或者是有大量锁竞争。怎么定位先用pidstat -w 1看哪个进程贡献了最多的上下文切换再用perf sched统计调度事件。如果确认是锁竞争最直接的缓解办法是减少锁粒度或者用无锁数据结构替代如果是线程池线程数配置过高调低线程数量往往立竿见影。这个场景我建议你特别留意cs的绝对值——超过CPU核数乘以5000就可疑乘以10000基本就是风暴了。3.5 虚拟化环境st字段的警钟云主机的vmstat里如果st长期不为0说明宿主机CPU超卖严重你的虚拟机在偷时间。这种情况下应用慢不一定是你自身代码的问题不要盲目扩容纵向资源而是要考虑换一台宿主负载更低的主机或者干脆加副本做横向伸缩。4. 实际排查案例一次数据库变慢的完整定位链理论讲完了用一个真实排查案例把整个思路串起来。有一回线上MySQL实例响应明显变慢慢查询日志却空空如也无法通过SQL维度定位。我第一反应就是先看系统层面有没有变化。连接服务器后执行vmstat 1 10输出里r从平常的1-2涨到了6-8waI/O等待在25%-30%之间波动si/so都为零。r偏高有一定CPU压力但wa也高说明I/O也在拖后腿。这种组合意味着CPU想干活但在等磁盘所以我重点排查磁盘。接着用iostat -x 1看具体盘符发现sda的%util接近100%而await到了200ms以上确实磁盘接近饱和。再往下看是哪些进程在产生大量I/O用iotop一抓发现是个夜间批处理任务在同时跑多条全表扫描的UPDATE语句。最后的处理手段并不复杂一是把批处理任务的并发度调低二是把部分查询从主库切到只读从库。改动后再次用vmstat 1 5验证r回落到2wa掉到5%以内。整个排查链路大概半小时其中vmstat花了不到10秒就给出了方向。这个案例最能说明vmstat的定位它不直接告诉你答案但它能大幅缩小问题范围让你知道该往CPU、内存还是I/O方向去查后续的精细化定位工具才能派上用场。5. 高频参数和进阶用法不要只会敲vmstatvmstat默认输出已经很有用但很多参数能让它适配更多场景。挑几个高频用法分享一下。5.1 采样次数和间隔的组合规则# 每个2秒采样1次共采集3次 vmstat 2 3 # 持续采样不限制次数 vmstat 2第一行永远是系统启动以来的平均值想跳过这一行可以用-a它会显示活跃和非活跃内存的信息输出布局稍有不同。不过实际使用中我一般不去掉第一行原因很简单第一行可以作为这台机器历史负载的参考特别是接手别人环境时第一行的r和wa大致能反映这台机器长期的健康程度。5.2 -s参数查看内存事件汇总vmstat -s这个参数会把大量内存相关的统计事件打印出来包括总内存、已用内存、活跃页、非活跃页、换入换出总量、页错误数等。因为全部是累计值适合用来和当前采样做对比比如想知道开机以来总共发生了多少次主缺页中断这个参数是最直接的。注意缺页中断分为主缺页需要磁盘I/O读入和次缺页直接从内存页表分配前者对性能影响大后者基本可以忽略。vmstat -s输出的major fault就是主缺页如果你发现它持续快速增长说明应用的内存访问模式可能存在问题或者内存配置偏小。5.3 -d和-p参数磁盘维度的补充# 各磁盘的读写统计 vmstat -d # 指定分区的读写统计 vmstat -p /dev/sda1这两个参数可以在不额外安装工具的情况下快速查看磁盘粒度的I/O统计。虽然精细程度不如iostat但胜在系统自带在没有额外软件包的环境里应急排查很管用。5.4 -a参数活跃与非活跃内存vmstat -a输出会增加act和inact两列分别展示活跃和非活跃内存的大小。Linux回收内存时会优先回收非活跃页因此inact偏高说明有大量冷数据躺在内存里如果要给应用程序腾内存空间这些非活跃页是可以被回收的。不过现实中我更常用cat /proc/meminfo里的Active和Inactive内存维度更细。6. 和其他工具配合vmstat、top、free、iostat、sar如何分工不少运维新手有个误区以为top能代替vmstat。确实top上面几行也显示负载、CPU、内存但top的核心价值是进程视角它把单个进程的CPU和内存消耗列得清清楚楚vmstat则是系统视角它整体告诉你哪个子系统有问题。两者定位完全不同严格来说是互补关系。工具核心视角最擅长的场景不足vmstat系统整体快速定位CPU、内存、I/O瓶颈方向无法定位到具体进程top进程个体看哪个进程吃CPU/内存最多系统整体健康度弱化free内存详细看内存总量、可用量、缓存构成只看内存不涉及CPU和I/Oiostat磁盘设备看块设备的利用率、队列长度、服务时间不包含内存和CPUsar历史趋势回溯历史性能数据定位昨天发生了什么需要提前部署并开启采集我的习惯打法是这样的接到问题反馈先敲vmstat 1 5判断方向是CPU、内存还是I/O。方向是CPU用top -Hp看具体是哪个线程在消耗CPU。方向是内存用free -h和cat /proc/meminfo看内存构成如果si/so异常再用top按RES排序找进程。方向是I/O用iostat -x 1看具体磁盘设备用iotop找I/O大户。需要回溯用sar查看历史负载趋势判断问题是突发的还是渐进的。这套打法虽然简单但效率极高。绝大多数性能问题在vmstat阶段就能确认方向后面几步只是进一步坐实避免白忙一场。7. vmstat常见误读这些数字陷阱你踩过几个vmstat虽然命令简单但输出里藏了不少坑。我把这些年见到的误读场景集中说一下。7.1 free小就等于内存不足新手看到free显示几百MB就恐慌实际上Linux的cache会按需释放给应用程序。看内存是否充足正确指标是free命令里available一列它才是在不触发swap的情况下还能分配多少内存。vmstat的free列只是完全空闲的物理页忽略cache的存在。7.2 wa高就一定是磁盘故障wa高只能说明CPU在等I/O但不一定是磁盘坏了。前面说过可能是驱动bug、存储链路拥堵、锁等待。先看bi/bo确认是否真有I/O流量再看iostat的await和%util如果流量不大但等待时间长问题大概率在设备或驱动不在磁盘本身。7.3 r高就等于CPU不够r高说明有大量进程在排队但排队也可能是锁竞争导致的调度停滞。之前遇到一个Java应用疯狂创建线程的场景r高达30但CPU的us只有20%系统响应极慢。后来排查发现是线程池参数配置错误导致任务不断创建新线程加剧了上下文切换形成了调度风暴。这种情况下加CPU核数毫无意义反而可能让问题更严重。7.4 第一行的数值被误当作实时状态这是最隐蔽的坑。vmstat不带参数时输出的是系统启动以来的平均值你用它来判断当下状态完全可能得出错误结论。我见过有人看着第一行的r0.2就说系统很空闲但实际上此刻服务器已经被压垮了——因为开机时间很长平均值被稀释了。养成好习惯vmstat永远跟采样间隔和次数一起用。7.5 st高被误以为是CPU耗尽st是虚拟机被宿主机抢占的CPU时间云服务器里如果st高意味着宿主机资源超卖或邻居虚拟机太嘈杂。这时你不要急着优化自己系统的代码而是考虑调整部署位置或换宿主机优化自己代码解决不了宿主机抢占问题。8. 几个可以立刻用起来的小技巧和扩展最后分享几个我在实际使用中总结的小技巧谈不上高深但确实能省时间。技巧一结合watch命令动态刷新watch -n 2 vmstat 1 3watch会把vmstat的输出定时刷新在同一屏适合长时间观察变化趋势。注意外层watch -n 2控制每2秒刷新一次内层vmstat 1 3则是每次刷新前采集3次每隔1秒的数据这样实际看到的是约3秒窗口内的平均状态比单纯每秒刷一次更平滑。技巧二脚本里用vmstat做简单告警如果不想引入复杂的监控平台写个简单的shell脚本就能实现基础告警采样vmstat 1 3判断最后一行输出的wa如果连续多次超过80就通过邮件或消息接口报警。内核自带的监控方案虽然简陋但很多轻量场景够用。技巧三把vmstat和性能压测配合使用做压测时终端开着一路vmstat 1压测脚本跑完后再看日志能清晰记录每一秒的系统状态。这个做法比压测结束后再看汇总数据有价值得多——你能看到瓶颈是何时出现的、哪项指标先报警这对调优方向极有指导意义。技巧四处理大量输出时用日志记录如果系统性能是间歇性出现问题人肉盯屏幕不现实。可以这样记录一段时间内的采样比如每5秒一次记录10分钟vmstat 5 120 /tmp/vmstat_$(date %Y%m%d_%H%M%S).log等下次问题复现时这份日志能帮你重建故障前后系统状态的变化过程。我排查一些偶发性卡顿时经常靠这类历史日志找规律。9. 从vmstat看Linux整体调优思想工具讲得差不多了我想从方法论层面做个总结。很多人学了一堆命令却还是不会排查问题本质原因是没有理解Linux性能调优的核心思想。vmstat的六个区域procs、memory、swap、io、system、cpu不是孤立设计的它们构成了一个循环模型运行队列长度procs.r反映CPU供需关系内存和交换memory、swap反映资源的下层供给I/Oio反映磁盘链路system反映中断和调度cpu则汇总时间片去向。任何性能问题在这个循环里一定能找到断裂点。回到最开始的数据库变慢案例r升高说明任务在排队wa升高说明排队等的是I/Obi/bo升高说明I/O确实繁忙于是问题锁定在磁盘链路。整个推理链路如果走对了基本一次到位。所以我的建议是不要孤立地记命令参数而是建立系统是一条流水线的心智模型。CPU是工人内存是工位旁的临时堆放区磁盘是原料仓库I/O是传送带上下文切换是工人换岗。哪一环堵了哪一环的指标就会异常。vmstat不过是把每一环的状态都搬到你面前而已。模型建立之后vmstat在你的工具箱里就不再是一条生硬的命令而是一张系统健康仪表盘。配合top、iostat、sar你完全可以在不借助商业监控软件的情况下独立完成绝大多数性能问题的定位。这套方法论是我这些年排查各类诡异性能问题最值钱的积累。