Skip to content
Calcrivo

OOM Killer Threshold Calculator

Calculate the memory threshold at which the Linux OOM killer is likely to trigger.

Inputs

Status

Healthy — comfortable margin above the low watermark before OOM risk.

Margin Before OOM Risk (MB)

836.00

Low Watermark (≈min_free_kbytes, MB)

64.00

Estimated oom_score (0-1000 proxy)

125

Step by step

  1. Values used

    MemTotal (MB) = 16,384; MemAvailable Now (MB) = 900; vm.min_free_kbytes (KB) = 65,536; Swap Free (MB) = 0; Candidate Process RSS (MB, for oom_score estimate) = 2,048

  2. OOM risk margin

    margin = MemAvailable + SwapFree − min_free_kbytes

  3. Status

    = Healthy — comfortable margin above the low watermark before OOM risk.

  4. Margin Before OOM Risk (MB)

    = 836.00

  5. Low Watermark (≈min_free_kbytes, MB)

    = 64.00

  6. Estimated oom_score (0-1000 proxy)

    = 125

How it works

The kernel invokes the OOM killer as a last resort when it cannot satisfy a memory allocation even after reclaiming cache and exhausting swap — practically, this risk rises sharply once MemAvailable plus free swap approaches vm.min_free_kbytes, a reserve the kernel tries to keep free for atomic (non-blocking) allocations like network interrupt handling. When the OOM killer does trigger, it selects a victim process using a heuristic oom_score (roughly proportional to memory footprint, adjustable per-process via /proc/<pid>/oom_score_adj) — this calculator's oom_score_estimate is a simplified proxy for that ranking, not the kernel's exact computation.

Formula

OOM risk margin

margin = MemAvailable + SwapFree − min_free_kbytes

A
MemAvailable
S_free
free swap
W_low
low watermark (≈min_free_kbytes)

Frequently Asked Questions

Why did the OOM killer terminate a process even though 'free -h' showed some free memory?

The kernel reserves a chunk of memory (governed by vm.min_free_kbytes) that regular allocations can't touch, to guarantee atomic/interrupt-context allocations always succeed. If regular memory pressure pushes available memory down to that reserve with no swap left to fall back on, OOM killer triggers even though the reserve itself is technically 'free'.

How does the kernel choose which process to kill?

It computes an oom_score for every eligible process, heavily weighted by memory usage (RSS plus swap usage), adjusted by each process's oom_score_adj (settable to bias the kernel toward or away from killing a specific process, e.g. protecting a database with a negative adjustment) and some additional heuristics like process age and privilege level.

Can I protect a critical process from being killed?

Yes — write a negative value to /proc/<pid>/oom_score_adj (down to -1000, which fully exempts it) to reduce its likelihood of being chosen. Use this carefully: it doesn't prevent OOM conditions, it just redirects the kernel's choice of victim to other processes.

You might also need