Interactive tool
Requests and limits, from measurements
Most OOMKilled incidents come from a limit set by guess rather than measurement. This turns what you observed into numbers you can paste, and explains each one — including why it does not suggest a CPU limit.
Runs in your browser · nothing is sent anywhere
Measured input
MiB
Steady-state usage under normal traffic
MiB
Highest you have observed, including startup
millicores
Steady-state usage
millicores
Highest you have observed
Where to get these numbers
kubectl top pod <pod> --containers
Sample several times across a full load cycle. One reading cannot show a peak, and a guessed input produces a guessed limit — which is how OOMKilled happens in the first place.
Suggested
resources:
requests:
memory: "256Mi"
cpu: "150m"
limits:
memory: "512Mi"
# No CPU limit set — see the note above.Why these numbers
- Memory request is set near typical usage (180 MiB). Requests are what the scheduler reserves, so inflating them makes the cluster look full while nodes sit idle.
- Memory limit is 25% above your observed peak (320 MiB). The limit is the kill line — crossing it means SIGKILL from the kernel with no graceful shutdown.
- No CPU limit is suggested. CPU is compressible: exceeding a request throttles the container rather than killing it, and tight CPU limits are a common cause of latency nobody can explain. Memory offers no such forgiveness, which is why it gets a limit and CPU does not.
Related troubleshooting
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere