Memory Pressure and OOM Kill

When total memory demand from a process or the entire host exceeds available physical RAM plus swap, the Linux OOM killer terminates one or more processes to reclaim memory, causing immediate connection loss, data corruption risk if in-flight writes are lost, and process restart overhead.

The Linux OOM (Out-Of-Memory) killer is invoked when the kernel cannot satisfy a memory allocation request from any process and swap space is exhausted. The OOM killer selects a process to terminate based on an oom_score calculation (a function of memory usage, runtime, and /proc/PID/oom_adj). Database processes (PostgreSQL postmaster, Redis, MongoDB mongod) are large memory consumers and are frequently selected as OOM victims.

For PostgreSQL: when the postmaster process is OOM-killed, all client connections are severed immediately. The shared memory segment (shared_buffers) is deallocated. Dirty shared buffer pages that had not been checkpointed to disk are lost: these will be replayed from WAL on restart, but WAL replay may take minutes for a large shared_buffers. All active transactions are rolled back by the crash recovery process. Depending on crash recovery mode, the database may be unavailable for 1–10 minutes.

For Redis: if the Redis process is OOM-killed and persistence is disabled (save "" or appendonly no), all in-memory data is permanently lost. If appendonly yes is configured, the AOF file contains all committed writes but recovery requires replaying it: seconds to minutes depending on AOF size.

Memory pressure scenarios in PostgreSQL: 1. shared_buffers configured too large: shared_buffers = 16GB on a 16GB host

leaves 0GB for OS page cache, sort operations, and other processes.

2. Sort and hash operations exceeding work_mem: a complex query with 10 hash

joins at work_mem = 256MB can allocate 10 × 256MB = 2.5GB for a single query.

Multiply by concurrent queries.

3. Connection count × connection overhead: each PostgreSQL connection uses

5–10MB of memory (stack, local cache). 1,000 connections = 5–10GB.

4. Autovacuum workers with large scale: autovacuum on a very large table

with aggressive settings can consume hundreds of MB per worker.

Memory pressure builds gradually and is often ignored until the OOM event. The first signs are the kernel beginning to reclaim page cache aggressively (free -m shows available memory dropping to near 0) and swap utilisation growing. These are warning signals that OOM is approaching.