PostgreSQL连接占用大量内存的根本原因是其“每个连接一个进程”的模型，每个连接由独立操作系统进程处理并独占内存资源，导致连接数增加时内存消耗线性上升。该设计虽提升稳定性与隔离性，但进程间不共享内存，单连接基础开销达几MB至十几MB，叠加work_mem等动态分配后，高并发下易引发OOM和性能下降。例如500连接可致30GB以上内存需求。优化关键在于控制连接数：使用PgBouncer或PgPool-II等连接池减少后端进程，合理设置max_connections、work_mem及超时参数，避免直接暴露数据库于大量短连接。生产环境必须依赖连接池缓解内存压力。
PostgreSQL 连接占用大量内存，根本原因在于其进程级的连接模型。每个客户端连接都会由数据库服务器派生一个独立的操作系统进程来处理，这个进程在生命周期内会分配相对固定的内存资源，导致连接数上升时内存消耗线性增长。
PostgreSQL 的进程模型
与 MySQL 等使用线程模型的数据库不同，PostgreSQL 采用的是“每个连接一个进程”（one process per connection）的设计：
- 每当有新连接建立，PostgreSQL 主进程（postmaster）会 fork 出一个专用的后端进程处理该连接
- 该进程独占一定量的内存，包括本地缓冲区、查询执行上下文、事务状态等
- 进程之间不共享内存空间，无法像线程那样共用堆内存，因此开销更大
这种设计提升了稳定性和隔离性——一个连接崩溃不会直接影响其他连接，但也带来了更高的资源成本。
单连接内存开销构成
每个 PostgreSQL 后端进程的内存使用主要包括以下几个部分：
- shared_buffers：共享内存区域，所有进程共用，不随连接数增加而增加
- work_mem：用于排序、哈希表、位图操作等，每次需要时按需分配，复杂查询可能多次使用
- maintenance_work_mem：用于 VACUUM、CREATE INDEX 等维护操作，仅在特定操作时启用
- temp_buffers：临时表使用的缓冲区，每个会话独立分配
- 会话级上下文：保存会话变量、权限信息、打开的游标等
其中 work_mem 是最容易被低估的部分。如果设置为 64MB，一个复杂查询中执行多个排序或哈希连接，可能会分配数倍于此的内存。100 个并发连接下，峰值内存可能额外增加数十 GB。
连接膨胀带来的问题
当应用未使用连接池，或连接池配置过大时，容易出现连接数激增：
- 每个连接即使空闲，其进程仍保留在内存中，持续占用基础内存（约几 MB 到十几 MB）
- 高并发下多个查询同时执行，work_mem 叠加效应显著，极易触发 OOM
- 操作系统进程调度开销增大，CPU 上下文切换频繁，整体性能下降
例如：500 个连接，每个平均消耗 10MB 基础内存 + 查询时动态使用 50MB，总内存需求可达 30GB 以上，远超预期。
优化建议：控制连接数量
最有效的办法不是调低内存参数，而是减少实际连接数：
- 使用连接池中间件，如 PgBouncer 或 PgPool-II，将大量应用连接映射到少量后端连接
- 设置合理的最大连接数（max_connections），避免无限制增长
- 监控空闲连接，通过 idle_in_transaction_session_timeout 终止长时间空闲事务
- 调整 work_mem 按需设置，避免全局设得过高，可对特定操作单独调整
PgBouncer 在“会话模式”或“事务模式”下能极大压缩后端进程数量，是生产环境推荐方案。
基本上就这些。PostgreSQL 的进程模型决定了它不适合直接承载大量短连接，必须依赖连接池来缓解内存压力。理解这一点，才能合理规划架构和资源配置。
