如何理解连接池推荐 ((2 * n_cores) + n_disks) 与支持 100s 连接之间的 PostgreSQL 差异？

Question

来自 PostgreSQL 文档：

• 数据库连接数 -> 如何找到最佳数据库连接池大小

  为了获得最佳吞吐量，活动连接的数量应该接近 ((core_count * 2) + Effective_spindle_count)

• 调整你的 PostgreSQL 服务器 -> max_connections

  通常，良好硬件上的 PostgreSQL 可以支持几百个连接。

对我来说——不是一个有经验的 DBA——这里的某个地方存在差异，特别是查看一些 DB 即服务提供商的产品。

例如，此时 Amazon RDS 最大的机器 (db.r3.8xlarge) 有 32 个 vCPU，根据第一个公式，如果有很多磁盘，它可能会在池中有 100 个连接的情况下以最佳方式运行。使用第二个公式中的“几百个连接”，它会不会运行得很糟糕？

更极端的是另一家 DBaaS 提供商的差异，他们提出了一个具有 500 个并发连接的 2 核服务器。这怎么可能运作良好？

如果我误解了什么，请告诉我。非常感谢！

Answer 1

“可以支持”！=“最佳吞吐量”。

您可以使用大量连接，但速度较慢。

如果您使用较少的连接和队列工作，您可以在更短的时间内完成相同数量的工作。

更极端的是另一家 DBaaS 提供商的差异，他们提出了一个具有 500 个并发连接的 2 核服务器。这怎么可能运作良好？

他们要么在事务池模式下使用像 PgBouncer 这样的连接池前端，要么不能很好地工作。

人们喜欢大数字，所以他们会给你大数字。

他们这样做实际上是在损害性能。PostgreSQL 有一些与 线性扩展的成本max_connections，因此即使不使用连接，它仍然会对性能产生影响。

此外，即使是空闲连接也有一些进一步的内务管理成本。

如果连接正在积极工作，那么您还会争用系统资源和内部锁。

我经常遇到有 PostgreSQL 性能问题的人——他们试图通过在应用程序中添加更多连接、更多工作人员等来解决这些问题。尤其是运行排队系统的人。很难说服他们减少工人数量会使系统运行得更快，而且他们最初的性能问题源于数量太多。