为什么JMeter中设置的soak test未到预定时长就提前终止？

问题根因分析 #

报错an established connection was aborted by the software in your host machine本质是TCP连接被客户端或服务端的上层应用/操作系统主动断开，两种场景都有可能触发，可以按照下述方向逐一排查：

一、JMeter侧常见触发原因 #

JMeter本身没有压测时长的官方限制，你的线程组配置参数本身没有问题，大概率是下述配置缺陷导致：

• JVM堆内存溢出/GC停顿：如果压测时开启了View Result Tree全量存储所有请求响应数据，8-9小时累计的请求数据量很容易撑爆JMeter默认的JVM堆内存，JVM堆占满后会触发长时间GC甚至OOM，导致JMeter主动断开现有连接。
• HTTP采样器超时配置缺失：如果HTTP采样器未配置Connect Timeout和Response Timeout，且操作系统TCP keepalive参数不合理，闲置超过系统阈值的长连接会被客户端操作系统主动回收。
• CSV数据集配置不匹配：如果CSV数据集配置为「遇到文件结束符停止线程」，且没有开启无限循环，10000个用户凭证消费完成后线程会逐步退出，导致压测提前终止。

二、IIS侧容易被忽略的超时配置 #

常规IIS站点配置中不会展示部分底层长连接相关参数，很容易在排查时遗漏：

• 操作系统级TCP连接回收阈值：Windows Server默认的非活动TCP连接回收阈值通常为8小时，刚好匹配你报错的时间点，该参数不在IIS站点配置列表中，需要通过netsh命令或者系统注册表查看。
• 应用程序池回收策略：如果IIS应用程序池配置了固定时间间隔回收（例如8小时），或者配置了内存/CPU阈值触发回收，回收操作会主动断开所有现有客户端连接。
• 上层应用会话超时限制：如果被测接口配置了会话有效期，单用户会话超过8小时后被服务端强制下线，也会触发连接断开报错。

快速验证方案 #

1. 调整JMeter配置，禁用所有非必要监听器，仅保留聚合报告这类低资源消耗的监听器，将JVM堆内存调整为测试机物理内存的80%，重新启动压测观察是否还会在8小时左右中断。
2. 查看JMeter运行日志jmeter.log，确认中断时间点是否存在OOM、线程中断相关的报错记录。
3. 查看Windows系统事件查看器，确认报错时间点是否存在IIS应用程序池回收、重启的系统日志。

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