/proc/meminfo
and /proc/cpuinfo
files for available memory and CPUs. The content of these files reflects the amount of resources of the host/node machine that is running the container, but do not reflect the actual limits assigned to the container (which may be much less)./sys/fs/cgroup/cpu
and /sys/fs/cgroup/memory
.8u141
is not container-aware, it will output the MaxHeapSize
(in bytes) that is calculated from the host machine and can be significantly higher than the 256MB of memory you originally assigned. This means your Java process may allocate heap aggressively and go beyond the original limit, causing the container instance to be killed, usually result in a OOMKilled
message.MaxHeapSize
is now 132120576
bytes, which is ~126MB, indicating that it's now respecting the 256MB limitation we assigned for the container.OOMKilled
for your container instance, and have already made sure that you are using a container-aware version of JDK, then you may want to turn on Native Memory Tracking.JAVA_TOOL_OPTIONS
. OOMKilled
, then it's an unsuccessful exit, so the memory details may not be printed. In this case, consider first increase the amount of memory allocation, and then trigger a successful exit, to get the native memory usage details.ParallelGCThreads
that is calculated from the number of CPUs of the host machine and can be significantly higher than 2
.ParallelGCThreads
is 2
.Runtime
API as well.availableProcessors
to determine the size of the thread pools. So, if you allocated only 2
CPUs, but the JVM inaccurately sees 32
CPUs from the host, then the libraries may over-allocate the thread pool size, and causing your application to run more than the underlying system allows.