Page 3 of 3
Put this tier together against a realistic page: a service is getting OOM-killed at unpredictable times, with no obvious traffic spike correlating to the kills. The diagnostic path:
dmesg -T | grep -i "killed process"
# [Tue Sep 2 03:14:07 2026] Killed process 4821 (java) total-vm:4194304kB, anon-rss:2050000kB
kubectl top pod my-app-7d9f8 # is usage actually creeping toward the limit over time?
kubectl describe pod my-app-7d9f8 | grep -A2 Limits # what's the configured ceiling?
The dmesg line confirms it was the OOM killer, not a crash, and the RSS figure at time of death tells you exactly how much memory the process was actually holding when it got killed, which you compare against the cgroup limit from the pod spec. If RSS was climbing steadily over hours before each kill rather than spiking suddenly, that's a memory leak, not a traffic-driven spike, and no amount of raising the limit fixes it, it just delays the inevitable kill by a few more hours. If instead the kills correlate with periodic batch jobs or garbage-collection pauses that temporarily inflate memory, the fix might genuinely be raising the resource ceiling, or tuning the application's own memory behavior. A JVM heap sized too close to its container's cgroup limit is a classic version of exactly this problem, since the JVM manages its own heap without necessarily knowing about the cgroup ceiling wrapped around it. Either way, the answer comes from correlating the OOM kill timestamp against a memory trend, not from treating each kill as an isolated, unexplainable event.
Real scenario-based DevOps questions, hands-on practice, and clear explanations for every answer.