3

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

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

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

所以 PGBouncer 似乎是答案。

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

PGBouncer 不应该只打开 1 个连接到数据库并通过该连接路由所有流量吗?然后打开一个新连接,如果那个连接已满?

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

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

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

4

1 回答 1

2

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

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

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

于 2012-11-13T07:46:34.697 回答