Ktor/Exposed后端并发请求连接超时问题排查求助

核心现象复盘 #

• 仅10个并发请求就耗尽7个连接的Hikari池，抛出SQLTransientConnectionException（连接超时，active=7，waiting=18）
• 单个请求耗时约300ms，但除首个请求外，其余请求耗时均等于10秒连接超时时间

可能的根因分析 #

1. SocketTimeout配置错误导致连接异常失效 #

你的Hikari配置中设置了addDataSourceProperty("socketTimeout", "30")，PostgreSQL的socketTimeout单位是毫秒，30ms的超时远小于你单个请求的300ms耗时，这会导致数据库查询频繁触发socket超时，连接被强制关闭但未被Hikari正确回收，池内可用连接持续减少，最终耗尽。

2. 事务块内存在阻塞操作导致连接长期占用 #

newSuspendedTransaction(Dispatchers.IO)要求块内代码使用挂起函数而非阻塞操作，如果你的数据库查询或业务逻辑中包含Thread.sleep()、非挂起的JDBC调用等阻塞代码，会导致Dispatchers.IO的线程被长时间占用，事务无法及时完成，连接一直被持有不释放，快速耗尽池内连接。

3. 事务未正确提交/回滚导致连接泄漏 #

虽然newSuspendedTransaction默认会自动处理事务提交或回滚，但如果：

• 事务块内的异常被上层代码捕获但未显式触发回滚
• 手动调用了事务API（如commit()/rollback()）但逻辑有误
• Exposed的事务管理与Hikari的isAutoCommit=false配置存在冲突（Exposed会手动管理事务，关闭autoCommit可能导致连接未被正确释放）

都会导致连接被长期占用，无法返回连接池。

排查步骤 #

• 修正SocketTimeout配置：将socketTimeout改为合理值（如30000，即30秒），避免查询超时导致连接失效。
• 检查事务内代码：替换所有阻塞操作为挂起函数，确保事务能快速完成并释放连接。
• 启用Hikari调试日志：配置日志级别为DEBUG，跟踪连接的获取、使用、释放流程，定位未释放连接的请求或线程。
• 验证事务生命周期：在事务块的开始和结束处添加日志，确认每个事务都能正常提交或回滚，没有异常分支导致连接泄漏。
• 调整连接池参数：临时增大maximumPoolSize（如改为15），观察问题是否缓解，若缓解则说明原池大小不足或存在连接泄漏；若问题依旧，重点排查连接泄漏。

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