I host my Java/JRuby apps in a Kubernetes cluster deployed thanks to AWS EKS.
My Kubernetes version is 1.11 (I don’t know the patch version. How can I know it ?)
I encountered a problem when I switched the version of my JVM from 8u181 to 8u202.
With the 8u181 version, my JVM booted 4 threads for one of my thread pool I configured to boot
Runtime.getRuntime.availableProcessors() threads. Which is the correct value because my kubernetes node has 4 CPUs.
With the 8u202 version, my JVM booted only 1 thread for the same thread pool and code.
I searched a lot to understand why and now I know that this is related to 2 problems. One which concerns Kubernetes (that’s why I’m here), one concerning how the recent versions of the JVM detects the number of CPU.
Apparently, in its recent versions, the JVM uses the
/sys/fs/cgroup/cpu/cpu.shares value to detect how many CPUs is can use. (I should precise that, for now, I don’t know the exact algorithm the modern JVM uses to detect the number of CPUs but I’m also working with the JVM folks to understand what’s happening)
And the reason the version 8u202 boot only 1 thread is because the default value, when we don’t set any
resources.limits.cpu restrictions, of
2 instead of
So, my question is why
/sys/fs/cgroup/cpu/cpu.shares default value is 2 ?
0 ? or
-1 like the
/sys/fs/cgroup/cpu/cpu.cfs_quota_us default value ?
Thanks for your help