云服务器
PostgreSQL 在 2核4G 内存的服务器上能支持的最大并发连接数并没有一个固定的数值，它取决于多个因素，包括：
- 应用负载类型（读多写少？复杂查询？简单 CRUD？）
- 查询复杂度和执行时间
- 是否使用连接池
- PostgreSQL 配置参数（如
max_connections、内存相关参数） - 操作系统资源限制
但我们可以从硬件和配置角度进行合理估算。
1. 理论最大连接数（由配置决定）
PostgreSQL 默认的 max_connections 是 100。你可以修改 postgresql.conf 文件来调整这个值：
max_connections = 100 # 可以设为 200、300 等，但受限于内存理论上你可以设置到几百甚至上千，但在 2核4G 的机器上，实际可行值远低于理论值。
2. 内存限制是关键
每个 PostgreSQL 连接会消耗一定的内存，主要包括：
- 后端进程（每个连接一个 backend process）：约 5–10 MB 内存（含共享内存 + 私有内存）
work_mem：每查询使用，例如默认 4MB，复杂查询可能多次使用maintenance_work_mem、shared_buffers等也影响整体内存使用
示例估算：
假设：
max_connections = 100- 每个连接平均消耗 10 MB 内存
- 总连接内存：100 × 10 MB = 1 GB
- 加上 shared_buffers（建议 1GB 左右）、操作系统和其他开销
在 4GB 内存下，100 个并发连接已经接近极限，如果每个连接执行复杂查询（大量使用 work_mem），可能几十个连接就会导致内存耗尽或频繁 swap，性能急剧下降。
3. CPU 限制
2 核 CPU 意味着最多同时运行 2 个进程（不考虑超线程）。当并发连接数超过 CPU 处理能力时，会产生排队，响应变慢。
- 如果每个查询很轻量（如简单索引查询），可能支持 50~100 个活跃连接。
- 如果查询复杂或有锁竞争，超过 20~30 个活跃连接就可能出现瓶颈。
4. 实际建议
| 场景 | 建议最大并发连接数 |
|---|---|
| 轻量 Web 应用（如博客、小 API） | 50～100（配合连接池） |
| 中等负载应用 | 30～50 |
| 复杂查询或 OLAP 类型 | ≤ 20 |
⚠️ 注意：这里的“并发连接”指的是数据库层面的连接数。实际应用中应使用 连接池（如 PgBouncer、PgPool-II）来限制真正连接到 PostgreSQL 的数量，比如只允许 20 个真实连接，但对外支持数百个应用连接。
5. 推荐配置（2核4G）
# postgresql.conf
max_connections = 100
shared_buffers = 1GB
work_mem = 4MB ~ 8MB # 避免过高，防止内存爆炸
maintenance_work_mem = 256MB
effective_cache_size = 2GB
# 使用连接池时可降低 max_connections 到 50 或更少搭配 PgBouncer（最常用）将实际连接数控制在 20~30。
结论
📌 在 2核4G 的服务器上：
- PostgreSQL 最大配置连接数：可设为 100
- 实际稳定支持的并发连接（活跃）：建议控制在 20～50
- 使用连接池后，可支撑的应用并发更高（如数百 HTTP 请求），但数据库后端连接保持精简
✅ 最佳实践：使用 PgBouncer，设置后端连接数为 20~30，前端连接可更多。
这样既能充分利用资源，又能避免内存耗尽和性能下降。