Postgres 12.7 设置max_worker_processes超CPU核数是否存在风险？

PostgreSQL max_worker_processes 超过CPU核心数的影响说明 #

首先明确结论：你2核的PostgreSQL 12.7实例将max_worker_processes调高到3甚至略高的数值，不存在致命危害，完全可以正常使用。

你之前看到的「max_worker_processes设置为CPU核心数」属于通用性能优化建议，不是不可突破的硬性限制。

这个参数的本质是PostgreSQL后台辅助工作进程的总数量上限，覆盖的进程类型包括并行查询工作进程、逻辑复制工作进程、pg_cron这类扩展的后台调度进程、物理/逻辑备份的工作进程等，不是每个进程都会长期占满1个CPU核心：类似pg_cron的常驻后台进程，大部分时间处于空闲等待状态，CPU占用可以忽略不计。

只有当你把这个参数调得过高（比如2核实例调到10以上）时，才可能出现负面影响：

• 极端高并发场景下如果大量工作进程同时活跃，会导致CPU上下文切换开销飙升，拉低整体数据库性能，小型低负载业务基本不会碰到这个情况
• 每个工作进程会占用固定的少量内存（和shared_buffers等配置相关，通常单进程内存占用在几十MB级别），仅调高1-2个的情况下，内存开销完全可以忽略

针对你的场景，建议直接把max_worker_processes设为4即可：1个给pg_cron使用，剩下3个冗余留给并行查询、临时备份等场景，足够覆盖绝大多数小型数据库的使用需求。后续如果需要开启逻辑复制、多并行度备份等功能，再按需往上调整即可，只要不一次性调到几十的量级，不会引发稳定性问题。

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