PostgreSQL 防 OOM 杀手的内存配置
推荐指数 62.0 NO. 014 · 2026.07.04
发布2026/07/03Score118Comments43
为什么值得看
15年运营5个托管PostgreSQL服务的团队坚持启用strict memory overcommit来避免数据库被OOM killer误杀。文中披露了一个三字符内核bug曾迫使他们临时关闭该设置，并分享了内存限制的经验公式。
编辑判断
大多数DBA只知道调vm.overcommit_ratio，但strict模式（vm.overcommit_memory=2）配合自定义ratio才是生产环境防OOM的正经做法。这个团队踩过的坑是：内核某版本把"0"误写成"00"导致strict模式失效，数据库半夜被系统杀掉——这种极隐蔽的regression只有长期运营大规模集群的团队才能捕获。
如果你在用云厂商托管RDS，这个配置通常不可见；自建K8s跑Postgres的团队建议检查节点内核版本和overcommit设置，尤其是共享内存较大的workload。他们的heuristic（work_mem * max_connections + shared_buffers ≈ 可用物理内存的80%）可以直接套用。
社区反馈
意见分歧 35 条评论
核心争论：禁用overcommit能防OOM误杀，但会牺牲内存效率并引发程序崩溃
相关内容
PostgreSQL and the OOM Killer: Why We Use Strict Memory Overcommit Ubicloud 解释为何对 PostgreSQL 采用严格内存过量使用策略，深入分析 OOM 杀手机制与内存配置权衡。 如何调整PostgreSQL的Out-Of-Memory Killer设置 中文技术博客详解 vm.overcommit_memory 参数调优，建议设为 2 避免 OOM，以及 oom_score_adj 配置技巧。 管理内存用量的最佳实践 | Cloud SQL for PostgreSQL Google Cloud 官方指南，说明 Cloud SQL 如何配置 OOM killer 仅针对工作器进程，保留 postmaster 实现快速恢复。 How to Fix PostgreSQL OOM Killer Issues 系统调优指南，涵盖内存配置与监控策略，防止 Linux OOM killer 终止 PostgreSQL 进程。
They allude to this in the article but I would emphasize caution when using mode 2 especially if one has already adjusted overcommit ratios as one can prevent forks. Test this in a QA/Perf environment first, also testing the restart of all applications. Load test and do full QA tests before d
Correcting a rather significant typo: setting the oom_score_adj for programs as high as 1000 should be -1000 to be left alone. 1000 would make it a prime candidate for an OOM kill. Positive integers should be used on sacrificial superfluous programs. [1] As an example OpenSSH sets the sshd to -1
I have disabled overcommit both on Windows and on Linux. I hate having random programs being killed. Unfortunately, many programs commit 2x memory than they actually use. Often I see ~32GB committed and ~16GB resident.