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?
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.