ClickHouse Managed Postgres扩展PgBouncer:进程组吞吐量达单进程4倍,突破连接池瓶颈!
如何在ClickHouse Managed Postgres中扩展PgBouncerPgBouncer单线程运行无论服务器有多少CPU核心单个进程仅使用一个核心。在16个虚拟CPU的服务器上一个核心承担所有连接池管理工作其余15个核心闲置。并且在Postgres还有处理能力时连接池就开始限制吞吐量。在ClickHouse Managed Postgres中运行一组与可用核心数成正比的PgBouncer进程。这组进程中的每个进程都使用启用了 so_reuseport 的相同端口进行绑定。内核会将传入的连接负载均衡到各个进程上客户端仍连接到单个端点不会察觉到背后有多个PgBouncer进程。这正是PgBouncer官方文档中提到的利用多个核心的机制每个进程是单线程的而 so_reuseport 可以让每个核心都发挥作用。问题查询取消Postgres的取消请求会通过一个全新的连接发送该连接携带一个取消密钥与运行查询的连接分开。使用 so_reuseport 时内核可能会将这个新连接分配给与持有会话的进程不同的进程。这样取消请求就会发送到一个从未听说过该查询的进程上导致取消操作失败。通过进程间的“对等机制peering”可以解决这个问题。这些进程相互了解若取消请求发送到了错误的进程它会被转发到实际持有会话的进程。这样即使任何给定的请求可能到达任意进程整个进程组都能正常处理取消操作。连接池以事务模式运行一旦事务提交服务器连接就会返回到连接池。并且连接预算会在整个进程组中进行分配max_client_conn 和 max_db_connections 会除以进程数量确保整个进程组不会使Postgres过载。在真实硬件上的测试结果在相同的AWS EC2实例上运行了两种配置一个16虚拟CPU的 c7i.4xlarge 实例用于运行连接池另一个单独的实例运行Postgres还有一个实例使用 pgbench 在仅查询、事务池模式下施加负载。一个连接池实例运行单个PgBouncer进程另一个运行16个进程组成的进程组。实例类型、Postgres、工作负载均相同唯一的变量就是单个进程与16个进程的区别。将客户端连接数从8增加到256并测量了吞吐量以及每个连接池实际使用的16核心服务器的资源情况。单个进程在大约87000笔交易/秒时达到峰值之后随着负载增加性能反而下降。当客户端数量达到256时吞吐量降至77000笔交易/秒因为所有操作都在争夺一个核心的资源。而进程组的吞吐量持续上升最终达到约336000笔交易/秒大约是单个进程的4倍因为它可以利用更多的核心。单个进程的工作负载从未超过一个核心在负载下pidstat 显示PgBouncer进程的CPU使用率固定在约97%即一个完整的核心而16虚拟CPU的服务器整体利用率仍低于10%。进程组则可以充分利用服务器资源大约有8个核心处于忙碌状态并且在Postgres和负载生成器成为瓶颈之前还有提升空间。保持256个客户端对每个实例的稳定连接单进程实例在整个运行过程中的CPU使用率接近9%而进程组的CPU使用率约为52%。实例类型、Postgres、工作负载相同但一种配置使服务器闲置另一种则充分利用了服务器资源。EC2的CloudWatch指标从外部也反映了相同的情况在负载期间单进程实例的平均CPU利用率约为16%而进程组约为60%。CloudWatch的读数比实例内部的读数略高但差距依然存在在为16个虚拟CPU付费的服务器上单个PgBouncer几乎让所有资源都闲置了。连接上限的情况也是如此。单个进程会自行实施 max_client_conn 限制一旦超过这个限制新的客户端就会被拒绝连接FATAL: no more connections allowed (max_client_conn)将连接预算分配到进程组中可以在保证每个进程和Postgres处于安全限制范围内的同时提高总体连接上限。客户端数量单进程TPS单进程实例CPU进程组TPS进程组实例CPU889100.8%64502.9%32542035.2%6424412.3%64865708.3%21943931.9%128834638.1%32054745.9%256768937.7%33646948.9%在连接数较少时单个进程的表现实际上还不错甚至稍微快一些因为此时没有并行操作而进程组的连接分布较分散。但在真正的并发场景下差距就会显现出来因为单个核心会成为性能瓶颈。总结在连接池而非Postgres成为吞吐量瓶颈之前单个PgBouncer是一个不错的默认选择。根据核心数量调整进程组的大小使用 so_reuseport 共享一个端口并通过对等机制将进程连接起来可以让连接池不再成为瓶颈而是高效的基础组件。每个ClickHouse Managed Postgres服务器默认都采用这种配置。可以创建一个Postgres实例来体验一下。试用ClickHouse管理的PostgresClickHouse Postgres已成为可扩展应用程序的统一数据栈。随着ClickHouse Cloud中托管Postgres的推出可以从一开始就选择这个强大的数据栈。立即注册立即开始使用想了解ClickHouse如何处理数据吗只需几分钟即可开始使用ClickHouse Cloud并获得300美元的免费信用额度。立即注册