我已经设置了PGBouncer并将其配置为连接到我的postgres数据库，所有连接都很好，但我不确定它是否真的有用。
我有一个PHP脚本作为守护进程运行并且获取beanstalk作业。问题是系统上的每个不同用户/操作都会打开与postgres的新连接，然后使该连接空闲，因为守护程序实际上并没有停止运行，因此连接永远不会终止（快速修复此问题是重置脚本循环结束时的连接，但是对于许多连接来说效率很低。）
无论如何，这导致postgres最终耗尽连接并锁定......
所以PGBouncer似乎就是答案。
但是现在当我运行它时，当我执行ps ax时，我会多次看到相同的数据库连接grep postgres。
PGBouncer是不应该只有1个连接打开数据库并通过该连接路由所有流量？如果那个连接已满，请打开一个新连接？
目前我有3个用于一个数据库连接（我的访问控制系统），2个用于另一个数据库（我的客户端特定数据）。
对我而言，感觉如果我推出这些更改，那么我将面临同样的问题，即连接会因为没有被释放而再次被吃掉。
我希望这足以让某人提出任何建议。
答案 0 :(得分：2)
这听起来像是重要的一步是修复脚本，以便在完成后释放连接。一旦你这样做，PgBouncer将有助于减少连接设置/拆除开销，但在连接池模式下，它不会让你能够保持与Pg的更多连接。
但是，您也可以在事务池模式下使用PgBouncer。当用于事务池时，PgBouncer会保留一个空闲后端事务池，并仅在客户端执行BEGIN时分配它们。客户端执行COMMIT或ROLLBACK后，会将连接返回到池中。这意味着在事务池模式下，您可以拥有大量与PgBouncer的开放连接;他们并不需要与PostgreSQL后端相对应的连接，只要大多数后端处于闲置状态并且没有任何事务处于打开状态。
事务池模式的唯一真正缺点是它会破坏期望SET会话级变量的应用程序，跨事务保留准备好的语句等。应用程序可能需要修改，例如：使用SET LOCAL。