PostgreSQL 扩展到 64 核?

O_O*_*O_O 11 postgresql database scalability

在这篇计算机世界文章中,它指定 PostgreSQL 可以扩展到 64 核的限制。这是否意味着一个 64 核的多核处理器?还是内核更少的多个处理器?

我问的原因是因为我试图找出 PostgreSQL 可以扩展到多少处理器,但当然这可能仅限于处理器的类型。但是,我一直在其他数据库中找到其他统计数据(即 Microsoft SQL Server在这里声明它可以扩展到 320 个逻辑处理器),并且他们没有指定它们的核心数。这是一个非常模糊的统计数据吗?

任何想法将不胜感激。谢谢!

vor*_*aq7 13

Postgres 可以扩展到您想要安装的任意数量的处理器,并且您的操作系统可以有效地处理/管理。您可以在 128 核机器(甚至是具有 128 个物理处理器的机器)上安装 Postgres,它会正常工作。如果操作系统调度程序可以处理那么多核,它甚至可能比在 64 核机器上工作得更好。

Postgres的已经显示出扩展 线性多达64个内核(带警告:我们正在谈论的读取性能,在特定的配置(磁盘,内存,操作系统等) -罗伯特·哈斯有一个漂亮的图的博客文章,其我在下面转载:

在此处输入图片说明

这个图有什么重要的?

只要Number of Clients小于或等于Number of Cores,这种关系就是线性的(或几乎是线性的),然后开始看起来性能大致呈对数线性下降,因为客户端连接数比您多做内核来运行 Postgres 后端,因为后端开始争夺 CPU(平均负载超过 1.0,等等......)。

虽然它仅针对最多 64 个内核进行了演示,但您可以概括地说,您可以不断添加内核(和客户端)并不断提高性能,直至达到某些其他子系统(磁盘、内存、网络)的限制,其中进程不再有 CPU 争用问题,而是在等待其他事情。

Haas 还有另一篇文章,他们证明了 32 核的线性可扩展性,其中有一些关于一般可扩展性的很好的参考资料——强烈推荐背景阅读!)

  • 顺便提一下,[Oli 的回答](http://serverfault.com/a/459116/32986) 中提到了这种线性可扩展性的原因:Postgres 为每个客户端连接使用单独的后端进程。因此,如果您只使用一个连接,您将看不到多核的太多(如果有)好处——您需要并行请求才能利用多核。 (2认同)

Oli*_*Oli 8

不,这是一个非常精确的统计数据。“逻辑处理器”是一个核心。核心就是这样,它们如何分布在物理处理器上并不重要。

而且,如果您正在处理内核数超过支持数量的机器,那么这对于 PostgreSQL 来说应该不是问题。每个连接本质上都是单线程*,因此无论您拥有多少内核,都会限制并发连接的效率和功效。

不用说,这也意味着您应该将资金投入到比核心数量更快的核心上,除非您想以更复杂的方法对事物进行聚类。

* 2017 更新:某些查询(或子查询)可能会并行执行

  • @voretaq7:通过某种连接池机制连接到 postgresql 并不少见。之所以这样做,是因为连接到 postgresql 的成本相对较高。池化可以极大地减少与数据库的并发连接数。所以我倾向于比内核数更喜欢快速 CPU。但一如既往:这取决于许多因素...... (3认同)
  • `不用说,这也意味着你应该把钱花在比核心数量更快的核心上,除非你想用更复杂的方法对事物进行集群。` <- 如果核心数量大于核心数量,我才同意这个说法并发客户端的数量,并发客户端的数量不太可能增加。为每个 Postgres 后端提供一个内核对性能来说非常重要...... (2认同)
  • @m.sr 同意 - 连接池机制非常普遍。其中“最聪明的”将启动到 Postgres 的多个连接并在它们之间进行平衡(我们的一个内部应用程序通过为每个 Apache 进程提供自己与 Postgres 的连接来实现这一点——对于我们的用例来说,这是一个非常方便的映射,具有合理的后端-与用户的比率)。恕我直言,如果您的连接池使查询排队而不是产生后端,它对您没有任何好处,但是深入研究 [dba.SE] 的利弊会更有趣。[所以我问了!](http://dba.stackexchange.com/questions/30711) (2认同)