数千个连接和分布式事务的 PostgreSQL 数据库性能问题答案

【问题标题】：PostgreSQL DB performance issues with thousands of connections and distributed transactions数千个连接和分布式事务的 PostgreSQL 数据库性能问题
【发布时间】：2016-09-22 00:38:02
【问题描述】：

我们正在尝试在我们的应用程序中评估 PostgreSQL DB 作为 Oracle 数据库的替代品。我们使用 PostgreSQL 9.5，它安装在具有 128 GB 内存、32 个 CPU 内核和 SSD 存储的 Linux 机器上。连接池和分布式事务由 JBoss 7 应用服务器管理，SQL 查询由 Hibernate 4 生成/执行。大多数表有数千万行，其中一张有数亿行。总共有大约 3,000 个数据库连接（它们由应用程序服务器汇集）处于活动状态并同时使用。我们修改了一些查询，为慢查询创建了索引，根据文档调整了数据库和操作系统设置等。但是，吞吐量慢了几倍，最终数据库响应时间增加了 10-20 倍。

我进行了一些谷歌搜索，但找不到其他人 (ab) 以相同方式使用 PostgreSQL DB 的信息：

使用数千个活动数据库连接
使用如此大量的分布式事务（PREPARED TRANSACTIONS）
在一张表中存储数十亿行

Oracle 在处理更高的负载时没有任何问题。非常感谢您分享您的经验、建议、链接等。

谢谢

【问题讨论】：

Zalando 使用 Postgres，它们同时为大量客户提供服务。所以它不像引擎很麻烦我可以告诉你:) 处理大表分区很方便。这个问题很宽泛，我猜你不会得到你期望的答案。
感谢您的评论。但是根据他们的 GIT 存储库 (github.com/zalando/patroni/search?utf8=%E2%9C%93&q=prepared)，他们不使用分布式事务：max_prepared_transactions=0 另外 max_connections 的默认值为 100。我知道生产价值可能会有所不同。
您有自己的事务管理器吗？您是否使用分布式事务来允许跨集群上不同数据库的全局事务？您是否考虑过赔偿？
"数以千计的活动数据库连接" 是你的问题。您应该使用连接池将其降至“数百”
我认为您必须尝试找出问题所在。是数据量吗（尝试归档/清除）。真的是并发连接吗（如果你只用一百个连接进行测试，你会得到你想要的响应时间吗？）。尝试使用 JMeter 或类似工具进行测试，确定问题，然后寻找解决方案。您是否修改了 PostgreSQL 的默认参数设置？当我们进行性能测试时，我已经迁移了一个有几百 GB（我猜它按照你的标准是很小的）和几百个并发用户的 Oracle 数据库，并且得到了相同/相似的响应时间。

标签： postgresql hibernate jboss7.x

【解决方案1】：

解决方案是升级 Linux 内核并将我们的 Java 连接池中的数据库连接数从 3000 减少到 300。在此更改之后，我们可以处理与使用 Oracle DB 相同的流量。

我偶然发现了一条宝贵的信息，它可以在 cmets 部分为 Robert Haas 撰写的帖子Did I Say 32 Cores? How about 64? 解决问题（副总裁，首席架构师，数据库服务器@ EnterpriseDB，PostgreSQL 主要贡献者和提交者）：

不，我是说要在 64 核服务器上获得良好的性能，您需要 PostgreSQL >= 9.2 和 Linux >= 3.2。大多数更改实际上都发生在 PostgreSQL 方面，但 Linux 内核中的 lseek 扩展功能也很重要。

【讨论】：

【解决方案2】：

应该在 postgresql.conf 文件中提供适当的设置以处理大量连接。它也可以由 pgpool2 前端用于复制和负载平衡。我们在集群环境中使用 Postgres，它运行良好。

【讨论】：

你有成千上万的并发活动连接，使用分布式事务，有数亿条记录吗？
是的，多台服务器，多个应用，大量用户同时连接
您能定义“大量用户”吗？是成百上千个并发 ACTIVE 查询吗？