云服务器
在 2 核 4G（2 vCPU, 4GB RAM）的服务器上，PostgreSQL 的最大并发连接数并没有一个固定的“官方上限”，它完全取决于你的配置参数、业务负载类型以及系统资源限制。
不过，基于该硬件配置的实际情况，我们可以从以下几个维度进行推导和估算：
1. 理论上的软性限制
PostgreSQL 本身对最大连接数的限制主要受限于两个参数：
max_connections：数据库层面的逻辑上限。默认值通常为 100。你可以将其设置为任意整数（如 500、1000），甚至更高，只要操作系统允许。- Linux 文件描述符限制 (
ulimit -n)：每个数据库连接本质上是一个文件句柄。默认情况下，Linux 进程通常只能打开 1024 个文件。如果将max_connections设为 2000，但ulimit没改，超过 1024 的连接会直接失败。
结论：仅从软件配置角度，你可以轻松将 max_connections 设置为 3000~5000 甚至更多，但这不代表服务器能处理这么多请求。
2. 硬件资源的硬性瓶颈（核心分析）
在 2 核 4G 的机器上，真正的瓶颈在于内存和CPU，而非 Postgres 本身的代码逻辑。
A. 内存压力 (RAM)
PostgreSQL 是“每连接一进程”或“每连接一线程”架构（取决于版本和配置，但在标准模式下，每个连接都会消耗一定的内存）。
- 共享缓冲区 (
shared_buffers)：建议设置为总内存的 25% 左右，即 1GB。这是必须保留的。 - 其他固定开销：操作系统内核、文件系统缓存等至少占用 500MB – 800MB。
- 剩余可用内存：约 1.5GB – 2GB 可用于动态分配给连接上下文。
- 单连接内存消耗：
- 简单的查询连接可能只需几 MB。
- 复杂的查询、排序、临时表可能会消耗几十 MB。
- PostgreSQL 文档建议保守估计每个连接消耗 5MB – 10MB 内存（包含
work_mem等开销）。 - 计算：$2000 text{MB} / 5 text{MB} = 400$ 个连接；若按 $10 text{MB}$ 算，则只有 200 个连接。
风险：如果你强行开启 1000 个连接，当所有连接同时活跃时，系统会触发 OOM Killer（内存溢出杀手），导致数据库进程被系统强制杀掉，服务中断。
B. CPU 压力 (vCPU)
2 个核心意味着同一时间只能真正并行执行 2 个计算密集型任务。
- 如果是读写混合且计算复杂的业务（如大表 Join、排序），并发数稍高就会导致 CPU 100% 满载，响应时间急剧增加（排队等待）。
- 如果是轻量级业务（如简单的 Key-Value 查询、心跳检测），CPU 可以支撑更高的并发，因为大部分时间是在等待 I/O。
3. 实际场景估算与建议
根据经验数据，针对 2 核 4G 的配置：
| 业务场景 | 推荐最大活跃并发数 | 说明 |
|---|---|---|
| Web 应用后端 | 50 ~ 100 | 大多数 Web 请求是短连接，且会有部分空闲等待。此范围最稳定。 |
| 高并发读/写混合 | 150 ~ 200 | 需要精细调优 work_mem 和 shared_buffers，避免内存交换。 |
| 纯静态读取/简单查询 | 300 ~ 400 | 仅当查询极快且不消耗大量内存时可达，风险较高。 |
| 设置 max_connections | 建议设为 200~300 | 不要直接设到 1000+。应配合连接池使用。 |
4. 关键优化策略
要在 2 核 4G 上跑更多并发，绝对不能依赖 Postgres 原生的高连接数，必须采用以下方案：
-
引入连接池 (Connection Pooling)：这是最关键的一步。
- 使用 PgBouncer 或 ProxySQL。
- 原理：应用程序建立几千个连接，但 PgBouncer 将这些连接复用到后端的几十个物理连接上。
- 效果：你可以让前端有 2000 个客户端连接，但 PostgreSQL 实际只维护 100 个物理连接，从而完美避开内存瓶颈。
-
调整
max_connections：- 将其设置为略高于预期物理并发数（例如 200）。
- 公式参考：
max_connections = (可用内存 - shared_buffers) / (平均单连接内存)。
-
限制
work_mem：- 默认值通常是 4MB。对于小内存机器，建议调低至 1MB – 2MB，防止单个复杂查询吃光内存导致 OOM。
-
调整 Linux 参数：
- 修改
/etc/security/limits.conf，将nofile限制调高（例如 65535），以支持更多的文件句柄。
- 修改
最终结论
在 2 核 4G 的服务器上：
- PostgreSQL 原生物理连接数：安全且稳定的范围建议在 100 ~ 200 之间。超过 300 极易引发内存溢出或 CPU 雪崩。
- 实际支持的客户端并发：通过部署 PgBouncer 等连接池，可以将支持的客户端连接数提升至 1000 ~ 3000 甚至更多，而数据库内部依然保持低负载的物理连接。
建议操作：
不要直接修改 max_connections 为高数值。请安装 PgBouncer，将 PostgreSQL 的 max_connections 限制在 150 左右，并适当降低 work_mem，这样既能保证稳定性，又能支撑较高的外部并发流量。