多租户Spring Boot应用PostgreSQL的max_connections最优配置咨询

问题根源 #

你之前遇到的连接耗尽问题，核心是HikariCP连接池配置不合理导致的连接分配失衡，单纯调高max_connections只是临时规避了崩溃，并非根本解决办法。PostgreSQL采用进程模型，每个连接对应一个独立OS进程，过多连接会快速耗尽内存、增加CPU上下文切换开销，反而拖垮整体性能。

连接池与max_connections最优配置 #

当前每个客户应用的HikariCP配置（minimumIdle=5、maximumPoolSize=10）确实冗余，建议调整为：

• 应用端HikariCP：minimumIdle=2，maximumPoolSize=5
  • 理由：多数业务场景下，单个客户的并发数据库请求不会持续维持在10个，5个足够应对常规峰值；最小空闲连接设为2，既避免频繁创建销毁连接的开销，又不会占用过多闲置资源。
• PostgreSQL端max_connections：调回至220左右
  • 理由：按40个客户计算，总连接上限为40×5=200，预留20个连接给管理员维护、监控等操作，既保证业务需求，又避免连接过多导致的性能问题。

硬件搭配建议 #

如果坚持保留max_connections=350，硬件必须升级到以下配置：

• CPU：至少4vCPU（物理核优先），多核心能有效降低大量连接带来的上下文切换开销
• 内存：至少16GB
  • 每个PostgreSQL连接约占用10-15MB私有内存，350个连接需3.5-5.25GB；再加上共享内存（建议设为总内存的1/3，约5GB）、OS及其他进程占用，16GB内存才能避免swap交换。
• 更优选择：先调整连接池配置，再升级到2vCPU+8GB内存，既能满足当前40个客户的需求，又能控制成本。

客户数量增长后的应对策略 #

当客户数据库数量持续增加时，优先采取以下方案：

1. 先优化连接池利用率：监控每个应用的连接实际使用率，如果大量连接长期处于空闲状态，可进一步降低maximumPoolSize至3-4，压缩单客户的连接占用。
2. 拆分PostgreSQL服务器：当连接需求接近当前服务器的合理上限（max_connections=200左右），将客户分组部署到多台PostgreSQL服务器（比如每30个客户一台），避免单节点连接过载。
3. 绝对避免盲目调高max_connections：一旦max_connections超过300，PostgreSQL的性能会明显下降；超过500则极易引发内存耗尽、服务器无响应等严重问题。

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