Pod Memory Limit Calculator
Set a memory limit that prevents OOMKills while leaving headroom for spikes.
About Pod Memory Limit Calculator
Unlike CPU, memory is not compressible — a container that exceeds its memory limit is immediately OOMKilled by the kernel, not throttled. This calculator derives the limit from the memory request scaled by a ratio, then checks whether historically observed peak usage would breach that limit, since a ratio that looks safe on paper can still leave you exposed if peaks are underestimated.
Formula
memoryLimit = memoryRequest × ratio
- R
- Memory request in MiB
- \rho
- Limit-to-request ratio (typically 1.0–1.5×)
- L
- Memory limit in MiB
Worked example
With the default values below, Pod Memory Limit Calculator returns Recommended Memory Limit of 384. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Memory Requestaccepts 1–1,000,000 MiB
- 256 MiB
- Limit-to-Request Ratioaccepts 1–5 ×
- 1.5 ×
- Observed Peak Memory Usageaccepts 0–1,000,000 MiB
- 300 MiB
Results
- Recommended Memory Limit
- 384 MiB
- Recommended Memory Limit
- 0.38 GiB
- Margin at Observed Peak
- 84 MiB
- OOMKill Risk at Peak
- false
Step by step
- 1Memory limit = request × ratio= 384MiB
- 2Margin at observed peak= 84MiB
Assumptions and limits
- The result is derived only from the 3 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 is memory OOMKilled instead of throttled like CPU?
Memory can't be reclaimed the way CPU time can be rationed — once a process exceeds its cgroup memory limit, the kernel's OOM killer terminates it immediately to protect the node, causing a pod restart.
What ratio is safe between memory request and limit?
1.0 (request equals limit, Guaranteed QoS) is safest for avoiding surprise OOMKills. Ratios of 1.2–1.5× add some slack for transient spikes but should be validated against real peak usage data.
What should I do if the OOMKill risk flag is triggered?
Either raise the memory limit (and likely the request) to sit above observed peaks with margin, or investigate whether the peak reflects a memory leak that should be fixed rather than accommodated.