PostgreSQL14无PGBouncer支撑5000并发连接的配置优化咨询

现有配置可行性判断 #

现有32GB内存、8核CPU的Windows Server 2016配置完全无法支撑5000个连接需求，核心原因如下：

• PostgreSQL采用独立进程模型，每个空连接至少占用2_{3MB内存，仅5000个空连接的基础开销就达到10}15GB，若连接处于活跃状态内存占用还会进一步上涨。
• 当前work_mem配置为1GB，该参数为单连接单次排序/哈希操作可占用的内存上限，单连接可能同时触发多次内存申请，即使只有30个连接同时执行复杂查询，就能打满剩余内存直接触发OOM，导致数据库崩溃。
• 当前max_connections仅配置为1000，远低于5000的需求阈值，且Windows平台下PostgreSQL进程的资源开销高于Linux平台，现有配置的性能冗余完全不足。

关于"设-1支撑无限连接"的问题 #

PostgreSQL不存在类似SQL Server设置-1即可无限制支撑连接的配置，max_connections必须设置为正整数，且该参数受服务器硬件、系统内核限制，盲目调大只会导致数据库无法启动或者运行时崩溃。

无PGBouncer落地调整建议 #

该方案仅适用于5000个连接中绝大多数为空闲连接、活跃连接数不超过CPU核数2~3倍的场景，如果活跃连接数更高，无论如何调整参数都无法规避PostgreSQL进程模型的性能缺陷，最终仍需部署PGBouncer：

• 硬件扩容
  • 内存至少扩容至64GB，推荐128GB，为连接开销、缓存、查询运算留足冗余空间
  • CPU优先升级到16核及以上，降低高连接数下的进程上下文切换开销
• 系统配置调整（Windows Server 2016）
  • 调整系统进程最大句柄数、TCP半开连接数限制，避免系统层面拦截连接请求
  • 关闭Windows自动更新、Defender实时扫描等非必要后台进程，释放系统资源
• PostgreSQL参数调整
  • 修改max_connections = 5000，重启数据库生效
  • 调整shared_buffers为总内存的25%，64GB内存场景下设为16GB，128GB内存场景下设为32GB
  • 大幅下调work_mem到4MB~8MB，避免单个查询占用过多内存
  • maintenance_work_mem可保持1GB或上调到2GB，仅用于建索引、VACUUM等维护操作，不影响日常连接使用
  • 调低idle_in_transaction_session_timeout到30分钟，自动释放长时间未活跃的事务连接，减少资源浪费

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