PostgreSQL's Strict Memory Overcommit Protects Against OOM Kills

Overview of Memory Overcommit

Linux permits processes to allocate more virtual memory than the available physical memory. This virtual memory allocation does not immediately consume physical memory, relying instead on the assumption that not all allocated memory will be used actively at once.

Impact of OOM Killer on PostgreSQL

When processes exceed memory capacity, the Linux kernel invokes the OOM killer, which terminates processes to free memory. In the case of PostgreSQL, this can have severe consequences since the database's architecture involves shared memory among various backend processes.

Consequences of OOM Kill for PostgreSQL

If the OOM killer terminates a PostgreSQL backend process, it risks leaving shared memory in an inconsistent state, potentially leading to silent data corruption. PostgreSQL's postmaster responds by terminating all active connections to safeguard the database from corruption.

Kernel Bug and Its Effects

A specific kernel bug caused the team to temporarily disable strict memory overcommit, highlighting the critical balance between system settings and database integrity. The disabling of this feature meant increased vulnerability to OOM kills and the associated risks.

Determining the Right Memory Overcommit Settings

The article aims to share heuristics for setting the optimal memory overcommit limit for PostgreSQL workloads, enhancing reliability and data integrity. Understanding these settings is vital for database administrators to prevent OOM-related issues.