4核32GB（db.m5.2xlarge）的Postgres正常连接数是多少

100并发连接、CPU利用率约80%的状态不需要立刻开展连接压降优化，先对照实际运行场景判断：

• 如果80%CPU是业务峰值时段的稳定运行值，且没有出现CPU持续跑满95%以上、慢查询占比陡增、连接等待队列堆积、业务请求超时的问题，这个负载属于健康区间：对线上数据库来说，稳态CPU保持在70%-85%是资源性价比最高的状态，既没有算力闲置，也留足了应对流量突增的冗余。
• 如果80%CPU是非业务峰值的常态值，且监控显示CPU开销里上下文切换占比超过15%、存在大量长时间空闲的无效连接、简单查询响应时间比低负载时高30%以上，才需要排查连接配置问题，针对性做压降。

以下为主流OLTP数据库（MySQL InnoDB、PostgreSQL）在生产环境的实测合理区间，注意不是数据库max_connections参数的配置上限，是实际承载业务请求的有效并发连接数：

• 2核4G规格：稳态合理区间15-30，峰值突发不建议超过50，对应峰值CPU控制在80%左右
• 4核8G规格：稳态合理区间30-60，峰值突发不建议超过100
• 8核16G规格：稳态合理区间60-120，峰值突发不建议超过200
• 16核32G规格：稳态合理区间120-200，峰值突发不建议超过350

上述数值为通用场景参考，实际阈值要根据业务特性调整：如果业务以简单主键查询为主、应用侧配置了合理的连接池做连接复用，阈值可以上浮30%；如果业务多为多表关联的复杂分析查询、未做连接池管理，阈值需要下浮40%。

不要单纯按CPU核数做线性外推，先给系统进程、运维监控组件预留10%-15%的CPU冗余，再结合业务实际的单连接CPU消耗计算，公式如下：
合理稳态连接数 = (实例总CPU核数 * 0.85) / 单连接平均CPU占用
举个实际计算示例：8核16G实例上，单连接承载业务请求的平均CPU占用为0.05核，代入计算可得合理稳态连接数为(8*0.85)/0.05=136，和前面给出的参考区间匹配。如果按你当前实例的单连接CPU消耗计算，100连接对应的CPU负载在预留阈值内，就完全不需要做调整。

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