我的问题更多地在Java线程方面.但是对于OS级别的线程,它可能也更通用.

JAVA特定：ThreadPool Tuning Size的意义是什么(公式)？带有容器的冲击性能及其在发动机罩下的行为. (我想我可以理解cpu集,但不能理解cpu份额,我知道什么是cpu份额,只是不了解线程在这里的行为).

因此,我读了一篇有关java in containers(在CloudFoundary上运行应用程序时观察到的),3和enhancements的文章,这些文章已引入JDK 10中以检测容器限制.

在上述文章中：

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.

现在,如果

the number_of_cpus() will be calculated based on cpu_shares()/1024

然后,在假设CPU份额为512的情况下,此计算将得出0.(然后,我假定该值将舍入为1 ??).
那如何运作呢？

解决方法:

是的,它将四舍五入为1.

该实现位于./hotspot/os/linux/osContainer_linux.cpp下,基本上看起来像这样：

share_count = ceilf((float)share / (float)PER_CPU_SHARES);

其中,PER_CPU_SHARES = 1024,共享为您的示例512.此函数的结果为1.

我不确定自己所做的编辑是否正确理解了您,但是当在同一OS上运行的多个容器尝试使用100％的CPU时,cpu共享很重要.假设您有3个容器,一个有1024个容器,另外两个有512 cpu共享.当所有三个尝试获得100％的CPU时间时,就会发生这种情况：50％的时间将流向拥有1024个份额的容器,其他的将获得25％的份额；但是同样,这仅在CPU处于100％时.

现在,再次阅读该JEP-它仅影响JIT / GC线程-不影响您的应用程序线程.您仍然可以创建尽可能多的线程,因此无论该文章如何建议-它仍然有效,为容器或无容器.