我们将 PgBouncer 的吞吐量扩展到 4 倍

PgBouncer 是单线程的。单个进程使用一个 CPU 核心，无论机器有多少个。在 16 个 vCPU 机器上，这意味着一个核心负责所有连接池，而另外 15 个核心则闲置，并且池化器早在 Postgres 空间耗尽之前就开始限制吞吐量。在 ClickHouse Managed Postgres 中，我们运行一组 PgBouncer 进程，其大小与可用核心成比例。队列中的每个进程都绑定相同的端口并启用 so_reuseport。内核在进程之间对传入连接进行负载平衡，因此客户端仍然连接到单个端点，并且永远不知道其后面有多个 PgBouncer。这是 PgBouncer 自己的文档指出的使用多个核心的机制：每个进程都是单线程的，so_reuseport 是让每个核心工作的方式。要点：查询取消 # Postgres 取消请求到达一个带有取消键的全新连接，该连接与运行查询的连接分开。使用 so_reuseport ，内核可以自由地将新连接移交给与持有会话的进程不同的进程。取消落在从未听说过该查询的进程上，并且什么也没有发生。对等互连解决了这个问题。这些进程彼此了解，因此发生在错误进程上的取消会被转发到实际拥有会话的进程。即使任何给定的请求可以到达任何地方，取消功能也适用于整个机队。池化在事务模式下运行，因此服务器连接会在事务提交时返回到池中。连接预算在整个队列中分配：max_client_conn 和 max_db_connections 除以进程数量，因此整个队列永远不会超额订阅 Postgres。在真实硬件上查看 # 我们在相同的 AWS EC2 实例上运行这两种配置：用于池化器的 16-vCPU c7i.4xlarge、用于 Postgres 的单独盒子，以及在仅选择、事务池模式下使用 pgbench 驱动负载的第三个驱动负载。一个池化器运行一个 PgBouncer 进程；另一个运行 16 个集群。相同的实例类型、相同的 Postgres、相同的工作负载。唯一的变量是一个进程与十六个进程。我们将客户端连接从 8 个增加到 256 个，并测量吞吐量以及每个池化器实际使用的 16 核盒子的数量。单个进程的峰值约为 87k 事务/秒，然后在更多负载下变得更糟，在 256 个客户端上下滑至 77k，因为所有内容都在争夺一个核心。该队列不断攀升至约 336k 事务/秒，约为 4 倍，因为它有更多的核心可供使用。单个进程永远不会超过一个核心的工作：在负载下，pidstat 显示 PgBouncer 进程固定在约 97% CPU（一个完整核心）上，而 16-vCPU 框整体利用率保持在 10% 以下。机群分布在整个机器上，大约有 8 个核心处于忙碌状态，当 Postgres 和负载生成器达到极限时，它仍然有空间。每个盒子稳定地保持 256 个客户端：单进程盒子在整个运行过程中运行着接近 9% 的 CPU，而机群则保持着大约 52%。相同的实例类型、相同的 Postgres、相同的工作负载。一种配置使机器闲置，另一种配置则使其工作。 EC2 自己的 CloudWatch 指标从来宾外部也得出了同样的结论：在加载期间，单进程实例的 CPU 利用率平均约为 16%，队列约为 60%。 CloudWatch 读取的数据略高于来宾数量，但存在同样的差距：在您支付 16 个 vCPU 的机器上，单个 PgBouncer 几乎将所有数据留在地板上。连接上限的行为方式相同。单个进程会自行强制执行 max_client_conn，一旦超过它，新客户端将被拒绝： 1 致命：不允许更多连接 (max_client_conn) 复制命令 在整个队列中分配预算可以让您提高总体上限，同时将每个进程和 Postgres 保持在安全限制内。客户端 单 TPS 单机箱 CPU 队列 TPS 队列 机箱 CPU 8 8,910 0.8% 6,450 2.9% 32 54,203 5.2% 64,244 12.3% 64 86,570 8.3% 219,439 31.9% 128 83,463 8.1% 320,547 45.9% 256 76,893 7.7% 336,469 48.9% 在少量连接的情况下，单个进程实际上很好，甚至快一点，因为没有什么可以并行化，而且队列的连接分布很薄。这一差距正是在重要的地方出现：在真正的并发情况下，一个核心变成了墙。要点 # 单个 PgBouncer 是一个很好的默认设置，直到池化器（而不是 Postgres）限制了你的吞吐量。将队列规模调整到核心，与 so_reuseport 共享一个端口，并通过对等互连将进程连接在一起，从而使池化器重新成为管道而不是瓶颈。默认情况下，每个 ClickHouse 托管 Postgres 服务器都附带此设置。配置一个 Postgres 并查看它的运行情况。尝试由 ClickHouse 管理的 Postgres ClickHouse + Postgres 已成为可扩展应用程序的统一数据堆栈。由于托管 Postgres 现在可在 ClickHouse Cloud 中使用，因此该堆栈是第一天就做出的决定。报名