PostgreSQL max_connections 调大后的共享内存与 OOM 风险

调大max_connections会导致共享内存暴涨，因其线性增加ProcArray、LockManager等结构的预分配空间，需同步调高kernel.shmmax、shmall和kernel.sem参数，否则启动失败；同时活跃连接增多易触发OOM Killer杀postgres进程。

max_connections 调大后为什么共享内存会暴涨

postgresql 每个连接都会独占一份 Backend 结构体，同时为每个连接预留共享内存区域（如 shared_buffers 不参与此部分，但 max_connections 会直接影响 semaphores、shmem 中的锁结构和进程间通信空间）。更关键的是，max_connections 直接决定 PostgreSQL 启动时预分配的共享内存段大小 —— 尤其是 ProcArray、LockManager、BackendStatus 等结构，它们都按连接数线性扩容。

典型表现：从 100 调到 1000，仅共享内存（SHMMAX）需求可能翻 3–5 倍，而系统默认的 /proc/sys/kernel/shmmax 往往远低于这个值，导致启动失败并报错：could not create shared memory segment: Invalid argument。

linux 共享内存参数必须同步调高

PostgreSQL 启动前会检查内核共享内存限制，不满足就拒绝启动。不能只改 postgresql.conf 里的 max_connections。

• kernel.shmmax：单个共享内存段最大字节数，建议 ≥ 实际所需 SHM 总量 × 1.2（可通过 pg_controldata 或 postgres -D $PGDATA -C shared_buffers 估算）
• kernel.shmall：系统级总页数限制，单位是页（通常 4KB），需 ≥ shmmax / 4096
• kernel.sem：信号量数组，格式为 SEMMSL SEMMNS SEMOPM SEMMNI，其中 SEMMNS 必须 ≥ max_connections × 2（保守起见再 ×1.5）

修改后需执行 sysctl -p 生效，且要写入 /etc/sysctl.conf 防重启丢失。

OOM Killer 在连接数激增时真会杀 PostgreSQL 进程

共享内存本身不计入 MemAvailable，但每个活跃连接的本地内存（work_mem、temp_buffers、客户端协议缓冲区等）全算作进程 RSS。当大量连接并发执行复杂查询，work_mem × active_connections 可轻松突破物理内存上限。

此时 Linux OOM Killer 会扫描进程得分（oom_score_adj），而 postgres 主进程因常驻且内存占用高，极易被选中 —— 日志里出现 Killed process postgres (pid XXXX) total-vm:XXXXkB, anon-rss:XXXXkB, file-rss:0kB 就是铁证。

• 别依赖 work_mem 默认值（通常 4MB），连接数 > 200 时建议压到 1MB 或更低
• 用 pg_stat_activity 监控 backend_type = 'client backend' 且 state = 'active' 的数量，比 max_connections 更反映真实压力
• shared_preload_libraries = 'pg_stat_statements' + 定期查 pg_stat_statements，揪出内存“黑洞”SQL

真正安全的扩容路径不是只调 max_connections

盲目调高 max_connections 是最省事也最危险的做法。PostgreSQL 的连接成本远高于 mysql，它的连接模型天然不适合“连接池透明透传”式滥用。

• 优先上连接池：pgbouncer（transaction 模式）或 pgpool-II，把 max_connections 控制在 200–400，让池子管住实际后端连接数
• 应用层控制：http 服务用 keepalive 复用连接；ORM 设置合理 idle timeout 和 max pool size
• 监控硬指标：除了 max_connections，盯死 shared_memory_bytes（来自 pg_postmaster_start_time() 推算）、pg_stat_bgwriter 中的 checkpoints_timed 是否频繁触发（说明 shared_buffers 压力过大）

很多线上事故不是因为 max_connections 设低了，而是设高了之后掩盖了连接泄漏、慢查询、内存配置失衡这些本该先解决的问题。