云服务器
在 1 核 2G 内存的 Linux 服务器上部署 PostgreSQL，结论是：勉强够用，但仅限于极低负载或开发/测试环境。如果是生产环境且业务有增长预期，这个配置风险较大。
以下是针对该配置的详细分析和优化建议：
1. 核心瓶颈分析
PostgreSQL 对内存非常敏感，尤其是共享缓冲区（Shared Buffers）和连接管理。
- 内存压力（2GB）：
- 系统开销：Linux 内核本身、文件系统缓存、以及运行其他守护进程（如 SSH、监控 agent）会占用约 300MB-500MB。
- PostgreSQL 默认设置：PG 启动时会自动计算
shared_buffers（通常为物理内存的 25%）。在 2GB 机器上，这约为 512MB。 - 剩余可用内存：扣除系统后，留给 PG 的剩余内存可能只有 1GB 左右。如果并发连接数稍多，或者查询涉及大量排序（Sort）、哈希表（Hash Join），很容易触发 OOM Killer（内存溢出杀手），导致数据库进程被系统强制杀死，服务中断。
- CPU 性能（1 核）：
- 单核意味着所有查询串行执行。如果有多个用户同时发起复杂查询（如全表扫描、大事务），响应时间会急剧上升，甚至出现“假死”状态。
- 对于简单的 CRUD（增删改查）或读写分离场景尚可，但无法处理高并发。
2. 适用场景 vs 不适用场景
| 场景类型 | 是否推荐 | 说明 |
|---|---|---|
| 本地开发 / 测试环境 | ✅ 推荐 | 只要不跑复杂的压测脚本，日常调试完全没问题。 |
| 个人博客 / 静态展示站 | ⚠️ 勉强可行 | 仅作为 CMS（如 WordPress）的后端，且访问量极低（日均 PV < 1000）。 |
| 小型内部工具 / 报表系统 | ❌ 不推荐 | 查询逻辑复杂，容易卡顿；单核无法支撑多用户并发。 |
| 生产环境 (Production) | ❌ 强烈不建议 | 缺乏容错率，一旦流量波动或发生慢查询，极易宕机。 |
| 高并发 API 服务 | ❌ 绝对不可用 | 1 核 CPU 瞬间就会饱和，2G 内存会导致频繁 Swap 交换，性能雪崩。 |
3. 如果必须使用此配置，如何优化？
如果你受限于预算或硬件资源，必须使用 1C2G 部署，请务必进行以下调优以保命：
A. 修改 postgresql.conf 关键参数
不要使用默认值，需手动限制内存占用：
# 1. 限制共享缓冲区，防止吃光内存 (设为 256MB 或 384MB)
shared_buffers = 256MB
# 2. 减少最大连接数 (默认 100，建议设为 20-30)
max_connections = 20
# 3. 降低临时文件内存使用，避免排序时爆内存
work_mem = 4MB # 每个操作使用的内存，越小越安全
maintenance_work_mem = 32MB
# 4. 开启自动调整 (可选，但在低配机器上需谨慎)
effective_cache_size = 512MB
# 5. 关闭不必要的功能
autovacuum = on # 保持开启，但需配合 autovacuum_naptime 调整B. 操作系统层面优化
- 禁用 Swap 或谨慎使用：虽然 Swap 能防止 OOM，但在 1 核机器上，Swap 会导致磁盘 I/O 成为瓶颈，让系统变得极慢。如果必须开 Swap，请确保磁盘是 SSD。
- 使用轻量级 OS：安装 Alpine Linux 或精简版的 Debian/CentOS，减少系统基础内存占用。
- 禁止其他服务：移除服务器上的 Docker、Redis、Nginx 等额外组件，尽量让 PG 独占资源。
C. 应用层策略
- 连接池：务必在应用层（如 Java Spring, Go, Node.js）使用连接池（如 PgBouncer），将应用端的长连接转换为短连接，避免耗尽
max_connections。 - 索引优化：严格检查 SQL 语句，确保所有查询都走索引，杜绝全表扫描（Full Table Scan）。
- 定期清理：建立严格的定时任务清理日志和历史数据。
4. 最终建议
- 如果是新项目上线：建议至少升级到 2 核 4G 的配置。PostgreSQL 在 4G 内存下表现会有质的飞跃（
shared_buffers可达 1GB，足以缓存热点数据），且双核能更好地应对并发。 - 如果是旧项目迁移：先进行详细的慢查询分析（Slow Query Log），优化 SQL 和执行计划。如果优化后仍不稳定，必须扩容。
- 云厂商方案：如果无法升级实例，可以考虑将数据库独立部署（即使是最小的规格），与应用服务器分离，避免资源争抢。
总结：1 核 2G 是 PostgreSQL 的“生存线”，不是“舒适区”。仅适合学习、开发或极低流量的边缘业务，切勿用于承载重要生产数据。