虚拟机搭建JMeter集群最核心的配置问题是网络互通、JVM堆内存与并发线程的匹配、以及RMI通信参数的正确设置，这三项缺一不可，否则压测数据会严重失真。很多人在单机跑JMeter没问题，一到虚拟机集群就出现各种奇怪报错，根因基本都藏在配置文件里，下面按实际部署顺序，把容易踩的坑逐个拆开。
虚拟机搭建jmeter集群配置问题：网络互通永远是第一步
虚拟机环境不像物理机,网络往往经过了虚拟交换机、安全组、防火墙多层过滤，JMeter集群用RMI（Java远程方法调用）通信，默认端口动态分配，这在虚拟机里是最大的坑。
- 安全组和防火墙必须放行JMeter使用的端口,Master默认连Slave的
server_port，通常设为1099，但RMI还会随机开一个本地端口用于数据传输，如果不固定，安全组没法提前配置。 - 在
jmeter.properties里把Slave的RMI本地端口固定下来，例如设置server.rmi.localport=50000，然后在云服务器安全组中同时放行1099和50000这两个端口。 - 关闭RMI SSL，新版JMeter默认开启
server.rmi.ssl.disable=false，虚拟机集群里证书配置复杂，多数情况下直接设为true更稳妥，否则会报Connection refused to host或握手失败。 - 每台虚拟机都要配置正确的
hostname或IP，如果Slave有多块网卡，启动时必须指定-Djava.rmi.server.hostname=内网IP，否则Master可能连到错误的虚拟网卡地址。
实际启动Slave的命令行：
./jmeter-server -Djava.rmi.server.hostname=192.168.1.10Windows虚拟机用jmeter-server.bat，Linux用./jmeter-server，跑起来以后，可以在Master的bin目录下用telnet SlaveIP 1099验证端口通不通，如果telnet不通，先检查虚拟机安全组和系统防火墙，再检查Slave进程是否真的监听在指定端口上。
jmeter集群压测虚拟机配置对比：CPU内存磁盘怎么选
做JMeter集群压测,虚拟机的规格选择经常被低估，有人拿2核4G的虚拟机跑5000并发，结果压测机自己先崩了，所以这里专门做一个配置对比。
| 配置项 | 低配坑点 | 推荐做法 |
|---|---|---|
| CPU核数 | 线程数一旦超过CPU核数很多，上下文切换频繁，吞吐量上不去，误差大 | 单台Slave的并发线程数控制在CPU核数的2到4倍以内，压测机CPU使用率别超过85% |
| 内存 | JMeter每个线程默认消耗约1MB堆内存，加监听器和结果收集后消耗更大，堆内存不足会频繁Full GC | 给每台Slave分配至少4G到8G堆内存，并通过HEAP参数调整 |
| 磁盘类型 | 结果文件持续写入，机械硬盘IOPS低会拖慢统计，影响压测节奏 | 使用SSD云盘，结果文件按场景拆分，不要用单个超大jtl |
| 网络带宽 | 虚拟机带宽通常是共享的，如果压测目标外网服务，带宽瓶颈会直接限制吞吐量 | 压测机与目标系统尽量同地域同可用区，内网压测 |
调整JVM堆内存的操作路径：找到JMeter安装目录的bin/jmeter或jmeter.bat，修改HEAP参数，
HEAP="-Xms2g -Xmx2g -XX:MaxMetaspaceSize=256m"改完重启JMeter进程生效,建议Slave上不要同时跑其他业务，避免资源争抢，尤其要注意-Xms和-Xmx设为相同值，防止堆内存动态扩展带来的性能抖动。
jmeter分布式压测配置注意事项：Master与Slave参数一致性
JMeter集群里,Master负责调度和汇总，Slave负责执行，真正压测时，脚本文件和参数必须高度一致，否则多台机器发出的请求都不一样，结果没法看。
- 脚本路径要一致，Master上保存的
.jmx文件路径和Slave上的路径必须相同，业内专家指出，很多分布式压测失败就是因为Slave找不到CSV数据文件或用户自定义变量文件，建议把所有依赖文件放到相同的绝对路径，比如/data/jmeter/。 - CSV参数文件要分片或复制，如果测试计划里用了CSV Data Set Config，每台Slave会独立读取同一份文件，为了模拟不同用户，可以给每台Slave准备不同的CSV分片，或者在脚本里用线程号做参数拆分。
- 监听器尽量精简，集群模式下，Master汇总所有Slave的结果，如果脚本里挂了一堆图形监听器，会消耗大量内存和网络，命令行压测时用
-l输出jtl文件即可，图形界面只做调试。 - 版本必须对齐，所有虚拟机的JMeter版本、JDK版本最好完全一致，小版本差异可能造成RMI序列化不兼容，行业共识认为，使用相同大版本和相同小版本是最稳妥的选择，不要混用JMeter 5.5和5.6。
启动分布式压测的命令行示例：
jmeter -n -t /data/jmeter/test.jmx -R 192.168.1.10,192.168.1.11 -l /data/result/result.jtl-R后面跟所有Slave的IP，用逗号隔开，也可以提前在jmeter.properties里配好remote_hosts，然后用-r一键启动所有远程机器，需要特别注意，每台Slave上使用的第三方插件必须一致，比如自定义采样器、函数扩展，否则Master汇总结果时可能报类找不到的异常。
虚拟机运行jmeter集群性能调优实操步骤
调优不是玄学,按下面这几步操作，基本能覆盖90%的场景。
-
固定RMI端口，关闭SSL，在Slave的
jmeter.properties里设置：server.rmi.localport=50000 server.rmi.ssl.disable=true同时在Master的
jmeter.properties里设置同样的server.rmi.ssl.disable=true，否则两边握手协议不一致。 -
调整JVM堆内存，在
bin/jmeter文件中，根据虚拟机内存设置-Xms和-Xmx，不要超过物理内存的80%，给操作系统留够空间。 -
使用非GUI模式运行，GUI模式只用于调试，真实压测务必用命令行，GUI会消耗大量CPU和内存，集群环境下尤其明显。
-
关闭不必要的监听器，聚合报告、查看结果树这类监听器在压测时别挂，只在测试完成后用命令行工具生成报告，
jmeter -g /data/result/result.jtl -o /data/report -
合理设置线程组启动策略，如果5000并发直接用Ramp-up 1秒拉起，压测机和目标服务都可能瞬时过载，建议分阶段加压，例如Ramp-up设置为300秒，让曲线平滑。
-
监控虚拟机自身指标，压测过程中用
top、vmstat或云监控查看CPU、内存、磁盘IO，如果Slave的CPU持续打满，先减线程数或加Slave数量，不要盲目放大线程。
虚拟机搭建jmeter集群的成本评估：jmeter集群需要几台虚拟机
很多刚接触分布式压测的人会问“jmeter集群需要几台虚拟机”，这个没有固定答案，但可以按并发量和单机能力估算。
- 单台Slave能跑多少并发：跟CPU核数、内存强相关，通常4核8G的虚拟机，跑1000到2000并发HTTP请求是可行的，具体取决于脚本复杂度和响应时间。
- 需要几台Slave：先测出单台Slave的极限吞吐量，再用目标并发除以单机能力，向上取整，一般在虚拟机环境，小规模压测用1个Master加2到3个Slave就能满足多数场景。
- 地域选择：如果压测目标是云上服务，建议把压测虚拟机放在同一地域同一可用区，走内网IP通信，跨地域压测会把公网波动混入结果，测出来的响应时间没有参考价值。
- 成本控制：虚拟机按量计费，压测前临时创建，压测完释放，比包月划算，国内主流云厂商的竞价实例或抢占式实例可以进一步降低成本，但需要接受实例被回收的风险。
一个典型的低成本方案是：Master用一台2核4G的竞价实例，Slave用三台4核8G的按量实例，整体压测时长控制在两小时内，成本可控制在较低水平，压测结束后释放全部资源，只保留脚本和结果文件。
虚拟机环境搭JMeter集群,配置重点永远是网络、JVM、参数一致性，把这三块理顺，大部分诡异报错都会消失，压测结果准不准，先看压测机自己稳不稳。
虚拟机搭建jmeter集群配置问题Q&A
虚拟机搭建jmeter集群时Slave启动报错Connection refused怎么解决？
多半是RMI端口没有固定或安全组没放行,先在Slave上确认server.rmi.localport已设置，再检查防火墙是否放行1099和该本地端口，关闭SSL后重启jmeter-server，用telnet验证端口连通性，多数情况下，把server.rmi.ssl.disable=true和server.rmi.localport=50000同时配置后问题就消失。
jmeter集群压测虚拟机配置对比：内网IP和公网IP用哪个？
压测机和目标系统在同一地域时,优先用内网IP，内网带宽大且延迟低，公网IP会经过NAT转换，RMI通信容易出问题，启动Slave时通过-Djava.rmi.server.hostname=内网IP显式指定，Master的remote_hosts也填内网地址。
jmeter分布式压测配置注意事项里，Master要不要也当Slave用？
不建议让Master同时执行压测任务,Master负责调度和结果汇总，本身资源消耗不小，如果也当Slave，会引入额外负载，导致统计结果偏慢，生产级压测中，Master单独一台，Slave独立若干台，分工明确，事实证明，这种架构在多数云压测平台中也是默认做法。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/669468.html
