Sidekiq后台任务报ActiveRecord::ConnectionTimeoutError连接池获取失败问题

排查方向 #

1. 验证生产环境实际生效的数据库连接池大小 #

Heroku部署时存在配置加载优先级问题，启动命令传入的环境变量可能被其他配置覆盖：

• 执行命令heroku run bash -a 你的应用名进入worker dyno，启动Rails控制台后执行ActiveRecord::Base.connection_pool.size，确认实际生效的连接池大小是否为预期的14。
• 检查Heroku全局Config Vars中是否设置了DB_POOL参数，全局配置会覆盖进程启动命令中传入的同名变量。

2. 排查连接泄漏问题 #

• 检查Sidekiq任务代码中是否存在手动创建线程的逻辑，比如使用Thread.new、Parallel等并行库，这类额外线程不受Sidekiq的concurrency参数限制，每个线程都会独立占用1个数据库连接，很容易打满连接池。
• 排查是否存在长事务/阻塞逻辑未释放连接：比如任务中调用外部接口长时间无返回、事务未正常提交，导致连接被持续持有，不会被放回连接池。

3. 检查Sidekiq的ActiveRecord连接管理适配 #

Sidekiq 6+版本已经默认内置了ActiveRecord连接自动归还逻辑，如果项目中存在旧版本适配的自定义中间件，反而可能破坏连接回收逻辑：

• 查看config/initializers/sidekiq.rb中是否手动添加了ActiveRecord::ConnectionAdapters::ConnectionManagement中间件配置，Sidekiq 6+版本可以直接删除这段配置。

解决建议 #

1. 如果确认Sidekiq进程的连接池实际值未达到14，修改database.yml的production段配置，明确区分不同进程的连接池大小：

production:
  url: <%= ENV['DATABASE_URL'] %>
  pool: <%= ENV.fetch("IS_SIDEKIQ") ? 14 : ENV.fetch("PUMA_MAX_THREADS", 5) %>
  reconnect: true

同时修改Sidekiq启动命令，新增IS_SIDEKIQ=1环境变量标识，保证Sidekiq进程读取到对应大小的连接池配置。
2. 给Sidekiq任务增加执行超时限制，使用timeout gem设置任务最大执行时长，超时后自动释放资源和数据库连接，避免异常阻塞导致连接泄漏。
3. 临时将Sidekiq的concurrency参数调整为5进行测试，如果不再抛出连接超时错误，即可100%确认是Sidekiq进程的连接池配置未生效问题，无需再排查其他方向。

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