PostgreSQL 连接数打满怎么办：pgbench 实测直连、每次新建连接与 PgBouncer 事务池

A 是应用最理想的状态：20 个长连接一直复用。B 模拟「每个请求开一个连接、用完就关」，这在 PHP、Serverless 函数和没配连接池的脚本里很常见。C、D 分别是经 PgBouncer 的短连接和长连接。

B 的平均延迟 58–59 毫秒里，建连就占了约 11.7 毫秒（pgbench 的 average connection time），剩下的是 20 个客户端排队建连造成的等待；真正执行一条主键查询只要 0.1 毫秒左右。

C 组的结果一开始让我以为配置错了：PgBouncer 已经替我保持着到 PG 的服务端连接，客户端每次新连上来只是和 PgBouncer 握手，为什么比直连还慢？

排查思路是做对照：另起一个 PgBouncer，只把 auth_type 从 scram-sha-256 改成 trust（只在本机测试环境这么做），其余完全一样，再跑同样的 -C。结果建连从 15–17 毫秒降到 0.26 毫秒，TPS 从约 250 升到约 1.46–1.49 万。也就是说，在这台机器上一次新建连接的成本几乎全是 SCRAM-SHA-256 的密码推导（客户端和服务端都要做），而 PgBouncer 是单进程的，20 个客户端同时握手就在它这里排队。

结论很朴素：解决「每次请求都建连」，靠的是让应用复用连接（应用内连接池、长连接），而不是在中间加一层代理。PgBouncer 前面如果还是短连接，认证开销一分不少；生产环境也不要为了快去用 trust，正确做法是让应用侧把连接留住。

把客户端数提到 120，超过 max_connections=100。直连两轮都在第 78 个连接（client 77）失败：FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute。意思是普通连接位已经用完，只剩 superuser_reserved_connections 留给超级用户的 3 个；连保留位也用完时才会看到 sorry, too many clients already。pgbench 只要有一个连接失败就整体中止，应用侧则表现为部分请求连不上。

为什么是第 78 个而不是第 98 个？这是我自己踩的坑：前一组测试留下的 20 条 PgBouncer 服务端连接还空闲着（server_idle_timeout 默认 600 秒），它们同样占着 PG 的连接位，100 − 3 − 20 = 77。线上也一样，连接池、监控、定时任务的空闲连接都算数，所以先用只读 SQL 第 2 段看清是谁占着连接，再决定要不要调大 max_connections。

经 PgBouncer 再跑 120 个客户端：两轮零失败，约 6.0 万 / 5.9 万 TPS，平均延迟约 2 毫秒（客户端在 PgBouncer 里排队）。压测进行中用只读 SQL 看 PG 侧，pgbench 的后端连接始终是 20 条（idle 19 + active 1 或 idle 20，取决于采样瞬间）。

transaction 模式下，PgBouncer 只在一个事务结束后才把服务端连接还回池子。我让 20 个客户端经 PgBouncer 各执行 BEGIN 和一条主键查询，然后什么都不做、空闲 12 秒再回滚。3 秒后第 21 个客户端执行最简单的 select 1，两轮分别等了 8.987 秒和 8.999 秒——正好等到前面的事务结束。

这时跑只读 SQL：第 2 段显示 lab / psql / 127.0.0.1 有 20 条连接全部是 idle in transaction；第 4 段逐条列出这 20 个会话，最后一条查询都是 SELECT abalance … ，事务已开约 4 秒。生产上，这通常是代码里开了事务后去调外部接口、或者异常分支没有回滚。