使用play-slick连接Heroku Postgres时出现间歇性连接失败求助

安全阿岳

2026-5-21

调试Heroku上Play-slick连接Postgres的偶发超时问题

这种部署时约30%概率出现的java.sql.SQLTransientConnectionException确实很棘手，我帮你梳理几个关键的调试方向，一步步排查：

1. 先检查连接池（HikariCP）的核心配置

Play默认用HikariCP作为连接池，很多超时问题都和它的参数设置有关：

调整连接超时时间：你的错误显示超时是1007ms，接近默认的1000ms，建议把db.default.hikaricp.connectionTimeout调到2000-3000ms，给网络波动留缓冲空间。
控制连接池大小：Heroku Postgres有严格的连接数限制（比如免费版是20，标准版根据规格不同），计算所有dyno的连接池总和不能超过这个上限。比如设置db.default.hikaricp.maximumPoolSize=5，再结合WEB_CONCURRENCY变量，确保总连接数在Postgres允许范围内。
设置合理的连接生命周期：Postgres默认有idle_in_transaction_session_timeout（Heroku通常是5分钟），要让HikariCP的maxLifetime比这个值短，比如设为4分钟（db.default.hikaricp.maxLifetime=240000），避免拿到失效的连接。
启用连接有效性测试：添加db.default.hikaricp.connectionTestQuery=SELECT 1，让连接池在分配连接前验证可用性，避免分发死连接。
初始化失败重试：设置db.default.hikaricp.initializationFailTimeout=0，这样连接池初始化时如果遇到临时问题会自动重试，而不是直接报错。

部署时新旧dyno可能同时运行，导致连接数瞬间超过上限：

用heroku pg:info查看当前Postgres的Connections使用情况，对比它的Connection Limit，确认是否接近阈值。
调整Heroku的部署策略：比如启用优雅关闭，给旧dyno足够时间释放连接。可以在Procfile里添加web: java -Dplay.server.http.idleTimeout=60s $JAVA_OPTS -jar target/universal/stage/lib/*.jar，延长空闲超时时间；或者设置Heroku的HEROKU_DYNO_SHUTDOWN_TIMEOUT环境变量，给旧实例更长的关闭时间（默认30秒）。
减少并发dyno数量：如果WEB_CONCURRENCY设置过高，每个dyno都有自己的连接池，总连接数很容易超标，适当调低这个值。

默认日志可能不够详细，需要开启更细粒度的日志：

在conf/logback.xml里添加HikariCP的DEBUG日志：
```
<logger name="com.zaxxer.hikari" level="DEBUG" />
```
这样能看到连接池的连接获取、释放、超时的具体过程，定位是连接池拿不到连接，还是Postgres拒绝连接。
查看Postgres的日志：用heroku pg:logs，检查是否有too many connections或者连接拒绝的日志，这能直接说明是连接数超了还是Postgres资源不足。

部署时应用启动阶段的连接初始化可能出问题：

添加应用启动钩子，提前预热连接池：比如在ApplicationLoader或者ApplicationStarted事件中，执行一个简单的查询（比如SELECT 1），强制连接池初始化几个连接，避免第一个请求就遇到超时。
确保应用关闭时优雅释放连接：Play应用收到Heroku的SIGTERM信号时，要主动关闭连接池。可以在自定义的ApplicationLoader中添加关闭钩子：
```
override def stop(context: ApplicationLoader.Context): Unit = {
  context.application.injector.instanceOf[Database].close()
  super.stop(context)
}
```

Heroku dyno和Postgres之间的网络偶尔会有临时波动，这种情况可以：

尝试切换Postgres的连接方式：比如从JDBC切换到Slick的原生配置，确保play-slick用的是最优的连接参数。
开启HikariCP的leakDetectionThreshold：设置db.default.hikaricp.leakDetectionThreshold=2000，检测是否有连接泄漏，比如代码中忘记关闭连接导致连接池耗尽。

按照这些步骤排查，应该能定位到偶发超时的原因。如果某个调整后问题消失，就能确认是对应的配置或流程问题。

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