问题描述
我们有一个运行 6 个 PgBouncer 进程的设置，我们的性能基准会随着时间线性下降。 PgBouncer 运行的时间越长，与 Postgres 的连接存在的时间越长，导致基准测试的响应时间越慢。我们有一个多租户模式分离的数据库，有 2000 多个关系。我们现在配置为事务模式池。随着时间的推移，我们看到每个 Postgres 进程的内存占用量不断攀升，不断攀升，再次导致性能下降。
我们尝试通过以下设置更积极地清理空闲连接：
min_pool_size=0
server_idle_timeout=30 (seconds)
server_lifetime=120 (seconds)
我们看到的问题是，在 Postgres 中我们仍然总是有很多空闲连接。当我们使用“show pools”监控 PgBouncer 时，我们看到 sv_idle 计数上升和下降，因此我们假设设置在 PgBouncer 中有效，但这并没有转化为 Postgres 中空闲连接的减少。就好像 PgBouncer 真的没有终止 Postgres 的会话。
我已经四处寻找解决方案并测试了几种不同的选项 - 但没有找到任何地方。我在别处阅读了有关从 Postgres 中删除空闲连接的 cron 作业，但我真的不想在生产中这样做，而是希望 PgBouncer 完全清除这些空闲连接。
我们使用的是 Postgres 9.6 并使用 PgBouncer 1.15 版
感谢任何帮助。
/**
应该在原始评论中指出这一点 - 我们有多个 PgBouncer 正在运行，我们正在使用 Unix Sockets 来做到这一点。我们不确定这是否会对 Postgres 留下连接产生影响。
**/
谢谢
解决方法
问题已解决。
应用程序非常健谈，即使将 server_idle_timeout 设置为低至 5 秒，连接也没有在 Postgres 端回收。
我们遇到的问题是当我们认为 server_lifetime 处于活动状态时不小心被评论了，一旦我们改变它，我们可以清楚地看到 Postgres 连接每 2 分钟被回收一次（基于我们的设置）。
随着时间的推移，每个连接的内存增加，特别是对于长期连接，只考虑了私有内存，而不是共享内存。我们观察到连接存活的时间越长，它消耗的内存就越多。我们尝试为 reset_query 设置 DISCARD ALL 之类的东西，它对内存消耗没有影响。根据我的在线研究，我们并不是唯一面临池化连接挑战的人。
感谢您的评论和帮助。我们最终的解决方案是利用 pgBouncer 中的 server_lifetime 来控制 Postgres 上的长期连接数。
-玛雅