PostgreSQL and the OOM Killer: Why You Must Use Strict Memory Overcommit
The article explains why PostgreSQL systems must use strict memory overcommit settings to prevent the Linux OOM Killer from terminating the database process. It details how memory overcommit allows PostgreSQL to allocate more memory than available, leading to out-of-memory conditions, and recommends setting vm.overcommit_memory to 2 to avoid such crashes.
Background
- **PostgreSQL (Postgres)** is a widely used open-source relational database known for reliability and data integrity. It's memory-intensive, especially when handling many concurrent queries.
- **OOM Killer (Out-Of-Memory Killer)** is a Linux kernel feature that forcibly terminates processes when the system runs out of physical RAM, often killing Postgres under high memory load. This can corrupt data or cause unexpected downtime.
- **Memory overcommit** is a Linux default behavior where the kernel promises more memory to applications than physically exists, betting they won't all use it at once. This risks OOM kills.
- **Strict (or conservative) memory overcommit** (vm.overcommit_memory=2 in Linux) makes the kernel reject memory allocations that exceed available RAM, preventing sudden OOM kills at the cost of more upfront failures.
- **Ubicloud** is a cloud provider that runs managed Postgres. This blog post shares their hard-learned operational lesson: strict overcommit prevents the OOM killer from killing Postgres, improving stability.