PgBouncer 吞吐量狂飙 4 倍的秘密
We scaled PgBouncer to 4x throughput
PgBouncer 天生是单线程的，这意味着在拥有 16 核的机器上，单进程运行时其他 15 个核心都在摸鱼，导致吞吐量早早触顶。我们在 ClickHouse Managed Postgres 中通过部署 PgBouncer 集群，利用 so_reuseport 让内核自动将连接负载均衡到所有进程，并配合 Peering 机制解决了跨进程取消请求的难题。实测数据显示，在相同的 AWS EC2 实例上，16 个进程的集群方案相比单进程方案，吞吐量从 8.7 万 TPS 飙升至 33.6 万 TPS，整整提升了 4 倍，同时 CPU 利用率也从个位数跃升至 50% 以上。这证明只要合理配置，连接池器完全可以不再是瓶颈。
单个 PgBouncer 进程是不错的默认选择，直到连接池器而非 Postgres 本身成为限制你吞吐量的瓶颈。
- 有评论者指出 Postgres 每连接 fork 一个进程的模型导致连接建立开销巨大，在 Serverless 架构下极易引发连接数爆炸，因此连接池化仍是刚需。
- 一位从业者反驳称 PgBouncer 的存在本身是荒谬的，认为 Postgres 内核应原生解决连接复用问题，而非依赖外部代理。
- 关于性能优化，评论提到利用 SO_REUSEPORT 技术可在内核层直接分发连接，相比传统方案能减少用户态跳转并提升吞吐量。
- 针对分布式场景，Peering 机制允许 PgBouncer 实例间转发 Cancel 请求，解决了请求落在非会话持有进程导致取消失败的问题。
- 有开发者分享经验称，虽然 PgBouncer 已能支撑 10K+ 连接，但最佳实践建议将连接数控制在数百以内，通过架构调整而非单纯堆砌连接来扩展。