2. PostgreSQL连接模型：Postmaster/Backend进程模型与开销分析
PostgreSQL采用经典的多进程架构，与MySQL的线程模型或Oracle的共享服务器模式有本质区别。理解这一模型是配置连接池参数的前提——连接池本质上是在规避原生进程模型在高并发下的固有开销。
2.1 进程模型核心结构
PostgreSQL的进程模型由两类核心进程组成：
- Postmaster（主守护进程）：系统启动时第一个进程，负责监听端口、接受新连接请求、fork子进程、管理共享内存、执行崩溃恢复等。
- Backend（后端进程）：每个客户端连接对应一个独立的PostgreSQL后端进程，由Postmaster fork产生，负责处理该连接的所有SQL请求，直到连接断开后退出。
关键认知： PostgreSQL中“一个连接 = 一个进程”是硬约束。连接池无法改变这一底层模型，只能通过复用连接来减少进程创建/销毁的频率。
2.2 每个连接对应一个进程的开销分析
当客户端发起连接时，Postmaster 执行 fork() 系统调用创建一个子进程。这个操作带来的开销是多维度的：
| 开销维度 | 具体表现 | 量化参考 |
|---|---|---|
| 进程创建开销 | fork() 需要复制父进程的页表、文件描述符表、信号处理设置等；PostgreSQL 还会立即执行子进程初始化（加载GUC参数、分配本地内存）。 | 每次连接建立耗时约 1~5ms（取决于系统负载和内存大小） |
| 内存开销 | 每个 Backend 进程独立占用私有内存：包括 work_mem、hash_mem_multiplier、本地排序缓冲区等。即使空闲连接也占用这部分内存。 | 每个空闲连接约占用 5~10 MB；活跃连接可能占用 50~200 MB+ |
| 上下文切换开销 | 当活跃连接数超过 CPU 核心数时，操作系统需要在大量进程间频繁切换，导致 TLB 失效、缓存污染。 | 连接数 > 2×CPU核心数时，切换开销显著上升 |
| 锁竞争开销 | 所有 Backend 进程共享同一份共享内存（缓冲池、WAL缓冲区），大量进程并发访问时，LWLock 和 SpinLock 竞争加剧。 | 连接数 > 200 时，锁等待时间可能占查询时间的 30%+ |
| 连接建立网络开销 | TCP 三次握手、SSL/TLS 握手（如果启用）、认证交换（md5/scram）等网络往返。 | 本地连接约 0.5~2ms；远程连接可达 10~50ms |
性能陷阱： 很多DBA只关注内存开销，却忽略了上下文切换和锁竞争这两个隐性杀手。当连接数达到 500~1000 时，即使内存充足，CPU 也会因大量进程切换而飙升，吞吐量反而下降。
2.3 进程模型 vs 线程模型：关键差异
理解 PostgreSQL 为什么坚持进程模型，有助于在连接池选型时做出正确决策：
| 对比维度 | PostgreSQL（进程模型） | MySQL / Oracle（线程模型） |
|---|---|---|
| 隔离性 | 进程级隔离，一个 Backend 崩溃不影响其他连接 | 线程共享地址空间，一个线程崩溃可能导致整个实例宕机 |
| 内存共享 | 通过共享内存（System V / POSIX）显式共享 | 线程天然共享堆内存，但需要更复杂的同步机制 |
| 扩展性上限 | 受限于进程数（通常建议 < 500 活跃连接） | 可支持数千并发线程 |
| 上下文切换 | 进程切换开销高于线程切换（页表切换） | 线程切换较轻量（共享地址空间） |
| 安全性 | 操作系统级进程隔离，更安全 | 线程间共享内存，存在数据竞争风险 |
2.4 连接数增长时的性能退化曲线
以下是一个典型 PostgreSQL 实例在连接数增长时的吞吐量变化趋势：
实践建议： 从曲线可以看出，当连接数超过 200 后，吞吐量开始明显下降。这也是为什么生产环境中建议将活跃连接数控制在 CPU 核心数的 2~3 倍以内，并通过连接池（如 PgBouncer、Pgpool-II）将前端大量连接转化为少量后端连接。
2.5 连接池如何缓解进程模型开销
连接池的核心价值在于：用少量持久化的后端进程，服务大量短时前端连接。具体缓解机制如下：
- 消除 fork 开销：连接池预先创建一组 Backend 进程并保持存活，新客户端连接直接复用已有进程，无需执行 fork()。
- 降低内存占用：空闲连接在连接池中被回收，后端进程数保持稳定，不会随前端连接数线性增长。
- 减少上下文切换：后端进程数可控（通常 50~200），操作系统调度压力大幅降低。
- 缓解锁竞争：更少的后端进程意味着更少的并发访问共享内存，LWLock 争用显著减少。
核心结论： PostgreSQL 的进程模型在低并发（<100 连接）时表现优异，隔离性好、稳定性高；但在高并发（>500 连接）时，进程创建开销、内存占用和上下文切换成为瓶颈。连接池正是为了弥补这一短板而存在的关键组件。