Reputation: 3302
My Question is more on the level of Java threads. But probably it might be more generic for OS level threads as well.
JAVA SPECIFIC: what would be the relevance of ThreadPool Tuning Size. (The formula)? The impact performance and how it behaves under the hood, with containers. (I think I can understand cpu-sets but not cpu-shares, I know what cpu-shares is just didn't understand how threading behaves here).
So I was an article reading about java in containers,(which I have observed while running applications on CloudFoundary), 3 and the enhancements that were brought in JDK 10 for detecting container limits.
In the said article:
Let’s take a short look at how the JVM adjust to the number of processors/cores available on the node it is running on. There are actually a number of parameters which by default are initialized based on core count. So if the normal default values for GC-threads, JIT Threads etc are the total number of 'cores' available.
Now, If
the number_of_cpus() will be calculated based on cpu_shares()/1024
Then in a scenario where let's say the CPU-Share is 512. This calculation would give 0. (I'm then assuming that the value would be rounded to 1?? ). How does this work then?
Upvotes: 3
Views: 1196
Reputation: 120848
Yes, it will be rounded to 1.
The implementation is under ./hotspot/os/linux/osContainer_linux.cpp
and basically looks like this:
share_count = ceilf((float)share / (float)PER_CPU_SHARES);
where PER_CPU_SHARES = 1024
and share is as per your example 512
. This function will result in 1
.
I am not very sure I understand you correctly with your edit, but a cpu-share
matters when multiple containers running on the same OS try to use 100% of the CPU. Suppose you have 3 containers, one has 1024
, the other two have 512
cpu-shares. When all 3 of them try to get 100% of a CPU time, this is what will happen: 50% of the time will go to the container that has 1024
shares, the other ones will get each 25%
; but again this is only when the CPU is at 100%
.
And now read that JEP again - it only affects JIT/GC threads - not your application threads; you can still create a many threads as you could, so whatever that article suggests - it is still valid, container or no container.
Upvotes: 4