你怎么知道 PGBouncer 是否在工作？

Question

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

我有一个 php 脚本，它作为守护进程运行并获取 beanstalk 作业。问题是对于系统上的每个不同的用户/操作，它都会打开一个与 postgres 的新连接，然后使该连接处于空闲状态，因为守护程序实际上并未停止运行，因此连接永远不会终止（对此的快速解决方法是重置在脚本循环结束时进行连接，但是对于许多连接来说效率会很低）。

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

所以 PGBouncer 似乎是答案。

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

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

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

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

我希望这足以解释，以便有人提供任何建议。

Answer 1

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

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

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