PostgreSQL and the Linux OOM Killer: A Better Default
5 hours ago
- Memory overcommit allows Linux to grant more address space than physical memory, using physical pages only on first touch; overcommit can trigger the OOM killer when touched pages exceed RAM.
- Postgres is vulnerable to OOM kills because shared memory segments (buffers, WAL, locks) are shared across backends; a SIGKILL can corrupt the segment, forcing the postmaster to restart the entire instance via crash recovery.
- Strict overcommit (vm.overcommit_memory=2) makes the kernel track committed memory and refuse allocations beyond a limit, returning ENOMEM instead of killing a process.
- Postgres handles ENOMEM as a query error: the transaction rolls back, the query fails with 'out of memory', and other connections remain unaffected.
- ClickHouse Managed Postgres uses strict overcommit with a limit set to 80% of available memory (excluding huge pages) plus 2GB, resulting in ~60% of total RAM plus 2GB.
- Experimental comparison on an m7i.2xlarge instance: under default policy, OOM killed a backend, causing 30.2 seconds of downtime and dropping all 20 bystander sessions; under strict overcommit, a single query failed with an error while 19 sessions continued and no downtime occurred.
- Performance overhead of strict overcommit is negligible: 2.2% difference in select-only throughput and 0.6% in read-write throughput, within run-to-run variation.
- The key takeaway: memory exhaustion is inevitable; the policy determines the cost—strict overcommit limits damage to a single query error, while default policy risks instance-wide restart.