JMeter性能测试进阶：使用PerfMon插件监控服务器资源，精准定位瓶颈

2026/7/8 17:45:38
JMeter性能测试进阶：使用PerfMon插件监控服务器资源，精准定位瓶颈
1. 项目概述与核心价值如果你做过性能测试肯定遇到过这样的场景用JMeter把服务器压得嗷嗷叫TPS曲线画得挺漂亮但一去看服务器CPU、内存、磁盘IO这些关键指标到底怎么样了心里完全没底。是JMeter脚本写得有问题还是服务器本身资源已经到瓶颈了这种“盲测”的感觉非常糟糕就像医生只测了病人的体温却不知道血压和心率诊断结论自然站不住脚。这正是我们今天要解决的痛点。JMeter本身是个强大的“压力发生器”但它天生不擅长做“系统体检”。它生成的报告比如聚合报告、图形结果更多反映的是客户端即JMeter自身感受到的响应时间、吞吐量而对于服务端即被压测的应用服务器、数据库服务器内部的资源消耗情况它是“看不见”的。一个接口响应变慢可能是因为应用代码有性能问题也可能是因为数据库CPU跑满了或者磁盘IO被打爆。如果不监控服务器资源我们很难精准定位问题的根因。PerfMon插件就是为了填补这个关键空白而生的。它不是一个独立工具而是一个需要安装在JMeter上的第三方插件。它的核心作用是在JMeter执行压测脚本的同时通过一个轻量的代理称为PerfMon Server Agent部署在被监控的服务器上实时收集该服务器的CPU使用率、内存使用量、磁盘I/O、网络流量等数十种性能指标并将这些数据实时回传到JMeter的监听器中与我们的TPS、响应时间等业务指标在同一个时间轴上对齐展示。简单来说PerfMon让JMeter拥有了“透视”服务器内部状态的能力。它的价值在于精准定位瓶颈当响应时间飙升时可以立刻查看对应时间点的服务器CPU、内存是否也同步飙升从而快速判断是应用层问题还是基础设施资源问题。评估容量与规划通过监控资源使用率与业务压力的关系可以科学评估当前系统的承载能力为服务器扩容或架构优化提供数据支撑。验证优化效果代码优化或配置调整后再次压测。如果响应时间降低了同时服务器CPU使用率也显著下降那这就是一个有力的优化证据。一体化分析所有数据业务指标和系统指标集中在JMeter一个工具里无需在多个监控工具间来回切换对比时间戳分析效率大幅提升。这个插件对于任何需要进行严肃性能测试、容量规划或故障诊断的测试工程师、开发人员和运维人员来说都是工具箱里的必备利器。接下来我会手把手带你完成从插件下载、安装、配置到实战监控的全过程并分享我踩过的那些坑和总结出来的最佳实践。2. 环境准备与插件安装详解在开始安装PerfMon之前我们必须确保基础环境是正确且一致的。很多安装失败的问题根源都出在环境上。2.1 基础环境确认首先明确我们的工作场景涉及两类机器控制机/压测机运行JMeter GUI或非GUI命令行模式的机器。这台机器需要安装JMeter和PerfMon插件。被监控服务器运行我们被测应用的服务端如Tomcat、Nginx、MySQL所在的服务器。这台机器需要安装PerfMon的Server Agent。关键检查点Java版本JMeter和Server Agent都是Java应用因此两端都必须安装Java运行环境JRE或开发工具包JDK。我强烈推荐使用JDK 8或JDK 11的LTS版本这是经过广泛验证最稳定的。可以通过命令行java -version来确认。避免使用过新或过旧的版本以免出现兼容性问题。网络连通性这是最容易出问题的地方。控制机必须能通过网络访问到被监控服务器的指定端口默认是4444。你需要确保防火墙包括云服务商的安全组已经放行了这个端口的入站流量。一个简单的测试方法是在控制机上使用telnet [服务器IP] 4444命令如果没安装telnet也可以用nc -zv [服务器IP] 4444看看端口是否能通。JMeter版本建议使用相对较新且稳定的版本如 JMeter 5.4, 5.5 或 5.6。太老的版本如3.x可能对插件支持不完善。去Apache官网下载二进制包即可。2.2 插件安装的两种方式与避坑指南PerfMon插件主要由两部分构成JMeter端的监听器插件一个Jar包和服务器端的Agent一个可执行Jar包。我们首先安装JMeter端的部分。方式一使用JMeter Plugins Manager推荐给新手和追求便捷的用户这是最省心的方法。JMeter Plugins Manager是一个插件管理器可以自动处理依赖和安装。下载Plugins Manager访问https://jmeter-plugins.org/wiki/PluginsManager/下载名为jmeter-plugins-manager-xxx.jar的文件。安装Manager将这个jar文件复制到你的JMeter安装目录下的lib/ext文件夹中。启动JMeter以GUI模式启动JMeter双击bin/jmeter.bat或jmeter。使用Manager安装PerfMon在JMeter的菜单栏依次点击Options-Plugins Manager。在弹出的窗口中切换到Available Plugins标签页。搜索与安装在右上角的搜索框输入“PerfMon”。你会看到一系列插件找到PerfMon并勾选它。同时我强烈建议你一并勾选它旁边的Custom Thread Groups和3 Basic Graphs这些都是做性能测试非常实用的插件。然后点击右下角的Apply Changes and Restart JMeter。JMeter会自动下载、安装并重启。注意这种方式虽然方便但有时会因为网络问题访问https://repo1.maven.org导致下载失败。如果遇到这种情况不要慌我们还有手动安装这个“万能方法”。方式二手动下载安装推荐给所有需要稳定可控环境的用户手动安装能让你完全掌控文件来源和版本是我个人更偏爱的方式尤其是在内网或网络不稳定的环境中。前往官方下载页访问JMeter插件的官方站点https://jmeter-plugins.org/wiki/PerfMon/。下载Server Agent在页面中找到ServerAgent-2.2.3.zip版本号可能更新以最新稳定版为准的下载链接并下载。这个zip包包含了服务器端需要的所有文件。下载客户端插件在同一个页面找到JMeterPlugins-Standard和JMeterPlugins-Extras这两个包的下载链接。通常PerfMon监听器在Standard包中。下载这两个jar文件如JMeterPlugins-Standard-1.4.0.zip。安装客户端插件解压你下载的JMeterPlugins-Standard-xxx.zip文件。将其lib/ext文件夹下的JMeterPlugins-Standard.jar和JMeterPlugins-Extras.jar如果你也下载了Extras包复制到你JMeter安装目录的lib/ext文件夹下。关键步骤同时将解压后lib文件夹下的所有.jar文件注意是lib目录不是lib/ext也复制到JMeter安装目录的lib文件夹下。这一步很多教程会遗漏导致插件无法正常工作或缺少图表渲染库。验证安装重启JMeter。在监听器Listeners的右键菜单中你应该能看到新增的选项其中包含jpgc - PerfMon Metrics Collector。如果能看到说明客户端插件安装成功。实操心得无论用哪种方式安装完成后一定要重启JMeter。手动安装时务必检查JMeter启动日志控制台窗口看是否有关于加载插件的错误信息。常见的错误是缺少依赖包按照上述步骤复制lib下的jar通常能解决。建议将下载好的插件包尤其是Server Agent归档保存方便后续在其他项目或环境中快速部署。3. 服务器端Agent部署与配置实战服务器端Agent的部署是整个过程的核心也是问题的高发区。它的原理很简单在被监控服务器上运行一个轻量的Java程序Server Agent它启动一个Socket服务默认端口4444等待JMeter客户端连接。当连接建立后Agent会按需收集本机的性能数据并发送给JMeter。3.1 Agent部署步骤传输文件将之前下载的ServerAgent-2.2.3.zip上传到你需要监控的Linux服务器上例如使用scp命令scp ServerAgent-2.2.3.zip useryour_server_ip:/tmp/。解压与准备通过SSH登录服务器进入文件所在目录并解压。cd /tmp unzip ServerAgent-2.2.3.zip -d /opt/ # 解压到/opt目录你也可以选择其他目录 cd /opt/ServerAgent-2.2.3解压后你会看到目录下有几个关键文件startAgent.shLinux启动脚本、startAgent.batWindows启动脚本、stopAgent.sh和LICENSE、README等。检查Java环境在服务器上执行java -version确保Java已安装且版本合适。启动Agent执行启动脚本。# 使用默认端口4444启动 ./startAgent.sh # 如果你想指定其他端口例如9999可以这样启动 ./startAgent.sh --udp-port 0 --tcp-port 9999--udp-port 0表示禁用UDP我们通常用TCP就够了--tcp-port指定TCP端口。验证启动如果启动成功你会看到类似下面的输出INFO 2023-10-27 10:00:00.000 [org.jmeterplugins.protocol.http.control.HttpServerControl] (): HTTP Sampler Server started on port: 8080 (此端口非必须可忽略) INFO 2023-10-27 10:00:00.100 [kg.apc.p] (): Binding UDP to 4444 INFO 2023-10-27 10:00:00.101 [kg.apc.p] (): Binding TCP to 4444 INFO 2023-10-27 10:00:00.102 [kg.apc.p] (): JPGC Server Agent started最重要的是最后一行表明Agent已成功启动并在监听端口。3.2 高级配置与权限问题处理默认配置能满足大部分监控需求CPU、内存、磁盘。但有时我们需要监控更多指标或者遇到权限问题。监控更多指标Server Agent通过调用操作系统命令或读取/proc文件系统来获取数据。对于Linux它依赖sarsysstat包、iostat、vmstat等命令。因此确保这些命令已安装在服务器上# 对于CentOS/RHEL yum install sysstat -y # 对于Ubuntu/Debian apt-get install sysstat -y安装后Agent就能提供更丰富的磁盘I/O、网络等数据。权限问题这是最常见的坑。Server Agent默认以启动它的用户权限运行。如果这个用户权限不足可能无法读取某些系统信息比如所有进程的CPU信息需要root权限导致JMeter端收到“No metric data”的错误。解决方案方案A不推荐生产环境直接使用root用户启动Agent。这最简单但违背了最小权限原则有安全风险。sudo ./startAgent.sh方案B推荐为Agent创建一个专用系统用户并赋予其执行特定系统命令的sudo权限而无需密码。创建用户sudo useradd -r -s /bin/false jmeter-agent将ServerAgent目录的所有者改为该用户sudo chown -R jmeter-agent:jmeter-agent /opt/ServerAgent-2.2.3/配置sudoers允许该用户无密码执行必要的命令。编辑/etc/sudoers使用visudo命令jmeter-agent ALL(ALL) NOPASSWD: /usr/bin/mpstat, /usr/bin/iostat, /usr/bin/vmstat, /usr/bin/netstat, /usr/bin/sar这里列出了可能需要的命令请根据你的服务器实际命令路径调整。修改Agent启动脚本让它以sudo方式运行这些命令。这需要修改startAgent.sh脚本中调用命令的部分比较复杂。更常见的做法是如果只是监控CPU、内存、磁盘空间普通用户权限通常足够。如果需要详细的磁盘IOiostat和网络数据才考虑此方案。方案C折中如果监控需求不复杂可以尝试使用sudo启动但限制其能力。或者接受普通用户权限下部分指标如各进程详细CPU不可用的事实。对于大多数性能测试场景监控系统整体的CPU、内存、磁盘空间和IO等待普通用户权限获取的数据已经非常有价值。后台运行与停止测试时我们通常在前台启动以便查看日志。在生产性压测中你需要让Agent在后台运行nohup ./startAgent.sh agent.log 21 停止Agent可以使用自带的脚本./stopAgent.sh或者找到进程ID用kill命令。4. JMeter端配置与监控指标解读服务器端Agent就绪后我们回到JMeter配置监听器来连接Agent并收集数据。4.1 配置PerfMon Metrics Collector添加监听器在你的测试计划或线程组上右键选择Add-Listener-jpgc - PerfMon Metrics Collector。配置服务器指标这是核心配置界面。点击“Add Row”按钮新增一行监控配置。Server IP or DNS name填写被监控服务器的IP地址或主机名。Port填写Agent启动时指定的端口默认是4444。Metric to collect点击下拉框选择你要监控的指标。这是关键CPU选择CPU。注意这里获取的通常是系统整体CPU使用率。如果你想监控某个特定进程如Java进程需要选择Process CPU并指定进程ID或名称但这通常需要更高权限。Memory选择Memory。这里监控的是物理内存的使用情况包括used, free, cached, buffered等。对于JVM应用你更需要关注的是JVM堆内存这个指标需要通过JMX或其他JVM监控工具来获取PerfMon的Memory指标是系统级的。Disks I/O选择Disks I/O。这里可以监控磁盘的读写速率KB/s和IO等待时间。你需要在下方的Parameter输入框中指定磁盘设备例如sda或vda。你可以通过iostat -x 1命令查看服务器上的磁盘设备名。Network I/O选择Network I/O。监控指定网卡如eth0的进出流量bytes/s。同样需要在Parameter中指定网卡名。Metric parameter如上所述对于磁盘、网络等指标需要在此指定具体的设备名。Interval (seconds)数据采集间隔默认1秒。对于长时间压测如1小时以上可以适当调大如5秒以减少数据量和JMeter自身开销。对于短时高压场景保持1秒以获得更精细的视图。配置图表与文件Save Data to File强烈建议勾选并指定一个.jtl或.csv文件路径。这样可以将原始的监控数据保存下来即使关闭JMeter GUI数据也不会丢失后续可以用其他工具如Grafana进行更深入的分析。图表设置你可以设置图表的标题、Y轴标签、线条颜色等让图表更易读。4.2 关键指标解读与健康基线光收集数据不行还得会看。下面是一些核心指标的解读和基本的健康基线参考注意基线因应用和硬件而异以下仅为通用经验指标正常范围通用参考警戒线可能的问题CPU使用率平均 70% 80% 持续应用计算密集型操作过多存在死循环线程阻塞需要升级CPU或优化代码。内存使用率有一定余量如20% 90% 持续内存泄漏应用配置内存不足系统缓存占用过多Linux下需看可用内存available而非free。磁盘IO使用率平均 70% 90% 持续大量日志写入数据库频繁刷盘磁盘性能成为瓶颈。需结合awaitIO等待时间看如果await很高如50ms即使使用率不高也说明磁盘慢。网络IO低于网卡带宽的80%接近带宽上限网络成为瓶颈。需检查是否有大量数据传输或网络攻击。实操心得看趋势比看单点更重要。在压测过程中重点观察这些指标随着并发用户数TPS增加而变化的趋势。理想情况TPS线性增长CPU、内存、IO等资源使用率也平稳上升且最终稳定在一个安全水位以下。典型瓶颈CPU瓶颈TPS上不去CPU使用率却先打到100%。这时响应时间会急剧上升。你需要分析是哪个进程吃掉了CPU可以用top命令进一步排查。内存瓶颈TPS上不去或下降内存使用率持续走高直至接近100%可能伴随大量Swap使用系统变得极其缓慢。IO瓶颈TPS上不去磁盘IO使用率或await时间非常高CPU可能因等待IO而空闲%iowait高。PerfMon图表的美妙之处在于你可以把响应时间曲线和CPU使用率曲线放在一起看。如果两条曲线的波峰波谷高度重合那基本可以断定性能问题是由服务器资源不足导致的。5. 分布式压测与多服务器监控真实的系统往往是分布式的应用服务器、数据库服务器、缓存服务器可能部署在不同的机器上。我们需要同时监控所有这些节点。5.1 监控多台服务器在PerfMon Metrics Collector中这非常简单。你只需要点击多次Add Row按钮为每一台需要监控的服务器添加一条配置即可指定各自的IP、端口和需要收集的指标。例如行1: IP:192.168.1.101, Port:4444, Metric:CPU(应用服务器1)行2: IP:192.168.1.101, Port:4444, Metric:Memory(应用服务器1)行3: IP:192.168.1.102, Port:4444, Metric:CPU(应用服务器2)行4: IP:192.168.1.103, Port:4444, Metric:CPU(数据库服务器)行5: IP:192.168.1.103, Port:4444, Metric:Disks I/O, Parameter:sda这样在一个图表中你就可以同时看到多台服务器的关键指标便于对比分析。比如当TPS下降时你可以一眼看出是应用服务器CPU满了还是数据库磁盘IO爆了。5.2 与JMeter分布式压测结合JMeter支持分布式压测即由一台控制机Master指挥多台压力机Slave同时发起请求。在这种情况下监控配置需要注意Agent部署你需要在每一台被监控的服务器包括所有压力机Slave如果也想监控压力机本身资源的话上部署并启动Server Agent。监听器位置PerfMon Metrics Collector监听器应该添加在控制机Master的测试计划中。因为所有测试结果和监控数据最终都会汇聚到控制机进行汇总和展示。配置连接在控制机的监听器配置中添加所有需要监控的服务器IP包括应用服务器、数据库服务器甚至压力机就像上一节那样。网络考虑确保控制机能访问所有被监控服务器的Agent端口。在分布式环境中网络拓扑可能更复杂需要提前打通防火墙规则。这样当你启动分布式压测时控制机上的PerfMon监听器会同时向所有这些服务器的Agent发起连接收集全局的资源视图让你能全面把握在分布式压力下整个系统各个组件的资源消耗情况。6. 常见问题排查与实战技巧即使按照步骤操作你也可能会遇到一些问题。这里我总结了一份常见问题速查表基本覆盖了我遇到过的所有坑。问题现象可能原因排查步骤与解决方案JMeter连接Agent失败提示“Connection refused”或超时1. Agent未启动。2. 防火墙/安全组阻止了端口。3. IP或端口号填写错误。4. 服务器上存在多个Java实例Agent使用了错误版本。1. 登录服务器检查Agent进程是否存在 (ps -efJMeter能连接但收不到数据图表为空或显示“No metric data”1. Agent权限不足无法执行监控命令。2. 服务器缺少必要的监控工具如sar,iostat。3. 选择的指标在该操作系统上不支持。1. 查看Agent启动日志和运行日志是否有权限错误。2. 尝试用sudo启动Agent测试是否是权限问题。3. 在服务器上手动执行sar 1 3,iostat -x 1 3等命令看是否能正常输出。4. 对于Linux优先使用CPU、Memory、Disks I/O这些通用指标。Swap、Network I/O等可能需要额外配置。监控数据严重延迟或断断续续1. 网络延迟高或不稳定。2. 被监控服务器负载极高Agent本身响应慢。3. JMeter控制机资源不足CPU/内存处理不过来。4. 采集间隔太短数据量太大。1. 检查网络状况。2. 监控服务器资源看是否负载过高。3. 检查JMeter控制机的资源使用情况考虑在更强大的机器上运行JMeter GUI或者使用非GUI模式 (jmeter -n) 运行测试减轻GUI渲染开销。4. 适当调大PerfMon监听器的采集间隔如从1秒改为5秒。PerfMon图表导致JMeter GUI非常卡顿1. 监控的服务器和指标过多。2. 压测时间很长图表渲染数据点太多。3. JMeter运行机器的图形性能不足。1.最佳实践不要在GUI模式下进行长时间压测。使用非GUI模式运行测试 (jmeter -n -t test.jmx -l result.jtl)并将PerfMon数据也保存到文件 (-J参数或监听器配置中指定文件)。压测结束后用GUI打开结果文件离线分析图表。2. 在监听器中设置“Rows limit”限制图表显示的数据点数量。3. 只添加真正关心的核心指标减少图表渲染负担。Windows服务器监控不到磁盘IO等指标PerfMon Server Agent对Windows的支持有限部分指标可能无法获取或名称不同。1. 确保使用最新版本的Server Agent。2. 对于磁盘IO在Windows上尝试使用PhysicalDisk相关的指标参数具体参数名可能需要参考Agent的文档或源码。3. 考虑对Windows服务器使用其自带的性能计数器Performance Counter并通过其他方式如编写脚本将数据集成进来或者使用更专业的Windows服务器监控工具。独家避坑技巧先测试后压测在正式压测前先单独配置好PerfMon监听器启动一个只有1个用户、循环1-2次的线程组点击运行。看看图表是否能正常出数据连接是否稳定。这个简单的冒烟测试能提前发现90%的配置问题。善用“Save Data to File”无论GUI多卡一定要把原始数据保存为CSV文件。这个文件是“金矿”里面是按时间戳排列的所有指标原始值。你可以用Excel、Python Pandas或导入到GrafanaInfluxDB中进行更灵活、更美观的二次分析。组合监听器不要只依赖PerfMon。将jpgc - Transactions per SecondTPS监听器、jpgc - Response Times Over Time响应时间监听器和PerfMon Metrics Collector放在同一个“View Results Tree”或“Simple Data Writer”的兄弟位置。然后使用JMeter的“Merge Results”功能在“Tools”菜单可以将业务指标和系统指标合并分析效果极佳。Agent启动参数startAgent.sh支持一些有用参数比如--auto-shutdown可以在指定时间后自动关闭--loglevel可以调整日志级别debug, info, error。对于生产环境使用--loglevel error --sysinfo可以减少日志输出并通过--sysinfo在启动时打印一次系统信息用于确认。监控压力机自身别忘了在PerfMon中添加对你JMeter压力机Slave本身的监控。有时候性能上不去不是服务器的问题而是压力机先达到了资源上限比如网络带宽打满、CPU处理不过来生成的请求这能帮你准确区分是施压方还是受压方的问题。最后我想说的是PerfMon插件是连接“压力现象”和“系统根因”的桥梁。它提供的数据是客观的但如何解读这些数据将其与业务逻辑、代码实现、架构设计关联起来才是性能测试工程师真正的价值所在。多实践多对比建立你自己对系统的性能基线认知你会发现自己对系统性能的理解会上一个全新的台阶。

相关新闻