What is the impact of CPU-Shares on Threads

Question

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?

Answer 1

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.