云服务器
在 1核2G（1 vCPU, 2GB RAM）这种资源非常受限的环境下运行 PostgreSQL，核心原则是：保守使用内存，避免 Swap，确保稳定性优先于性能。
以下是针对该配置的关键优化建议，按重要性排序：
🔧 一、核心参数调整（postgresql.conf）
1. shared_buffers
- 推荐值：
256MB~384MB - 说明：PostgreSQL 默认可能设为物理内存的 25%（即 512MB），但在 1C2G 下太高会导致系统频繁 Swap。
- 建议：设置为总内存的 10%~15%，预留足够空间给 OS 和其他进程。
2. work_mem
- 推荐值：
4MB~8MB - 说明：每个排序或哈希操作使用的内存。切勿设高！如果并发查询多，容易 OOM（Out of Memory）。
- 计算逻辑：
可用内存 ≈ 2GB - shared_buffers(256MB) - OS预留(512MB) = ~1.2GB work_mem ≤ (可用内存 / 最大并发连接数) × 0.5假设最大连接数为 20，则
work_mem = 1200MB / 20 / 2 ≈ 30MB，但为安全起见，建议从 4MB 起步测试。
3. maintenance_work_mem
- 推荐值：
64MB~128MB - 说明：用于 VACUUM、CREATE INDEX 等维护操作。设置过高无益，反而浪费内存。
4. effective_cache_size
- 推荐值：
768MB~1GB - 说明：告诉优化器有多少内存可用于缓存数据（包括 OS 页面缓存）。设为可用内存的 50%~75%，帮助优化器选择更优的执行计划。
5. max_connections
- 推荐值：
20~50 - 说明：每个连接至少占用几 MB 内存。1C2G 不适合高并发直连，建议通过 PgBouncer 等连接池管理。
6. wal_buffers
- 推荐值：
16MB - 说明：预写日志缓冲区，一般不需要太大。
7. checkpoint_completion_target
- 推荐值：
0.9 - 说明：减少 I/O 峰值，使检查点更平滑。
8. random_page_cost
- 推荐值：
1.1~1.5（如果使用 SSD/NVMe） - 说明：默认 4.0 是针对 HDD 的。SSD 上随机读取代价低，调低可让优化器更倾向索引扫描。
🛡️ 二、操作系统级优化
1. 禁用或限制 Swap
- 强烈建议：直接禁用 Swap，或设置极小 Swap + 高 swappiness。
- 原因：Swap 会极大降低数据库性能，且可能导致不可预测的行为。
- 操作：
# 查看当前 swappiness cat /proc/sys/vm/swappiness # 临时设置为 1（几乎不用 swap） sysctl vm.swappiness=1
2. 增加文件描述符限制
- PostgreSQL 在高并发时容易达到 Linux 默认的
ulimit -n（通常 1024）。 - 操作：
# /etc/security/limits.conf postgres soft nofile 65536 postgres hard nofile 65536并重启会话生效。
3. 文件系统选择
- 推荐使用 ext4 或 xfs，挂载选项中加入
noatime以减少不必要的元数据写入：mount -o remount,noatime /data
📊 三、架构与运维建议
1. 使用连接池（PgBouncer）
- 1C2G 服务器无法承受大量直连连接。
- 部署 PgBouncer 作为X_X，将应用层的数百个连接合并为少量后端连接（如 10~20 个）。
- 模式推荐：
transaction模式，平衡性能与安全性。
2. 定期 VACUUM 和 ANALYZE
- 启用自动 vacuum：
autovacuum = on autovacuum_max_workers = 1 - 手动执行
ANALYZE;更新统计信息，确保查询计划准确。
3. 监控与告警
- 安装轻量级监控工具（如
pg_stat_statements扩展）跟踪慢查询。 - 关注内存使用率，若接近 1.8GB，立即排查是否有内存泄漏或过大查询。
4. 备份策略
- 使用
pg_basebackup+ WAL 归档进行连续归档备份。 - 注意：备份过程也会消耗 CPU 和 I/O，建议在低峰期执行。
✅ 四、验证是否生效
启动后，登录 psql 执行以下命令检查关键参数：
SHOW shared_buffers;
SHOW work_mem;
SHOW effective_cache_size;
SHOW max_connections;
SHOW random_page_cost;同时观察系统状态：
free -h # 确认内存未被 swap 耗尽
top # 观察 PostgreSQL 进程内存占用⚠️ 五、注意事项
- 不要追求极致性能：1C2G 仅适合小型项目、开发测试环境或极低并发生产场景。
- 避免复杂查询：大表 JOIN、未加索引的排序、子查询等在低配服务器上极易导致超时或崩溃。
- 考虑升级：如果业务增长，建议尽快升级到 2C4G 或更高配置，这是最具性价比的X_X。
通过以上优化，你可以在 1C2G 服务器上稳定运行 PostgreSQL，满足轻量级应用需求。