postgresql - 你怎么知道 PGBouncer 是否正常工作？

Question

我已经设置了 PGBouncer 并将其配置为连接到我的 postgres 数据库，并且一切正常，但我不确定它是否真的有效。

我有一个 php 脚本作为守护进程运行并获取 beantalk 作业。问题是对于系统上的每个不同的用户/操作，它都会打开一个到 postgres 的新连接，然后让该连接处于空闲状态，因为守护进程实际上并没有停止运行，所以连接永远不会终止(对此的快速修复是重置连接在脚本循环的末尾，但是对于许多连接来说效率很低。

无论如何，这导致 postgres 最终耗尽连接并锁定...

所以 PGBouncer 似乎就是答案。

但是现在当我运行它时，当我执行 ps ax | 时我多次看到相同的数据库连接grep postgres.

难道 PGBouncer 不应该只打开 1 个到数据库的连接并通过该连接路由所有流量吗？如果连接已满，则打开一个新连接？

目前我有 3 个用于一个数据库连接(我的访问控制系统)和 2 个用于另一个数据库(我的客户特定数据)。

对我来说，感觉如果我推出这些更改，那么我将面临同样的问题，即连接将再次被耗尽，因为它们没有被释放。

我希望上面的解释足以让某人提供任何建议。

Answer 1

听起来这里的一个重要步骤是修复脚本，以便它们在完成后释放连接。一旦你这样做了，PgBouncer 将有助于减少连接设置/拆卸开销，但在连接池模式下，它不会让你能够保持比其他方式更多的 Pg 连接。

但是，您也可以在事务池模式下使用 PgBouncer。当用于事务池时，PgBouncer 保留一个空闲后端事务池，并且仅在客户端执行 BEGIN 时分配它们。在客户端执行 COMMIT 或 ROLLBACK 后，连接返回到池中。这意味着在事务池模式下，您可以打开大量到 PgBouncer 的连接；它们不需要每个都需要与 PostgreSQL 后端的相应连接，只要它们中的大多数在任何时间点都处于空闲状态并且没有打开任何事务即可。

事务池模式唯一真正的缺点是它破坏了期望 SET session 级变量的应用程序，跨事务保留准备好的语句等。应用程序可能需要修改，例如使用 SET LOCAL。