GCP环境下Nginx Ingress后Pekko HTTP特定Pod连接数过高问题排查

架构老林

2026-6-17

单个Pekko HTTP Pod连接数异常偏高的排查问题

问题描述

在特定GCP区域中，我们遇到了如下异常：

Kamon监控的http_server_connection_open_bucket指标显示某一Pod的连接数异常偏高（达1.73K，其他Pod仅约200）
架构链路为：客户端请求 → Nginx Ingress → 基于Pekko HTTP 1.0.0的后端服务
仅该Pod出现连接数持续增长，且同步伴随p99延迟上升、CPU及内存占用飙升
在Pod所在节点执行命令 netstat -natu | awk '{print $6}' | cut -d: -f1 | sort | uniq -c | sort -n 后，输出的连接数与其他节点相近，排除节点层面问题

当前使用的Pekko HTTP配置：

pekko.http {
  server {
    max-connections = 2048
    pipelining-limit = 16
    request-timeout = 1s
  }
}

我们希望明确：该问题仅发生在单个Pod的原因、排查方向，是否可能由GCP节点导致，或是应用内部问题？

请求处理阻塞/慢处理
- 对比该Pod与正常Pod的请求日志，检查是否有大量请求卡在业务逻辑中（如数据库查询超时、第三方API调用延迟过高）。Pekko HTTP基于事件循环模型，单个请求阻塞会占用线程，导致后续请求排队，连接无法及时释放。
- 确认是否有特定类型请求集中路由到该Pod（如大Payload请求、特定路由的请求），这类请求处理耗时更长，易堆积连接。
连接释放逻辑异常
- 检查代码中是否存在未正确关闭响应流的场景，比如complete方法未正常调用、流处理异常未终止连接，导致连接长期处于活跃状态。
- 验证request-timeout配置是否生效：查看日志中是否有请求超时记录，若超时未触发，会导致连接持续挂起。
版本或配置潜在问题
- 确认Pekko HTTP 1.0.0是否存在已知的连接泄漏Bug，部分版本在特定场景下会出现连接无法正常回收的情况。
- 当前max-connections配置为2048，该Pod已达1.73K，接近阈值可能导致新请求排队，进一步引发延迟和资源占用上升。

节点网络差异
- 查看该Pod所在节点的VPC Flow Logs，检查是否存在网络丢包、延迟波动，导致连接建立/释放报文丢失，使应用误判连接仍活跃。
- 确认节点本身是否存在资源竞争（如CPU、内存突发占用），虽应用层面显示Pod资源飙升，但节点资源瓶颈可能影响连接处理效率。
Ingress流量分发异常
- 检查Nginx Ingress的日志与监控，确认是否有大量请求被路由到该Pod：比如会话粘性配置导致特定用户请求持续命中该Pod，或负载均衡算法出现偏差。
- 验证Ingress到Pod的健康检查状态：若该Pod健康检查异常但Ingress未停止转发请求，会导致无效连接堆积。

实时抓包分析：在异常Pod上执行tcpdump抓取HTTP流量，分析连接的建立、请求处理、关闭全流程，查看是否有大量ESTABLISHED状态的连接无请求交互。
线程状态排查：使用jstack或Pekko内置监控查看事件循环线程状态，确认是否有大量线程处于阻塞状态。
Pod内连接统计：执行netstat -anp | grep <pekko-process-id>，统计不同状态的连接数量，与正常Pod结果对比。
日志级放大：临时调高该Pod的应用日志级别（如DEBUG），查看连接创建、处理、关闭的详细日志，定位异常连接的来源与处理过程。

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