调大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 <code>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 设低了，而是设高了之后掩盖了连接泄漏、慢查询、内存配置失衡这些本该先解决的问题。
