PostgreSQL 13频繁进入恢复模式问题求助及参数调整咨询

问题对应用的重大影响 #

• 数据库进程被系统OOM杀死后会触发崩溃恢复，恢复期间数据库处于只读状态，应用无法执行写操作，部分读请求也会失败，直接导致业务中断；
• 频繁的崩溃恢复会额外消耗系统IO和CPU资源，可能引发更严重的性能退化，甚至存在数据文件损坏的风险；
• postmaster.pid文件变更说明数据库主进程已重启，所有现有连接会被强制断开，应用会出现大量连接失败、事务中断的情况，破坏业务数据一致性，影响用户体验。

参数调整建议 #

1. 降低最大连接数（max_connections） #

当前设置为400，远超16GB内存的承载能力——每个PostgreSQL连接的基础内存占用约40-60MB，400个连接仅基础内存就会耗尽甚至超出总内存，直接触发OOM。建议调整为：

ALTER SYSTEM SET max_connections = '150';

若应用连接需求较高，建议搭配PgBouncer连接池，通过复用连接减少实际数据库连接数。

2. 优化work_mem参数 #

当前work_mem设为6MB，但每个排序、哈希操作都会单独分配该内存，高并发场景下内存占用会快速累积。建议下调至更保守的值：

ALTER SYSTEM SET work_mem = '4MB';

可临时开启log_temp_files = '0'监控临时文件生成情况，若出现大量大尺寸临时文件，再根据实际场景微调work_mem。

3. 调整并行查询参数 #

当前max_parallel_workers_per_gather设为4，与CPU核心数一致，高负载时并行查询会耗尽CPU和内存资源，建议降低：

ALTER SYSTEM SET max_parallel_workers_per_gather = '2';

4. 修正effective_io_concurrency参数 #

当前设置为100，对于SSD磁盘建议设为50左右，机械磁盘建议10-20。过高的设置会导致IO请求队列拥堵，增加系统负载：

-- 若使用SSD
ALTER SYSTEM SET effective_io_concurrency = '50';
-- 若使用机械磁盘
ALTER SYSTEM SET effective_io_concurrency = '15';

5. 补充关键参数配置 #

用户未给出shared_buffers和maintenance_work_mem的设置，建议补充调整：

• shared_buffers：建议设为物理内存的25%，即4GB，提升数据库缓存效率：

ALTER SYSTEM SET shared_buffers = '4GB';

• maintenance_work_mem：避免VACUUM等维护操作占用过多内存，建议设为512MB：

ALTER SYSTEM SET maintenance_work_mem = '512MB';

额外优化建议 #

• 配置OOM优先级：修改/etc/security/limits.conf，给postgres进程设置更低的OOM得分，避免被优先杀死：

postgres soft oom_score_adj -1000
postgres hard oom_score_adj -1000

• 监控高负载场景：通过pg_stat_activity查看慢查询和内存占用高的SQL语句，针对性优化；用top、free命令监控系统内存使用情况；
• 定期清理无用数据：执行VACUUM ANALYZE，避免表膨胀导致的内存和IO压力。

内容的提问来源于stack exchange，提问作者Manoj