负载测试中下降三角型延迟尖峰模式的根因排查

问题现象 #

定位应用最大百分位延迟异常模式过程中，观测到稳定复现的特殊延迟形态，首次观测结果来自4分钟Gatling负载测试：前2分钟为同场景预热阶段，未绘制延迟曲线，测量阶段结果如下：

测试中可稳定观测到2个（部分场景下数量更多）斜率几乎一致的三角型尖峰，多次重复测试均可复现，且尖峰形态与负载均衡后端部署的应用实例数量无关，不同实例数下的观测结果如下：

该尖峰模式无公开匹配案例，具备两个核心特征：

• 三角形态并非由连续延迟值填充，仅由离散尖点构成
• 形态呈倒置特征：恒定负载下若为负载抬升导致延迟上涨，预期三角斜率应与观测结果相反，现有斜率的形成逻辑暂无法通过常规负载-延迟模型解释

应用侧开展请求延迟优化前，观测到的尖峰形态如下：

测试环境基线信息 #

• 被测对象为部署在AWS上的Spring Boot应用，后端依赖PostgreSQL数据库
• Kubernetes集群部署6个应用Pod，测试期间已禁用自动扩缩容
• 初始排查阶段误判Gatling测试启用了Keep-alive，后续已确认该判断不成立
• Kubernetes Ingress使用默认配置，按默认规则会与各上游服务维持Keep-alive连接
• 测试期间数据库负载、单Pod CPU使用率均未达到性能上限
• 压测机网络上行带宽未跑满，压测期间仅运行压测任务，无其他额外负载
• 预热结束进入测量阶段后，应用每秒请求数基本恒定，无负载波动
• JVM垃圾回收活动处于较低水平，无明显长停顿

高优先级排查方向 #

按验证成本从低到高排序：

• 连接生命周期配置对齐核查
  这类固定周期、斜率一致的离散倒置三角尖峰，是典型的连接批量过期重建特征。逐层核对全链路TCP连接相关超时配置，重点覆盖四个环节：Gatling客户端连接配置、K8s Ingress Keep-alive超时配置、Spring Boot内置Web容器连接超时配置、PostgreSQL连接池maxLifetime/空闲超时配置。
  核查逻辑：如果某一层的空闲连接超时配置短于上下游配置，会出现固定周期的连接批量断开，后续请求触发新连接建立时，TCP握手、TLS握手的额外开销会落在离散请求上形成高延迟尖点；随着过期连接逐步完成重建，尖点的最高延迟逐次下降，刚好匹配观测到的倒置三角斜率。验证时可临时将全链路Keep-alive超时统一调至300s以上，观察尖峰间隔是否同步拉长，即可快速确认是否为该类问题。
• 网络层指标交叉验证
  在尖峰出现的时间窗口，同步在压测机、Ingress节点、应用Pod、数据库节点抓包，统计是否存在集中的TCP重传、SYN重传、RST重置包；同时核对节点内核参数中tcp_tw_recycle、tcp_tw_reuse配置，排除TIME_WAIT堆积导致的临时连接失败；另外核查K8s节点conntrack表统计，确认尖峰时段是否存在conntrack表项批量过期丢包的情况。
• 周期性后台任务排查
  虽然已确认GC处于低水平，但仍需核对全链路周期性任务的执行间隔是否与尖峰间隔匹配：包括Spring Boot内置定时任务、K8s节点上的日志/监控采集任务、AWS侧ENI网卡元数据刷新周期、EBS存储IO限流/快照周期、PostgreSQL自动checkpoint周期，这类后台任务如果抢占CPU/IO资源，会导致固定间隔的请求排队，形成离散延迟尖峰。
• 负载均衡调度逻辑验证
  虽然尖峰形态与后端实例数无关，仍需核对Ingress的上游连接调度逻辑，确认是否存在固定批次新建连接的调度规则，排除调度策略导致的周期性建连开销。

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