container-awarenesslisted

What the JVM actually detects inside a container: cgroup v1 versus v2 detection, ActiveProcessorCount and how a CPU quota becomes a processor count, MaxRAMPercentage and every ergonomic derived from it, GC and JIT thread counts sized from the wrong number, and verifying all of it from inside the running container. Use when a pod is OOMKilled while heap usage is well below Xmx, when a Deployment has no resources.limits or sets limits.memory equal to Xmx, when MaxRAMPercentage is pushed to 90, when someone reads ActiveProcessorCount out of PrintFlagsFinal or jcmd VM.flags and gets -1, when a cgroup command reads /sys/fs/cgroup/cpu/cpu.stat and finds nothing, or when latency spikes have no matching GC pause. Does not cover host-side kernel behaviour such as the node OOM killer, page faults, swap, PSI or signals (linux-for-jvm), the memory-region budget itself (jvm-memory-regions), or CPU topology and pinning (numa-and-cpu-affinity).
robsonkades/agent-skills · ★ 2 · DevOps & Infrastructure · score 68

Install: claude install-skill robsonkades/agent-skills

# Container Awareness ## Purpose Decide whether the JVM's automatic sizing inside this container is the sizing you actually want. HotSpot's `UseContainerSupport` — on by default since JDK 10 on supported Linux builds — incorporates cgroup memory and CPU constraints into ergonomics, using version-specific detection. It does not make the resulting heap, GC thread count or JIT thread count right for the workload. The failure this prevents is the confidently wrong container diagnosis: a pod killed for non-heap charges while the heap sat at 70%, diagnosed without reconciling memory views; or a detected CPU count inferred from the default `ActiveProcessorCount=-1` sentinel. ## Workflow This is Linux HotSpot guidance, with JDK 17–25 as the main command baseline and a JDK 26 heap-default note in the reference. Inspect the runtime image's vendor/update, launch flags, deployment resources and kernel/cgroup version; a build toolchain alone does not identify production ergonomics. Do not upgrade the runtime to match these examples. Start with the requested decision and existing deployment, runtime and measurement artifacts. Reuse evidence that matches the target and workload; collect only gaps that could change the answer. A flag explanation needs no new load test, and a budget that already meets its headroom and latency goals may need no change. 1. **Establish what the target JVM detected, from inside its container.** A fresh `java -XshowSettings:system` is a probe, not proof