PgBouncer连接池中客户端连接长期驻留问题解析

问题现象

在使用PgBouncer(v1.22.1)作为PostgreSQL(v16.2)连接池中间件时，发现一个典型问题：随着系统运行，PgBouncer中的活跃客户端连接数量会持续增长，最终达到配置的最大连接数限制(max_client_conn)。此时新连接请求会被拒绝，影响业务正常运行。

问题分析

经过深入排查，发现这种现象主要源于应用程序没有正确关闭数据库连接。当应用程序崩溃或异常终止时，这些"孤儿"连接会继续驻留在PgBouncer中。正常情况下，PgBouncer应该能够自动清理这些无效连接，但在某些情况下，清理机制可能被延迟，导致连接长时间(甚至数天)得不到释放。

技术原理

PgBouncer内部有一个称为"janitor"(看门人)的机制，负责定期检查和清理无效连接。这个机制的核心参数是client_idle_timeout，它定义了客户端连接在空闲多长时间后应该被自动关闭。如果这个参数设置为0(默认值)，则不会基于空闲时间自动关闭连接。

在连接池模式下(Pool Mode)，特别是事务模式(transaction)下，PgBouncer会重用连接而不是为每个客户端请求创建新连接。这种设计虽然提高了性能，但也使得连接状态的维护变得更加重要。

解决方案

通过将client_idle_timeout参数设置为一个合理的非零值(如300秒)，可以确保janitor机制能够定期清理那些被应用程序异常遗弃的连接。这个值应该根据具体业务场景进行调整：

1. 对于短连接频繁的业务，可以设置较小的值(如60-300秒)
2. 对于长连接业务，需要设置较大的值以避免误杀有效连接
3. 需要平衡连接复用效率和资源释放速度

配置建议

除了调整client_idle_timeout外，还需要注意以下配置参数的协同工作：

[pgbouncer]
pool_mode = transaction
max_client_conn = 10000
default_pool_size = 80
max_prepared_statements = 200
client_idle_timeout = 300  # 新增的关键配置

同时，后端PostgreSQL的max_connections参数也需要合理配置，通常应该大于PgBouncer的default_pool_size乘以服务器数量，以确保有足够的后端连接可供使用。

最佳实践

1. 应用程序层面确保正确关闭数据库连接
2. 监控PgBouncer的连接状态，特别是活跃连接数
3. 定期检查连接池统计信息，识别异常连接模式
4. 在开发环境中模拟应用崩溃场景，验证连接回收机制
5. 考虑使用PgBouncer的SHOW CLIENTS和SHOW SERVERS命令进行诊断

通过以上措施，可以有效预防和解决PgBouncer连接池中的连接泄漏问题，确保数据库服务的稳定性和可靠性。