High memory

Purpose

Investigate high memory usage, OOMKills, container restarts, and possible Java heap or native-memory leaks.

Symptoms

\n
• Container memory near its limit.
\n
• \1 termination reason.
\n
• Frequent pod restarts.
\n
• Increasing old-generation occupancy.
\n
• Long or frequent garbage-collection pauses.
\n
• \1 in application logs.
\n

Initial Triage

kubectl top pods -n <namespace> --sort-by=memory\nkubectl describe pod <pod> -n <namespace>\nkubectl get events -n <namespace> --sort-by=.lastTimestamp\nkubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

Check configured resources:

kubectl get deploy <deployment> -n <namespace> -o yaml

Compare:

\n
• Container memory limit.
\n
• JVM heap settings.
\n
• Non-heap and native-memory requirements.
\n
• Number of threads.
\n
• Direct-buffer usage.
\n
• Metaspace usage.
\n

JVM Memory Checks

kubectl exec -n <namespace> <pod> -- jcmd <java-pid> VM.flags\nkubectl exec -n <namespace> <pod> -- jcmd <java-pid> GC.heap_info\nkubectl exec -n <namespace> <pod> -- jcmd <java-pid> VM.native_memory summary

Native Memory Tracking must be enabled at JVM startup for detailed output:

-XX:NativeMemoryTracking=summary

Check GC logs for:

\n
• Increasing post-GC heap occupancy.
\n
• Full GC frequency.
\n
• Promotion failures.
\n
• Humongous allocations.
\n
• Long pause times.
\n

Heap Dump

Only capture a heap dump after assessing disk capacity and operational impact:

kubectl exec -n <namespace> <pod> -- jcmd <java-pid> GC.heap_dump /tmp/heap.hprof\nkubectl cp <namespace>/<pod>:/tmp/heap.hprof ./heap.hprof

Analyze with Eclipse MAT or another approved heap-analysis tool.

Look for:

\n
• Dominator tree leaders.
\n
• Large collections and maps.
\n
• Retained objects.
\n
• Class-loader leaks.
\n
• Unbounded caches.
\n
• Request/session objects retained too long.
\n

Common Causes

\n
• Unbounded in-memory caches.
\n
• Static collections retaining objects.
\n
• ThreadLocal leaks.
\n
• Excessive direct buffers.
\n
• Too many threads.
\n
• Large response/request payloads.
\n
• Class-loader leaks after redeployments.
\n
• Heap sizing too close to the container limit.
\n
• Native memory or off-heap allocations.
\n

Mitigation

\n
• Scale out if memory pressure is traffic-related.
\n
• Reduce cache size or add expiry.
\n
• Fix object-retention or listener leaks.
\n
• Reduce payload sizes and buffering.
\n
• Review thread-pool sizes.
\n
• Increase container memory only after identifying the memory category.
\n
• Keep headroom between JVM heap and container limit.
\n
• Enable heap-dump-on-OOM only with sufficient disk capacity.
\n

Validation

kubectl top pod <pod> -n <namespace>\nkubectl get pod <pod> -n <namespace> -w

Confirm:

\n
• Memory remains below the limit.
\n
• No repeated OOMKills.
\n
• Post-GC heap occupancy is stable.
\n
• Restart rate returns to normal.
\n
• Latency and error rates remain healthy.
\n