Instead of sysconf, it started calling sched_getaffinity to find the CPU affinity mask for the process. Since 8u121 the JVM became taskset aware. To set only one CPU, write echo 0 instead of echo 0-3

Therefore, in order to fake the number of available CPUs, one could replace this file using a bind mount: echo 0-3 > /tmp/onlineĭocker run -cpus 4 -v /tmp/online:/sys/devices/system/cpu/online. In turn, glibc read the system file /sys/devices/system/cpu/online. Prior to 8u121, HotSpot JVM relied on sysconf(_SC_NPROCESSORS_ONLN) libc call. Linux container support first appeared in JDK 10 and then ported to 8u191, see JDK-8146115.Įarlier versions of the JVM obtained the number of available CPUs as following. HERE IS MY QUESTION: The CPU issue is probabily fixed in JDK8 Update 212, but what if I can not update my JVM and I am running version prior to update 131, how can I fix the cpu issue.If a container with cpu limitation is started as below, JVM will respect this limitation and restrict itself to 1 cpu.ĭocker run -ti -cpus 1 -m 1G openjdk:8u212-jdk //jvms running in this container are restricted to 1cpu. After JDK 8 update 212, any JVM running in docker container will respect the cpu limits allocated to container and not look into host cpus directly.Then it would try to access or optimize based on this CPU counts. Resolving the CPU issue (possibly fixed in JDK update 212 )Īgain like described above, JVM running in docker would look at the host hardware directly and obtain the total CPUs available. or by passing these flags - (after 131 update).explicitly setting the max heap memory limit (using -Xmx ) while starting the JVM.Like described above, JVM was allocating it's self more memory than what's allowed for the container. Solution for memory issue - (possibly fixed in JDK 8 update 131) The result is catastrophic for the JVM i.e As the JVM was trying to allocate itself more resources (CPU or Memory) than what is permitted through CGroup limits, docker demon would notice this and kill the JVM process or the container itself if the java program was running with pid 1. JVM's (JDK 8 before Update 131) running in docker containers were ignoring the CGroup limitations set by the container environment.Īnd, they were querying for host resources and not what was allocated to the container.

Java 8 update 131