1. 先搞明白一件事为什么性能测试必须盯着服务端资源我见过太多人跑Jmeter压测流程走得挺顺——线程组配上、接口填好、聚合报告一跑看着响应时间没涨、错误率是0就拍板说系统没问题可以上线。但没过多久生产环境一上量就卡成PPT。这种翻车现场问题几乎都出在同一个地方只看了客户端视角的指标完全没看服务端资源到底扛不扛得住。这里想先讲一个很朴素的道理。Jmeter的聚合报告、响应时间、TPS本质上都是站在调用方视角看到的表象。举个例子你用一个线程组去压一个接口如果服务端的CPU早就被打满到95%以上但这台机器的负载均衡或者限流策略恰好让你的请求全部排队等待你看到的响应时间可能依然很平稳——因为请求根本没有真正执行都在队列里堆着。反过来有时候TPS掉得很厉害但服务端CPU不到20%这时候瓶颈根本不在服务端可能在数据库连接池、可能在带宽、可能在Jmeter自己的线程配置上。所以我一直跟团队里的人说一句话性能测试不是看接口快不快而是看系统在什么资源水位下能保持多快。响应时间和TPS只是结果服务端的CPU、内存、磁盘IO、网络连接数这些才是原因。这个因果关系理清楚了后面所有监控手段才有意义。这篇文章要聊的服务端资源监控技术适合下面几类人刚入门Jmeter能跑出压测报告但不知道怎么看系统瓶颈的新手测试。需要在报告里拿出CPU到顶了导致TPS上不去这类实锤证据的测试工程师。想低成本搞定服务端指标采集不想一上来就上整套APM平台的小团队。核心思路不复杂先明确指标清单再选对采集工具最后把资源数据和压测数据放在一起分析。下面我会把这四步逐层拆开每一步都给出可以直接照做的方案。2. 服务端资源监控到底在看什么指标清单与判断红线很多人以为看资源就是瞄一眼CPU高不高这其实是最粗的用法。真正有效的监控是先把这台机器在压测过程中经历了什么这件事量化出来。我习惯把指标分成三个层级每一层解决不同的问题。2.1 第一层利用率类指标——CPU、内存、磁盘、网络这四类指标回答的问题是资源够不够用。日常压测中我会重点盯以下几个CPU。这里要区分整体使用率和每个核心的使用率。整体使用率看的是系统平均水平但如果你的服务是单线程模型或者有CPU密集的锁竞争单个核心打满反而是更值得警惕的信号。Linux下用top进入交互界面后按1就能看到每个核心的负载。判断红线方面持续超过70%就要留意超过85%基本可以认定CPU已经成了瓶颈。内存。内存不能只看用了多少关键指标是available可用内存和swap的使用情况。很多人盯着free命令里那个used值看其实在Linux的内存管理机制下used里包含大量page cache这些缓存是可以随时释放给进程用的。真正危险的是available快速下跌以及swap分区开始被频繁读写。如果swap的si和so两个值长期不为0说明物理内存已经扛不住了。磁盘IO。压测过程中磁盘IO经常被忽略但它对性能的影响往往很致命。看两个关键值%util设备繁忙程度接近100%说明磁盘已经跑满和awaitIO请求的平均等待时间这个值飙升通常意味着磁盘队列堆积。数据库类的服务端对磁盘IO尤其敏感。网络。网络指标里最实用的不是带宽利用率而是TCP连接的状态分布。ss -s命令可以快速看到当前系统的TCP连接总数和状态。如果TIME_WAIT连接数持续高位会导致端口被占满新连接建不起来表现在业务上就是偶尔超时重试又好了。压测工具视角看到的网络延迟上升很多其实是服务端连接队列溢出导致的。2.2 第二层饱和度类指标——负载、上下文切换、队列长度利用率指标看的是资源忙不忙饱和度指标看的是资源忙到什么程度、有没有积压。这是更敏感的预警信号。Load Average负载均值。我用一个粗线条的参考标准Load值持续高于CPU核心数的1.5倍时说明CPU已经过载任务在排队。比如8核的机器Load超过12就要警惕了。上下文切换cs。vmstat里的cs列或者pidstat -w可以看到更细的进程级切换量。上下文切换本身是正常现象但如果压测过程中该值从几千突然飙到几万往往是线程数配置过大、锁竞争严重、或者频繁的系统调用导致的。这个问题很多新手根本不会往这个方向查结果压测报告里CPU不高、内存够用但接口就是慢最后发现是线程上下文切换把时间吃掉了。运行队列。vmstat的r列表示等待运行的任务数。这个值长期大于CPU核心数说明任务已经消化不过来后面的请求只能排队。这一列的值和响应时间的变化趋势放一起看经常能对上。2.3 第三层进程级与应用级指标——真正找到是哪个进程在捣乱前面两层都是系统整体视角。实际排查时你会发现一个尴尬的问题机器整体CPU不高但接口就是慢。这时候必须下沉到进程级。进程级最核心的两个指标是单个进程的CPU占比和进程的线程数。定位方法很简单先用top按CPU排序找到哪个进程占用最高再用top -Hp 进程号查看进程内部的线程排序如果是Java应用用jstack导出线程快照配合线程号就能定位到具体代码块。这一层在压测中特别重要。我遇到过不止一次这样的情况压测接口本身没消耗多少CPU但同一台机器上有个日志收集的Agent在疯狂写磁盘把IO挤爆了。如果不看进程级指标你会误判成接口代码有性能问题排查方向直接跑偏。2.4 把指标落到判断上一张参考红线表上面说的判断红线我汇总成一张常备的参考表注意这里的数值是经验值不是绝对标准不同业务对响应时间的容忍度不一样但资源红线的参考性比较强指标关注值预警信号通常意味着什么CPU利用率整体/单核持续70%峰值85%计算密集或锁竞争可用内存available持续下跌接近0swap读写频繁内存不足触发GC或换页磁盘%util设备繁忙度接近100%磁盘IO瓶颈磁盘await平均IO等待30ms且持续上升磁盘队列堆积Load Average对比核数核数×1.5CPU过载任务排队上下文切换cs列瞬时翻倍且居高不下线程过多或锁竞争TCP TIME_WAIT连接状态持续高位且端口耗尽连接释放异常运行队列rvmstat r列CPU核数任务积压这张表不需要背压测时打印出来放在旁边每个指标对应一个问题方向。后面讲到数据分析时这些红线值就是判断瓶颈出处的依据。3. 三种主流监控方案的横向对比从Jmeter原生到命令行明确了指标清单之后下一个问题是工具用什么。服务端资源监控的工具体系非常大从轻量级的命令行工具到企业级的监控平台都有。我不打算全讲只讲三种我实际用过的、覆盖不同场景的方案然后给出选型建议。3.1 Jmeter原生监听器能看但有一个致命限制先说一个很多人不知道的事实Jmeter本身并不直接采集服务端资源。你装完Jmeter打开监听器列表看到的Aggregate ReportResponse Time Graph这些全部是站在Jmeter自己这台机器也就是压测机视角的数据。想监控服务端要么装插件要么用外部工具。插件方案里最常用的是PerfMon (Servers Performance Monitoring)由jpgc插件系列提供。它的工作方式分成两部分ServerAgent一个部署在服务端的小程序负责采集CPU、内存、磁盘、网络等指标然后通过端口默认4444对外提供数据。Jmeter侧的PerfMon监听器压测过程中向ServerAgent请求数据并把曲线画在Jmeter的监听器面板里。这个方案的好处是曲线可以直接和TPS、响应时间画在同一个报告里对齐时间轴非常方便。缺点有两个一是ServerAgent本身的性能开销虽然小但不是0在生产环境压测时要留意二是Jmeter监听器界面本身在数据量大时会拖慢压测机压测机如果配置不高建议用后面两种方案。3.2 命令行工具全家桶轻量、无侵入、Linux运维的基本功如果你只需要压测期间的资源数据不想引入任何额外的部署组件那Linux自带的命令行工具就是最稳妥的选择。我的常用组合是这样的top/htop全局进程和CPU、内存概览。vmstat 1每秒刷新的运行队列、上下文切换、CPU、内存、swap数据。iostat -x 1磁盘IO的详细指标。sar -n DEV 1网络流量统计需要安装sysstat包。pidstat -w 1进程级的上下文切换统计。这些命令的数据是文本流可以重定向到文件里vmstat 1 60 vmstat_output.txt iostat -x 1 60 iostat_output.txt压测结束后直接打开文件分析。这个方案的优势是零依赖、只要SSH能连上服务端就能用对服务端应用本身完全无侵入是排查问题时最可信的底层数据来源。缺点是没有图形曲线数据需要自己脑补趋势而且多个命令的数据要手工对齐时间轴稍微麻烦一点。3.3 外部监控平台Prometheus node_exporter Grafana适合长期监控和回归对比如果你所在的团队已经把性能测试常态化每一次发版都要跑回归压测那就值得上一套轻量的监控平台。我的推荐组合是Prometheus抓取数据、node_exporter暴露服务端指标、Grafana做可视化面板。这个方案的优势非常明显node_exporter采集的指标维度比命令行工具全得多包括文件系统、网络协议栈、CPU各层状态等Grafana面板可以保存成一个固定的压测监控模板每次压测复用同一套视图历史数据可以留档这次压测和上次压测的资源水位可以直接叠加对比。缺点是初始部署要花半小时到一个小时。不过按照我下面的步骤走其实也快# 下载并解压 node_exporter wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz tar -xzf node_exporter-1.7.0.linux-amd64.tar.gz cd node_exporter-1.7.0.linux-amd64 # 启动默认监听9100端口 ./node_exporter 然后在Prometheus的配置里加一个抓取任务scrape_configs: - job_name: node_exporter static_configs: - targets: [服务端IP:9100]Grafana的配置这里就不展开了网上有很多现成的Node Exporter Full仪表板模板导入即用。3.4 选型建议什么时候用哪个这三套方案不是互斥关系我实际项目中的用法是分层的日常快速压测、临时验证用Jmeter的PerfMon插件因为曲线直接出在报告里分析快深度问题排查、需要实锤数据用命令行工具落盘因为粒度细、无侵入还能交叉验证PerfMon的数据是否准确持续压测、回归对比用Prometheus Grafana因为历史数据和面板复用价值高一键看到趋势变化。4. PerfMon插件从零到一服务端Agent部署与Jmeter端配置全流程这一章单独把PerfMon插件的完整配置过程拆开讲。原因很简单它是我接触过的最容易被小细节卡住的方案。下面每个步骤都是踩过坑之后的最终版本。4.1 第一步Jmeter端安装PerfMon监听器Jmeter的插件安装有两种常见路径。第一种是用Plugins Manager自动安装第二种是手动下载jar包放进lib/ext目录。推荐第一种从Jmeter官网下载Plugins Manager的jar包放到JMETER_HOME/lib/ext目录下重启Jmeter在工具栏上会多出一个Plugins Manager的图标。打开后在Available Plugins标签页里搜索PerfMon勾选安装重启Jmeter。插件安装完成后右键测试计划添加监听器你会看到jpgc - PerfMon Metrics Collector这个选项。这里有一个很关键的版本兼容问题Jmeter 5.x和旧版Jmeter对插件的兼容性要求不一样如果安装后监听器列表里看不到PerfMon优先检查Jmeter版本和插件管理器版本而不是怀疑安装步骤出错。4.2 第二步服务端部署ServerAgentServerAgent的官方下载地址在JMeter plugins的对应页面下下载的是一个zip包。解压后目录里有两个关键文件startAgent.shLinux/macOS和startAgent.batWindows。Linux下的标准启动方式是chmod x startAgent.sh ./startAgent.sh默认监听4444端口。如果4444端口被占用可以用AGENT_PORT环境变量指定新端口AGENT_PORT5555 ./startAgent.shWindows机器直接双击startAgent.bat弹出的黑色命令行窗口不要关关闭窗口意味着Agent退出。启动成功后服务端的准备工作就完成了这一步可能碰到的问题我在第6章统一说。4.3 第三步配置PerfMon监听器把服务端的指标拉过来回到Jmeter打开刚添加的PerfMon Metrics Collector监听器你会看到如下配置项Host/IP填写服务端的IP地址注意这个IP是Jmeter这台机器能访问到的IP不是服务端本机看到的IP。Port默认4444如果你在服务端指定了其他端口这里要同步修改。Metric collection一排可勾选的指标项常用的是CPU、Memory、Disk、Network I/O。Add Row每添加一行配置一个监控指标。我通常会加四行分别监控CPU、内存、磁盘、网络。配置完成后点击面板上的测试按钮如果能看到一条时间轴开始滚动说明连接成功。注意一点PerfMon监听器的曲线是实时刷新的压测开始前就打开它这样才能看到压测前、压测中、压测结束后的完整资源变化曲线尤其是释放阶段的回落曲线对判断资源是否有残留占用非常关键。4.4 第四步压测结束后的数据导出操作PerfMon监听器的面板上有Write results to file选项建议压测开始前就勾上并指定输出文件。导出的是CSV格式每一行带时间戳和指标值。这一步经常被省略但它决定了你后续能否做深入分析。我自己的习惯是无论压测规模大小都会导出这份CSV然后和Jmeter的聚合报告CSV放在同一个目录。分析时先把两份文件的时间轴对齐再用Excel或者Python脚本把资源曲线和响应时间曲线上下叠在一起看。这个工作看起来繁琐但做过一次就会发现这是定位瓶颈最快的方式——两条曲线的拐点在同一个时间点发生变化那个时间点附近发生的事情就是瓶颈的根源。5. 监控数据不会白看把资源曲线和TPS联动起来的分析方法工具装上去了曲线跑出来了然后呢很多人卡在这一步盯着满屏的曲线不知道下一步该做什么。这一章用几个真实场景底色的案例讲清楚看到指标之后怎么定位问题的分析方法。5.1 案例一CPU打满导致TPS上不去——先看拐点再下结论假设你压一个接口并发从50加到200TPS前期稳步上涨到并发100左右开始持平甚至下跌响应时间开始抖动。这时候打开服务端的CPU曲线大概率能看到CPU在某一个时间点后持续稳定在85%以上。分析链路是这样的CPU持续高位说明服务端的计算资源已经耗尽此时再增加并发只会让更多请求排队等待CPU时间片反映到Jmeter端就是响应时间上涨、TPS不再线性增长。这就是典型的CPU瓶颈。定位到CPU瓶颈后下一步是区分这个CPU是被谁的代码吃掉的。如果服务内部有大量JSON序列化、加解密、复杂正则操作这些都属于CPU密集型优化方向是减少重复计算、加缓存、或者横向扩容。如果CPU大量消耗在内核态top命令里sy列占比高那可能是系统调用频繁、网络包处理开销大方向完全不同。5.2 案例二CPU不高但响应时间飙升——去查磁盘IO和锁这个场景我在实际项目中碰到过不止一次。压测过程中服务端CPU不到40%内存也充足但接口响应时间从50ms一路涨到800ms。如果只盯着CPU看这个问题会变得非常诡异。此时我习惯先看一眼磁盘iostat -x 1里的%util是否接近100%await是否持续高位。如果确认磁盘饱和再看服务在这个时间点的磁盘读写模式——是日志写入频繁、还是数据库的刷盘操作、或者临时文件读写三种情况对应完全不同的优化手段。如果没有磁盘问题再往下查锁竞争。Java服务用jstack抓线程快照搜BLOCKED状态的线程以及等锁的线程数量。数据库方向则查show processlist看有没有大量查询卡在同一个状态。这里要记住一个原则资源指标只是入口定位到具体瓶颈组件才算结束。5.3 案例三内存泄漏的典型曲线形态内存问题在短时间的压测里反而不太容易暴露因为Java应用的堆内存占用是锯齿形的——GC之后掉下来再慢慢升上去。真正值得警惕的曲线形态是锯齿的波谷不断抬高说明每次GC之后内存回收得越来越少内存泄漏的经典信号就是这个。监控时怎么看如果服务端用的是Java系应用jstat -gc 进程号 1000可以打出堆内存各分区的使用曲线重点关注FGCFull GC次数和FGCTFull GC耗时。如果Full GC次数随着压测持续快速增长而每次Full GC后的堆占用并没有降到相近的水位线基本可以判断存在对象无法回收的问题。配合PerfMon的内存曲线看几百MB级别的小幅上升可能被系统整体内存的波动掩盖所以进程级监控在这里是必须的单看系统级内存曲线不够。5.4 把三块数据拼在一起建立你自己的压测体检模板分析做得多了以后我慢慢形成了一套固定的体检模板。每次压测跑完不会只甩一张聚合报告图而是固定输出一组数据TPS和响应时间的变化曲线服务端CPU、内存、磁盘IO、网络的四条曲线关键时间点的进程级快照比如并发最高那个时刻的top输出和线程栈。这三个文件放在一起看才能回答系统到底卡在哪这个问题。这套模板看起来工作量多其实做熟了一轮压测也就多花二十分钟但它在排查问题时提供的价值远超过这二十分钟的成本。6. 实战中容易踩的坑端口、权限、数据失真与Agent兼容性PerfMon这套方案在实际落地时有一批照着网上教程配了但就是不行的问题。我把高频踩坑点汇总一下每一条都是我自己或团队实际遇见过的。6.1 ServerAgent起不来端口占用、Java版本、权限三连最常见的问题是端口被占用。ServerAgent默认4444端口如果你机器上已经有其他服务占用了这个端口Agent会启动失败但报错信息在Windows下往往只是一个一闪而过的窗口很容易被忽略。排查办法是先手动运行java -jar CMDRunner.jar --tool PerfMonAgent把日志留在前台才能看到具体报错。第二个坑是Java版本。ServerAgent在运行时依赖本机Java环境如果服务端装的是很老比如1.6以下的Java运行时Agent的某些功能会直接起不来。建议服务端至少装上Java 8以上的运行时这不仅仅是ServerAgent的要求也是压测环境中大多数监控工具的共同底线。第三个坑是防火墙。很多云服务器默认安全组只放行了22、80、443等常用端口4444端口不在其中Jmeter端就会一直连接超时。解决办法是在安全组规则里临时放行4444端口测试完记得关掉或者在本地测试环境直接关防火墙验证连通性。6.2 Jmeter端连不上先ping再telnet再排查连接状态如果你配置好PerfMon监听器后面板上一直显示连接失败按下面顺序排查# 第一层网络通不通 ping 服务端IP # 第二层端口通不通 telnet 服务端IP 4444ping通了但telnet失败基本可以确定是防火墙或者端口监听问题。两者都通但监听器仍然报错检查一下Jmeter端的Port字段和Agent实际的监听端口是否一致——很多人改了服务端的AGENT_PORT环境变量却忘了同步改Jmeter端配置。还有一个很隐蔽的问题PerfMon监听器有一个Timeout配置项如果你压测的服务端和压测机之间的网络延迟比较高默认的2秒超时可能不够用导致曲线时断时续。把它调大到10秒左右这个问题的概率会大幅下降。6.3 曲线数据明显异常先怀疑采集端再怀疑网络有时候曲线看着怪——CPU瞬时冲到100%又掉到2%、内存值跳变幅度不合理。遇到这种情况我的经验是先怀疑数据源本身不要急着分析业务原因。排查顺序是在服务端本地手动跑一次top和vmstat对比同一时刻PerfMon曲线上的数值。如果两者差异很大说明PerfMon的数据通路可能有问题比如网络传输丢包导致采样点缺失、ServerAgent所在机器负载本身过高导致采样延迟等。另外值得提一句ServerAgent虽然很轻量但它本身也要占一点CPU和内存资源。如果你压测的目标服务本身对资源极度敏感比如CPU本来就在90%以上那么Agent带来的额外开销可能会影响测试结果的精确性。这种极端场景下我更推荐用命令行工具落盘的方式来做监控把采集本身的开销压到最小。6.4 压测机上监听器太多导致Jmeter卡顿PerfMon监听器在压测过程中是实时刷新曲线的每一条曲线都会消耗一点CPU和内存。如果你同时监控了CPU、内存、磁盘、网络四条曲线又开了聚合报告、结果树等一堆监听器压测机本身可能成为新的瓶颈——尤其是用笔记本跑压测的同学。我的建议是压测执行时只保留必要的监听器结果树这种耗资源的组件在正式测试时直接关闭PerfMon的实时曲线也可以在稳定运行后最小化界面减少界面刷新频率对压测机资源的消耗。数据要保留一份的话靠前面说的CSV导出功能就够了。7. 压测结束复盘时的一个习惯别让监控数据变成死档案说一个我个人的工作习惯吧。每次压测归档我会把服务端监控的数据截图或者CSV文件连同压测脚本、测试报告一起放进同一个目录命名规则统一带上日期和压测场景。这个习惯一开始只是为了方便自己回头查问题后来发现它的价值远不止存档——当你把压测资料积累到一定数量再去跑新一轮压测时直接翻上一轮同场景的资源曲线就能秒级判断这次的数据是正常波动还是性能收益/劣化。这种经验积累的方式比任何理论分析都来得直观。再补一个非常实用的小技巧压测正式开始前先跑一个30秒到1分钟的预热压测并发设低一点比如目标并发的20%。这个预热阶段的作用有两点一是让JIT编译、连接池初始化、缓存加载这些启动成本先完成让正式数据更干净二是顺便校验PerfMon的数据链路是否正常。预热阶段的监控曲线如果显示ServerAgent数据不通那你有充足的时间去排查而不是等正式压测跑完才发现整个监控是空的。性能测试的工具和技巧每年都在翻新但服务端资源监控这个环节的核心逻辑始终没变把系统在压力下的真实状态量化出来让每一次变慢报错上不去都有据可查。这套方法在你压测的项目越多之后你会越来越觉得它是整个性能测试里最值得花时间做扎实的部分。