Postgres 可扩展性 - 连接池的影响是什么？

Question

我们有一个关于 Server Fault 的问题，提出了一个有趣的问题：
鉴于 Postgres 9.2 可扩展性改进中的可扩展性改进，使用连接池机制来避免与数据库建立额外连接的开销更好，还是连接提高读取性能的开销值得吗？

---

将它具体与我的环境相关联：我们有一个以数据库为支持且以读取为中心的 Web 应用程序，我们目前在 Postgres 8.4 上运行。

我们的重新实现将于明年启动，同时升级到 9.2，并为每个 Apache 工作进程提供自己与数据库的连接（因此，它自己的 Postgres 后端会在 Apache 工作人员的生命周期内保留）。
根据我们所看到的，这似乎是连接到数据库的开销和让更多工作人员处理读取负载之间的良好平衡，尽管我们还没有进行任何实质性的基准测试来确认这一点。

该实现看起来是否合理？鉴于最近的可扩展性改进，我们是否应该考虑其他选项/连接池机制？

Answer 1

我认为你看到了一个不存在的错误二分法。

即使您期望客户端到后端的 1:1 映射，连接池也很有用。如果您的连接是长期存在的，您将不会从减少后端设置/拆卸开销中受益，因为它很小并且会在很长一段时间内摊销。由于其他原因，像 PgBouncer 这样的池可能仍然有用：

• 阻塞直到连接可用而不是立即返回max_connections exceeded错误；
• 如果故障转移到备用服务器，则可以切换池目标服务器，而无需重新配置应用程序；
• 您可以将应用程序数据库工作人员限制为低于max_connections，因此您仍然可以以非超级用户身份进行报告和维护连接。

此外，如果适合您的应用程序，您可以使用事务级池来大大增加您的服务器可以服务的客户端数量。

我个人不会试图保持从 Apache 工作人员到 PostgreSQL 工作人员的严格 1:1 映射。如果您的 PostgreSQL 机器上有（例如）16 个内核和良好的 I/O，您可能需要像 16-20 个活动的 PostgreSQL 工作人员以获得最佳性能。您几乎肯定需要更多的 Apache 工作人员，因为他们会因为以下事情而忙碌：

• 来自空闲客户端的持久 HTTP 连接；
• 无响应或非常慢的客户端；
• 故意的 DoS 连接；
• 客户端和服务器之间的网络中断；等等

如果可能，请考虑使用短期事务的事务池设计。