https://www.netdata.cloud/tags/ebpf-oomkill/Recent content in eBPF OOMkill on NetdataHugoen-ushttps://www.netdata.cloud/guides/cassandra/cassandra-off-heap-oom-kill/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/cassandra/cassandra-off-heap-oom-kill/<p>The JVM heap chart shows 50% utilization and a flat line. There is no <code>OutOfMemoryError</code>. Then the Cassandra process vanishes. <code>dmesg</code> shows the OOM killer terminated the JVM: <code>Killed process 12345 (java)</code>. The JVM heap metric does not include native allocations: bloom filters, compression metadata, index summaries, direct buffers, and chunk cache. When heap plus off-heap RSS exceeds available RAM, the kernel kills the process. This guide covers how to confirm that pattern, reduce off-heap footprint, and prevent recurrence.</p>https://www.netdata.cloud/guides/kubernetes/kubernetes-pod-oomkilled/Mon, 01 Jan 0001 00:00:00 +0000https://www.netdata.cloud/guides/kubernetes/kubernetes-pod-oomkilled/<p>A pod status of <code>OOMKilled</code> means the container restarted after the kernel sent SIGKILL because it could not satisfy a memory allocation. There is no graceful shutdown.</p> <p>Distinguish whether the kill happened at the container cgroup level (a limit you set) or at the node level (a system-wide shortage). Then separate kernel OOM kills from kubelet evictions, identify the correct fix, and prevent recurrence without guessing at memory limits.</p> <h2 id="what-this-means">What this means</h2> <p><code>OOMKilled</code> means the Linux OOM killer selected a process in your container and terminated it with SIGKILL (signal 9). Exit code 137 (128 + 9) often maps to <code>OOMKilled</code>, but the code alone is ambiguous: it can also result from a manual <code>docker kill</code> or an escalated graceful termination. Verify the pod status <code>Reason</code> field.</p>