OOM Killer Threshold Calculator
Calculate the memory threshold at which the Linux OOM killer is likely to trigger.
About OOM Killer Threshold Calculator
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)
Worked example
With the default values below, OOM Killer Threshold Calculator returns Status of Healthy — comfortable margin above the low watermark before OOM risk.. Change any input above and every figure here is recalculated in your browser.
Inputs used
- MemTotal (MB)minimum 1
- 16,384
- MemAvailable Now (MB)minimum 0
- 900
- vm.min_free_kbytes (KB)minimum 0
- 65,536
- Swap Free (MB)minimum 0
- 0
- Candidate Process RSS (MB, for oom_score estimate)minimum 0
- 2,048
Results
- 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
- 1Values used
- 2OOM risk margin
- 3Status= Healthy — comfortable margin above the low watermark before OOM risk.
- 4Margin Before OOM Risk (MB)= 836.00
- 5Low Watermark (≈min_free_kbytes, MB)= 64.00
- 6Estimated oom_score (0-1000 proxy)= 125
Assumptions and limits
- The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.