jmeter压力测试centos策略

JMeter 在 CentOS 的压测策略

一 环境与基础配置

• 安装与版本：在 CentOS 上先安装 JDK 1.8+，再部署 Apache JMeter 5.x（建议 5.4+）。设置环境变量（/etc/profile）以便命令行直接调用：JAVA_HOME、JMETER_HOME、PATH。完成后用 java -version 与 jmeter -v 验证。执行压测一律使用 非 GUI 模式，GUI 仅用于脚本编写与调试。为降低资源占用，压测时尽量少用或禁用 Listener（尤其是“查看结果树”“查看结果表”）。
• 执行与报告常用命令：
  • 本地非 GUI 执行：jmeter -n -t script.jmx -l result.jtl
  • 生成 HTML 报告：jmeter -n -t script.jmx -l result.jtl -e -o ./report（报告目录需为空）
  • 远程启动：jmeter -n -t script.jmx -R slave1:port,slave2:port -l result.jtl -e -o ./report
  • 注意：每次运行前确保 .jtl 结果文件与 -o 报告目录不存在或为空，否则会报错。

二 单机与分布式压测设计

• 单机策略：在单台 CentOS 压力机上，通过非 GUI 模式、精简 Listener、CSV 输出、合理定时器与线程爬坡（Ramp-Up）来稳定施压；如需更大并发，优先增加负载机数量而非一味拉高单机线程数。
• 分布式策略：
  • 架构建议：将 Master（调度机） 与 Slave（负载机） 分离，避免调度本身消耗影响吞吐；所有节点保持 JDK/JMeter/插件版本一致。
  • 关键配置：
    • jmeter.properties：设置 remote_hosts=slave_ip:port；如需固定 RMI 端口，设置 server_port；为简化防火墙策略，可设置 server.rmi.ssl.disable=true（测试环境）。
    • 负载机启动：在每台 Slave 上执行 jmeter-server。
    • 参数化文件：将 CSV 数据文件 同步到各 Slave 且路径一致；为避免数据重复，各 Slave 的数据切片应不同。
    • 执行方式：Master 使用 -R 指定 Slave 列表进行远程启动，或配置 remote_hosts 后使用 -r 一键启动全部。
  • 网络要求：确保 Master 与 Slave 之间的 RMI 端口与通信端口 已放通（或临时关闭防火墙用于联调）。

三 系统层面性能调优

• 资源与内核参数（示例值，按机器规格与业务调优）：
  • 文件句柄与连接：提高进程可打开文件数与内核网络参数，如 ulimit -n、somaxconn、tcp_tw_reuse 等，以支持更高并发连接。
  • 网络与 TCP：根据带宽与延迟调整 TCP 窗口、队列与超时参数（如 tcp_window_scaling、tcp_max_syn_backlog、tcp_fin_timeout 等），减少连接建立与回收开销。
  • 磁盘与 I/O：选择合适的 I/O 调度器（如 deadline/noop），并结合业务特性优化脏页刷新参数（如 vm.dirty_ratio、vm.dirty_background_ratio），降低 I/O 抖动。
  • 内存与调度：合理设置 Swap 与 swappiness（如 10），避免频繁换页；必要时用 nice/renice 调整压测进程优先级，避免被系统其他任务抢占。
• JMeter JVM 调优：
  • 堆大小：编辑 jmeter 或 jmeter.sh，将 HEAP 设置为不超过物理内存的 2/3；例如：-Xms4G -Xmx8G（具体依内存与场景而定）。
  • 运行方式：始终使用非 GUI 模式执行，减少额外内存与 CPU 开销。

四 监控 执行与报告闭环

• 目标先行：先做 单接口基准测试，明确目标 TPS、响应时间、错误率 与可接受的波动范围，再设计并发模型与持续时间。
• 监控体系：
  • 被测系统：在 CentOS 上使用 PerfMon 插件或系统工具（如 top、vmstat、iostat、sar、netstat）监控 CPU、内存、I/O、网络、连接数 等关键指标。
  • JMeter 实时可视化：部署 InfluxDB + Grafana，在 JMeter 中添加 Backend Listener（InfluxdbBackendListenerClient），将采样数据写入 InfluxDB，在 Grafana 实时查看 TPS、响应时间分布、活跃线程、错误率 等。
• 执行与稳定性：
  • 施压策略：采用 阶梯式加压（如每 5–10 分钟提升并发 25–50%）观察拐点；每个阶梯保持 10–15 分钟稳态，再进入下一阶梯。
  • 运行时配置：禁用或精简 Listener，使用 CSV 输出；如需“查看结果树”仅在脚本调试阶段启用。
  • 数据一致性：参数化文件在各 Slave 路径一致、数据不重复；分布式压测时避免 Master 参与发压。
• 报告与复盘：
  • 本地报告：使用 -e -o 生成 HTML 报告，便于归档与分享。
  • 数据清洗：若 .jtl 末尾存在不完整行导致报告生成失败，删除该行后重新生成报告。
  • 瓶颈定位：结合 Grafana/PerfMon 与业务日志，定位 应用线程池、数据库、缓存、外部依赖、网络链路 等瓶颈，按“调参—复测—对比”的闭环迭代优化。