零点流量突增，订单服务连接池上限只有12，并发升到120后请求排队，支付回调超时。数据库CPU尚未跑满，值班同学不是把池从12调到100，就是重启服务，却分不清是容量偏小、慢查询占槽、事务未释放，还是连接泄漏。定位这些问题，需要可印证、可复现的证据。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：neburst（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
连接池“耗尽”指应用线程拿不到连接，不等于数据库执行了更多SQL。若占满上限的连接都在执行长SQL，活跃会话快照会出现查询时长、锁等待或I/O升高，指向慢查询关联分析。若SQL已结束但事务仍未提交或回滚，连接仍被占用；会话处于事务中，可结合事务年龄与事务阻塞链定位持锁者。若连接既不执行SQL也不处于事务中，借出计数又只增不减，才更接近连接泄漏。
配置过小则不同：流量阶跃时活跃连接贴近上限，获取连接开始等待，但单条SQL耗时正常，数据库仍有CPU、I/O与连接余量，小幅扩池后等待下降。连接池状态采样要同步取得三组快照：应用侧的活跃数、空闲数、等待数与获取等待时长；数据库侧的会话状态、语句年龄、事务年龄和阻塞者；再按请求标识关联。流量回落后，在用连接应回到基线，若长期不回落且代码找不到归还路径，泄漏证据更强。
常见误区是把数据库空闲会话直接判成泄漏，或把长事务都归咎于慢SQL。语句耗时与事务持有时长应分开看；累计借用次数不能证明当前泄漏。
先抓事务阻塞链，而不是立即改参数。把等待连接的应用请求、执行中的SQL、会话等待事件和阻塞进程ID串起来，再追到根事务。根事务持锁时，扩池只会增加等待；根因是慢SQL时，连接在执行期间占槽；根因是事务未释放时，数据库侧看似空闲，连接仍被事务占用；若链上没有长语句和开放事务，而池计数仍异常，就检查借出、异常分支与归还逻辑。
随后按池容量压测方法验证：固定数据集和请求到达率，预热后按并发阶梯加压，每级保持相同时间，采集连接等待、超时率、吞吐、数据库CPU、I/O、锁等待和事务年龄。先复现等待曲线，再只改变一个变量。数据库有余量且SQL延迟稳定时，小幅扩池能降低等待；数据库已饱和时，扩池会放大锁与I/O竞争，应先治理慢查询、缩短事务或修复泄漏。扩容值须受数据库承载能力约束，通过条件是等待下降且数据库指标不恶化。
排查时可用随身服务器保存快照或搭建隔离压测环境。采样间隔和统一时钟也不能省：一分钟粒度可能错过秒级耗尽，重启后再看则会丢失证据。
连接池状态采样应按固定周期同时抓取连接池与数据库两侧，不能只在超时后看一次峰值。每 1～5 秒记录 pending、active、idle、获取连接延迟和超时数；数据库侧保存活跃会话快照，采集 pid、application_name、state、wait_event、xact_start、query_start 及 SQL。这样可先区分池内无空闲连接，还是连接已借出却被数据库卡住。
对等待会话调用 pg_blocking_pids，沿事务阻塞链找到根阻塞会话，记录锁类型、阻塞时长和根因 SQL。idle in transaction 并非空闲，仍持有事务快照与锁；应用线程卡在业务代码、网络读取或归还连接时，也会造成池等待。
慢查询关联分析要按同一时间窗对齐池等待、阻塞链、慢日志与应用 trace。用 query_id 或参数归一化后的 SQL 指纹聚合次数、总耗时、P95、返回行数、共享块读取及锁等待。总耗时集中于单条 SQL 时检查索引与数据分布；多会话均匀排队时，优先排查 I/O、并发上限或连接泄漏。
常见坑包括：多实例池各自按上限配置，总连接数超过数据库 max_connections；把池获取超时直接当成数据库故障；忽略未提交事务或异常路径未归还连接。盲目调大池只会推迟耗尽，还可能挤占数据库资源，必须先确认泄漏点和根阻塞会话。
池容量压测方法应使用接近生产的数据量、SQL 分布和实例拓扑。先测单连接基线，再按固定步长增加并发，覆盖短事务、长事务混合场景；达到目标利用率后持续 30～60 分钟，并注入慢查询、锁冲突和节点抖动。全程记录池等待 P95/P99、获取超时、活动会话、数据库 CPU、I/O、锁数和慢 SQL。
可执行检查清单：①保存故障前后 10 分钟的池指标和活跃会话快照；②导出阻塞链、根因 SQL、事务年龄及数据库日志；③核对事务是否提交或回滚，连接是否在 finally 中释放；④用原参数重放慢 SQL 并检查执行计划；⑤阶梯加压找出饱和拐点；⑥仅在数据库有余量时调整池上限，同时设置回滚阈值与告警。
这套流程能把笼统的“连接池耗尽”还原为容量不足、事务阻塞或连接泄漏。每次调整都应附带压测数据、风险评估和回滚方案，避免用更大的池掩盖数据库瓶颈。
