pgBouncer配置调整推荐公式及Moodle场景配置优化咨询

• pool_mode配置不合理：你当前使用的session模式是pgBouncer效率最低的池化模式，只有客户端断开连接才会释放后端数据库连接，完全没有发挥连接池的复用优势，相当于加了pgBouncer还是要占用同等数量的后端数据库连接。Moodle官方已经适配pgBouncer的transaction模式，只需要在Moodle的config.php中添加$CFG->dboptions['persistent'] = false;关闭持久连接即可，切换为transaction模式后，后端数据库连接可以在不同客户端请求之间复用，通常几十条后端连接就能支撑数千级的客户端请求。
• default_pool_size配置不合理：你当前将该值设为600完全对齐PostgreSQL的max_connections，但是该参数不适合设置这么高：PostgreSQL是进程模型，8核32G实例的最佳活跃连接数为CPU核心数的2_{4倍，也就是16}32条，开600条后端连接会导致数据库上下文切换开销飙升，性能反而大幅下降。如果切换为transaction模式，default_pool_size设置为20~30就足够支撑800+人的测验场景。
• 未配套调整系统文件句柄限制：日志中的ERROR accept() failed: Too many open files报错，是因为pgBouncer进程的文件句柄上限不足：pgBouncer每条连接（客户端连接+后端数据库连接）都需要占用一个文件句柄，你设置了max_client_conn=5000，再加上后端连接的数量，至少需要给pgBouncer进程开放10240以上的文件句柄上限。你看到的no more connections allowed (max_client_conn)报错本质是文件句柄占满后pgBouncer无法接收新连接，并不是max_client_conn设置过小导致的。
• 未启用储备池配置：建议将reserve_pool_size设置为default_pool_size的10%（也就是2~3），reserve_pool_timeout保持默认5秒，用于应对峰值时的突发连接排队场景。

现有资源配置完全可以支撑业务需求，不需要升配：

• 8核32G的Cloud SQL实例，只要将pgBouncer的pool_mode切换为transaction模式，后端活跃连接数控制在30以内，CPU、内存资源都会有大量富余，完全能支撑单场867人的测验需求。
• 运行pgBouncer的16核64G虚拟机配置冗余度很高，只需要调整系统的文件句柄上限即可，不需要升级规格。

• max_client_conn：按照业务峰值并发客户端请求数的1.2~1.5倍设置即可，你的场景峰值并发请求不会超过2000，设置为3000足够，不需要设到5000。
• default_pool_size：如果使用transaction模式，按照「数据库CPU核心数 * 2 ~ 数据库CPU核心数 *4」设置即可；只有使用session模式时才需要按照峰值业务需要的后端连接数设置，非常不推荐使用session模式。
• max_db_connections：可以设置为比default_pool_size高20%左右，预留部分连接给数据库管理操作。
• 系统文件句柄上限：至少要设置为「max_client_conn + default_pool_size * 2」的1.5倍以上，避免出现too many open files报错。

1. 先修改Moodle配置文件config.php，添加$CFG->dboptions['persistent'] = false;，关闭数据库持久连接。
2. 修改pgBouncer核心配置：pool_mode = transaction，default_pool_size = 25，reserve_pool_size = 3。
3. 调整系统文件句柄限制：编辑/etc/security/limits.conf，添加两行配置：pgbouncer soft nofile 65535、pgbouncer hard nofile 65535，重启pgBouncer进程生效。
4. 先发起小规模测验做压测，执行pgBouncer管理命令show pools查看运行状态，确认后端连接数稳定在20~30之间没有溢出现象即可正式使用。

内容的提问来源于stack exchange，提问作者realnsleo