单机 PostgreSQL 在 2C4G 云主机上的参数调优与冷备恢复演练

对于个人项目与中小型业务系统，在 2 核 4G 云服务器上自建单实例 PostgreSQL 往往比单独采购托管数据库节省不少预算。但 PostgreSQL 出厂默认参数非常保守（例如默认 shared_buffers 仅 128MB），直接上线无法发挥云硬盘与多核性能；而盲目调大内存参数又可能引发主机 OOM。本文整理一套稳健的 2C4G 调优与备份方案。

一、核心内存参数按比例切分

假设 2 核 4G 云主机上同时运行应用容器与 PostgreSQL，建议为数据库预留约 2GB 至 2.5GB 内存上限。在此前提下，shared_buffers 可设为 512MB 至 768MB（约占分配给数据库内存的四分之一），effective_cache_size 设为 1536MB，提示查询优化器充分利用操作系统页缓存，从而更积极地选择索引扫描。

极易踩坑的参数是 work_mem：它并非全局上限，而是每个连接在每次排序或哈希连接操作时都可能单独申请的内存块。若 max_connections 设为 100 且 work_mem 盲目设为 64MB，高并发复杂查询瞬间就会耗尽数 GB 内存。在 2C4G 机器上建议将 work_mem 保守控制在 4MB 至 8MB，而针对建索引与 VACUUM 的 maintenance_work_mem 则可放心设为 128MB 至 256MB。

二、适配云端 SSD 的寻道代价与连接数收敛

PostgreSQL 默认的 random_page_cost 为 4.0，这是机械硬盘时代的经验值。在华为云 GPSSD 等云盘环境下，随机读性能远好于传统磁盘，建议将 random_page_cost 下调至 1.1 到 1.3，避免优化器在明明走索引更快时误选全表顺序扫描。

同时建议将 max_connections 收敛在 50 至 80 之间。若上层采用多进程或 Serverless 架构，务必前置轻量级的 PgBouncer 采用 transaction 池化模式复用连接，避免空闲后端进程消耗内存与上下文切换。

三、没有经过恢复演练的备份等于零

单机自建数据库最核心的风险点在于磁盘单点故障或误删数据，必须建立异机冷备闭环。推荐通过定时脚本每日凌晨执行 pg_dump -Fc 输出自定义压缩格式归档（自带目录索引且支持按表选择性恢复），校验归档文件非空并计算 SHA256 后，立即加密上传至对象存储（OBS），本地仅保留最近 7 天副本，对象存储通过生命周期规则自动清理 30 天前历史包。

更重要的是每季度至少在临时容器里执行一次 pg_restore 实测恢复，验证备份文件完整性、扩展插件依赖以及恢复耗时，确保真正遇到故障时心中有数。

四、总结

在 2C4G 云主机上跑稳 PostgreSQL 的关键是克制连接数、精细限制单次查询内存、对齐 SSD 成本模型，并用自动化异地冷备加上定期恢复演练兜住数据安全底线。