Ubuntu 上提升 JMeter 吞吐与稳定性的实用优化清单
一 运行环境与 JVM 设置
- 使用最新稳定版 JMeter 5.x 与受支持的 Java 8/11/17，避免已知内存与协议栈问题。
- 以非 GUI 模式运行：执行命令形如：jmeter -n -t your.jmx -l result.jtl -e -o report，显著降低资源占用。
- 调整堆内存与 GC：编辑 bin/jmeter 启动脚本中的 HEAP，例如 HEAP=“-Xms4g -Xmx4g -XX:+UseG1GC”（建议 -Xms 与 -Xmx 一致 减少堆伸缩抖动；堆上限一般不超过物理内存的 80%）。
- 如仍出现 OOM，检查是否开启了响应体保存、线程数过大或数据写入过频等“内存大户”。
二 JMeter 配置与脚本减负
- 精简监听器：压测时移除或禁用 View Results Tree 等高开销组件；使用 Aggregate Report / Summary Report / Simple Data Writer 输出关键指标与 CSV 结果。
- 结果文件优化：将结果保存为 CSV（字段可按需裁剪），错误详情可单独用 XML 保存便于排查；控制台摘要频率可调小（如 summariser.interval=10）。
- HTTP 取样器关键项：
- 实现选择 HttpClient4；开启 Keep-Alive；
- 超时：Connect Timeout 5000 ms、Response Timeout 按业务设置（如 10000 ms）；
- 连接池与重试：httpclient4.time_to_live=60000（连接最大存活时间，按需），httpclient4.retrycount=1（减少失败重试对结果的干扰）；
- 仅在需要模拟浏览器时勾选 Retrieve All Embedded Resources（会增加大量子请求）。
- 结果字段裁剪：仅保存必要字段（如响应时间、状态码等），避免 jmeter.save.saveservice.response_data 等带来高 I/O 与内存压力。
三 线程模型与系统资源匹配
- 避免一次性拉起过多线程（例如 5 万线程/1 秒 ramp-up 极易触发 OOM 与调度抖动），采用阶梯加压（如 Stepping Thread Group）逐步观察拐点。
- 并发能力由多因素共同决定：客户端 CPU/网络栈、被测系统能力、协议与思考时间等；在 8 核 16G 这类通用云主机上，需以实际脚本与网络为基准逐步加压，不要盲设超高线程。
- 若单机已达瓶颈，优先通过多机分布式压测横向扩展；在 jmeter.properties 中配置 remote_hosts，各 Slave 节点设置 RMI 与网卡 IP，Master 使用 -R 指定远程节点执行。
四 Linux 系统层面优化
- 网络与文件描述符：适度提升 ulimit -n（如 65535），并检查 net.core.somaxconn / netdev_budget 等内核参数，减少连接排队与丢包。
- 运行环境：压测机尽量专机专用，关闭不必要的桌面/服务；如使用云盘，优先 更高 IOPS 的存储以承载结果写入。
- 监控与诊断：压测期间用 top/vmstat/pidstat 观察 CPU、内存、I/O 与网络；必要时用 JConsole 连到 JMeter 进程验证堆与 GC 配置是否生效。
五 快速检查清单与常用命令
- 快速检查清单
- 运行模式：非 GUI；HEAP 已按机器内存调优且 Xms=Xmx；启用 G1GC；
- 监听器：仅保留必要组件；结果输出为 CSV；
- HTTP：HttpClient4、Keep-Alive、合理超时、连接池 TTL 与重试次数已设置；
- 线程：避免一次性超高线程，采用阶梯加压；单机瓶颈则准备分布式。
- 常用命令
- 非 GUI 执行并写 JTL：jmeter -n -t script.jmx -l result.jtl
- 生成 HTML 报告：jmeter -g result.jtl -e -o ./report
- 分布式执行：在 Master 的 jmeter.properties 设置 remote_hosts，启动各 Slave 的 jmeter-server，Master 执行：jmeter -n -t script.jmx -R slave1,slave2 -l result.jtl -e -o ./report
- 堆设置验证：jconsole 连接 ApacheJMeter.jar 进程，查看 -Xmx/-Xms/GC 参数是否生效。
