2. PostgreSQL 连接模型：进程模型与连接管理

PostgreSQL 采用经典的“一个连接对应一个后端进程”的进程模型（Fork-on-Connect）。理解这一模型是掌握连接池水位管理的基础——连接数直接决定了系统进程数，进而影响 CPU、内存和锁资源。

2.1 进程模型架构

PostgreSQL 启动后，主要包含以下三类进程：

• Postmaster（主守护进程）：监听端口、接受新连接、fork 后端进程、管理共享内存。
• Backend Process（后端进程）：每个客户端连接对应一个独立后端进程，负责执行该连接的 SQL 并返回结果。
• Auxiliary Process（辅助进程）：如 WAL Writer、Checkpointer、Autovacuum Launcher 等，负责系统维护。

2.2 每个连接对应一个后端进程

当客户端发起连接请求时，Postmaster 进程会 fork() 出一个新的子进程（Backend Process）专门为该连接服务。这个进程的生命周期与连接完全绑定：

2.3 max_connections 参数的含义

max_connections 是 PostgreSQL 配置文件中最重要的连接限制参数，定义数据库实例允许的最大并发客户端连接数。

• 默认值： 通常为 100（部分发行版为 20~50）。
• 上限： 受操作系统进程数限制（pid_max、nproc）和内存容量制约。
• 修改方式： 需要修改 postgresql.conf 并重启数据库实例。
• 影响范围： 直接影响共享内存中 ProcArray、Lock Table 等结构的大小。

-- 查看当前 max_connections 设置
SHOW max_connections;

-- 查看当前已使用的连接数
SELECT count(*) FROM pg_stat_activity;

-- 查看连接使用率（水位）
SELECT count(*)::float / current_setting('max_connections')::int * 100 AS connection_usage_pct
FROM pg_stat_activity;

2.4 连接数 vs 性能：关键指标

2.5 连接模型对运维的启示

• 连接数 = 进程数：监控连接数就是监控系统进程负载，不能只看 CPU 使用率。
• max_connections 不是越大越好：过大会导致共享内存膨胀、上下文切换剧烈，反而降低吞吐。
• 空闲连接是隐形杀手：大量 idle 连接占用进程槽位和内存，却未产生任何业务价值。
• 连接池是必选项：通过中间层复用后端进程，将有效连接数控制在合理范围。