JMeter更换GC算法后耗时仍出现固定区间峰值的原因及优化问询

• 脚本内部对象累积/资源泄露：每次请求循环创建的大型对象（如完整响应缓存、自定义采样器中的未释放资源）累计到固定数量后，触发JMeter内部资源清理逻辑。峰值出现时可同步监控JMeter进程的非堆内存占用、打开句柄数、活跃线程数是否同步波动。
• 被压服务端的阈值触发逻辑：因峰值和累计请求数强相关，优先排查服务端逻辑：如配置了每3000条请求做一次批量日志落盘、本地缓存容量设置为3000条触发淘汰、连接池/数据库连接池耗尽触发等待、第三方依赖限流阈值触发。可将JMeter请求日志和服务端日志按时间戳对齐，确认峰值时服务端是否有对应打点。
• JMeter结果收集逻辑瓶颈：若开启了全量请求/响应数据持久化、多监听器同步收集数据，累计到固定数据量后会触发批量IO操作：如CSV结果文件缓冲区满刷盘、后端监听器批量上报阈值触发、内存中统计数据结构扩容。可先关闭所有非必要监听器，仅保留基础汇总统计，复测是否还存在峰值。
• 操作系统层面资源瓶颈：JMeter进程累计请求数达到阈值后，触发系统资源限制：如打开文件数接近上限、TCP连接TIME_WAIT堆积触发端口复用等待、压测机磁盘IO被日志写满、网络缓冲区满触发丢包重传。压测过程中同步监控系统CPU（区分用户态/内核态）、IO使用率、网络连接数、丢包率，和峰值时间点对齐排查。

• 脚本层面优化：关闭保存响应数据、保存请求/响应头的非必要配置，自定义代码逻辑中避免每次循环创建大对象，用完的资源主动置空释放，尽量复用对象实例。使用CSV数据集配置时，关闭每次迭代重新读取文件的冗余配置。
• JMeter配置优化：修改jmeter.properties中mode=Statistical仅收集统计数据，关闭jmeter.save.saveservice.*下所有非必要字段的持久化，调整结果刷盘缓冲区jmeter.save.saveservice.buffer_size=65536。压测全程使用非GUI模式，不要加载任何GUI相关组件。
• 服务端排查优化：若对齐日志确认峰值来自服务端耗时上涨，针对性调整服务端配置：扩容缓存容量、调整批量落盘阈值、扩容连接池、调整限流规则。
• 系统资源调优：将压测机的最大打开文件数调整至65535以上，开启TCP端口回收参数net.ipv4.tcp_tw_reuse=1、net.ipv4.tcp_tw_recycle=1，压测机和被压机尽量通过内网连接避免公网波动影响。

内容的提问来源于stack exchange，提问作者Rajasirpi