应用请求连接数超PostgreSQL max_connections的问题及理论验证

背景 #

生产环境出现偶发且每周愈发频繁的未知错误，有时会导致整个应用或所有后台进程宕机。宕机前短时间内会触发数百次PostgreSQL错误：FATAL: sorry, too many clients already，目前尚未明确问题根源，现提出初步理论请求验证逻辑合理性。

初步理论 #

1. 潜在连接需求计算：

   • Ruby on Rails应用的12个Puma worker，每个包含16个线程，对应192个潜在数据库连接；
   • 10个后台worker，每个允许使用1个数据库连接；
   • 1个SSH会话占用1个数据库连接；
   • 总计潜在连接需求为203个。

2. 数据库配置现状：
   PostgreSQL的max_connections参数仍为默认值100，远低于应用侧的潜在连接需求。

3. 问题触发逻辑：
   应用根据自身Puma和后台worker的配置发起连接请求，但当PostgreSQL已达100个连接上限时，会直接拒绝新的连接请求，短时间内大量触发连接失败错误，最终导致应用或后台进程宕机。

4. 理想状态与解决方案：
   若应用侧的潜在连接数≤PostgreSQL的max_connections，连接池会通过pool timeout机制将请求排队，等待可用的数据库套接字，避免直接拒绝。因此解决思路为：

   • 优先调整应用侧配置，使潜在连接数≤数据库允许的连接数；
   • 若连接需求确实超过100，再考虑提升PostgreSQL的max_connections上限。

逻辑验证与补充建议 #

你的逻辑完全合理，这是典型的连接池配置与数据库连接上限不匹配引发的生产问题。补充几点实操建议：

• 可通过执行SELECT count(*) FROM pg_stat_activity;实时查看数据库当前连接数，确认峰值是否接近或超过100，验证理论的准确性；
• 调整Rails应用的数据库连接池配置时，需注意每个Puma worker的pool参数设置，确保所有组件的连接数总和（预留系统超级用户的3个连接）不超过max_connections；
• 提升max_connections前需评估服务器内存资源，每个PostgreSQL连接会占用一定内存，过多连接可能导致服务器内存耗尽，引发新的稳定性问题。

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