2. PostgreSQL 连接模型：进程架构与连接上限

PostgreSQL 采用 “一个客户端连接对应一个操作系统进程” 的经典模型，这与 MySQL 的线程模型、Oracle 的共享服务器模式有本质区别。理解这一模型是后续连接池水位监控与调优的基础。

2.1 进程架构概览

PostgreSQL 启动后，会创建一组常驻后台进程，并在客户端连接时 fork 出独立的 后端进程（Backend Process） 来处理该连接的请求。核心进程包括：

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

当客户端通过 psql、JDBC、ODBC 或任何驱动发起连接时，Postmaster 主进程会 fork() 出一个子进程作为该连接的后端进程。该进程的生命周期与连接完全绑定：

• 连接建立： Postmaster 接受 TCP 连接或 Unix Socket 连接，fork 子进程，子进程继承主进程的共享内存句柄，然后执行身份认证。
• 请求处理： 后端进程读取客户端发送的查询请求，访问共享缓冲区或磁盘，执行计划，返回结果。
• 连接断开： 客户端关闭连接后，后端进程释放私有内存、关闭文件描述符，然后退出。

2.3 连接数上限配置

PostgreSQL 通过 max_connections 参数控制允许的最大客户端连接数。该参数在 postgresql.conf 中设置，修改后需要重启数据库实例生效。

-- 查看当前连接数上限
SHOW max_connections;

-- 查看当前活跃连接数
SELECT count(*) FROM pg_stat_activity;

-- 查看连接详情（排除后台进程）
SELECT pid, usename, application_name, client_addr, state, query
FROM pg_stat_activity
WHERE backend_type = 'client backend';

2.4 连接模型架构图

下图展示了 PostgreSQL 的进程架构与连接模型：

2.5 连接数上限的影响与监控

当连接数接近 max_connections 时，系统会出现以下症状：

• 新连接被拒绝： 客户端收到 FATAL: sorry, too many clients already 错误。
• 内存压力增大： 每个后端进程的私有内存（如 work_mem 排序区、hash_mem_multiplier 哈希区）累加，可能导致 OOM。
• CPU 上下文切换飙升： 大量进程争抢 CPU 时间片，vmstat 中的 cs（context switch）列显著升高。
• 锁竞争加剧： 更多进程同时访问共享缓冲区，LWLock 和 SpinLock 争用增加。

2.6 连接模型与连接池的关系

由于每个连接对应一个独立进程，直接维持大量长连接会消耗大量系统资源。连接池（如 PgBouncer）的核心作用就是 复用后端进程：

• 客户端连接到连接池，连接池内部维护少量到 PostgreSQL 的后端连接。
• 客户端请求结束后，连接池将后端连接归还到池中，而不是关闭进程。
• 这样可以将 max_connections 设置为一个合理的值（如 200），而客户端连接数可以远高于此。