Diagnose ambiguous failures be…

# QPS 1200 随机超时诊断指南

一、先定位故障层（按顺序排查）

1. 确认超时发生在哪一环

• 梳理链路：网关 → 应用 → 下游服务/DB/缓存
• 检查全链路日志的 traceId，看超时请求卡在哪个 span
• 区分：应用 RT 变长 vs 连接建立失败（connection reset 提示偏后者）

2. connection reset 的典型来源

• 后端应用线程池打满，accept 后处理不过来，或 keepalive 被内核/中间层断掉
• LB/网关的连接空闲超时 < 服务实际使用时长，导致使用了已被回收的连接
• 连接池配置过小，排队超时后连接被服务端重置

二、重点检查项（不先改代码）

应用侧

• 线程池是否打满：监控 active/pool size/queue 长度
• GC 情况：是否有长 STW，尤其 CMS/Full GC，1200 QPS 下堆压力大
• 接口 RT 分布：P99/P999 vs 平均值，确认是长尾恶化

连接层

• 连接池配置：maxActive、maxWait、是否复用了服务端已关闭的连接（建议开启连接有效性检测/testOnBorrow 的替代方案如心跳）
• TCP 层：服务端 netstat -s 看 reset 计数增长；ss -s 看 TIME_WAIT/CLOSE_WAIT 是否异常堆积
• 半连接/全连接队列是否溢出（netstat -s 中的 listen drops/overflow）

基础设施

• LB 的 idle timeout 配置 vs 连接池心跳周期是否匹配
• 容器/虚拟机：CPU throttling（cgroup limit）、网卡软中断是否集中在单核（mpstat -P ALL）
• 下游 DB/缓存：慢查询、连接数上限、缓存命中率下降导致的穿透

三、验证方法

• 压测复现：从 800 QPS 逐步加压，观察哪项指标先恶化（线程池/连接池/GC/队列溢出）
• 抓包：对 reset 的连接用 tcpdump 看 reset 由哪端发出、连接存活多久，可精确区分是 LB 回收还是应用主动拒绝

四、常见根因排序（经验）

1. 连接池与 LB idle timeout 不匹配（偶发 reset 最常见）

2. 线程池队列排队导致长尾超时

3. DB 慢查询/锁等待拖长 RT

4. GC 长暂停

五、之后再谈改代码

确认根因后针对性调整：连接池参数与心跳、超时与重试策略（注意幂等）、线程池隔离、慢 SQL 优化。避免无证据地加机器——若瓶颈在连接回收或锁，扩容无效。

建议先做第二、三部分排查，拿到数据后再决策，多数情况下不改业务代码即可解决。