我的问题更多地在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线程-不影响您的应用程序线程.您仍然可以创建尽可能多的线程,因此无论该文章如何建议-它仍然有效,为容器或无容器.
