Pod Memory Limit Calculator
Calculate a pod's memory limit from its request and a request-to-limit ratio, and see the OOMKill risk margin.
Inputs
The pod's configured memory request.
Multiplier applied to the request to derive the limit.
Highest memory usage seen in production, to check against OOMKill risk.
Recommended Memory Limit
384MiB
Recommended Memory Limit
0.38GiB
Margin at Observed Peak
84MiB
OOMKill Risk at Peak
false
Step by step
Memory limit = request × ratio
256MiB × 1.5
= 384MiB
Margin at observed peak
384MiB − 300MiB
= 84MiB
How it works
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
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.