Protecting PostgreSQL from the OOM Killer: A Guide to Strict Memory Overcommit
This article explains why PostgreSQL databases are particularly vulnerable to the Linux OOM (Out-Of-Memory) Killer due to their shared memory architecture, where killing a single backend process can crash the entire database. It advocates for strict memory overcommit settings (vm.overcommit_memory=2) to prevent the OOM killer from ever activating, and shares real-world operational experience including a one-character kernel bug that forced a temporary rollback of this setting. The post also provides a heuristic for determining the right overcommit limit based on workload characteristics.
Key quotes
PostgreSQL's postmaster (its main supervisor process) forks a backend process for each connection. These backends share memory segments that hold shared buffers, WAL buffers, lock tables, and other shared state.
The OOM killer doesn't understand this architecture. It simply picks a process based on a heuristic (usually the process that uses the most memory) and terminates it.
For most processes, handling an OOM kill is simple: the process restarts, reconnects, and picks up where it left off. PostgreSQL is different.
From the article
You might also wanna read
PostgreSQL Double Buffering: Why OS RAM and Buffer Cache Compete and How the 25% Rule Helps
This article explains the problem of double buffering in PostgreSQL, where the OS filesystem cache and PostgreSQL's shared_buffers both cach
How PostgreSQL survived near-death to become a cornerstone of modern cloud infrastructure
This feature article chronicles the unlikely survival and rise of PostgreSQL, tracing its origins from Michael Stonebraker's Postgres projec
theregister.com·15d ago
Stop Guessing Why Your Pods Are Crashing
PostgreSQL positioned as a solution to AI-driven datacenter energy demands
This article discusses how AI workloads and datacenter expansion are driving an energy crisis, and positions Postgres (PostgreSQL) as a solu
theregister.com·1mo ago
Comments
Sign in to join the conversation.
No comments yet. Be the first.