CPU-Shares 对线程有什么影响
What is the impact of CPU-Shares on Threads
我的问题更多是关于 Java 线程的级别。但对于 OS 级别的线程来说，它可能更通用。
JAVA 具体：ThreadPool Tuning Size 的相关性是什么。 （公式）？冲击性能及其在引擎盖下的行为，与容器。 （我想我可以理解 cpu-sets 但不能理解 cpu-shares，我知道什么是 cpu-shares 只是不明白线程在这里的行为）。
所以我读了一篇关于 java in containers,(which I have observed while running applications on CloudFoundary), 3 and the 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-Share 为 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。假设你有 3 个容器，一个有 1024，另外两个有 512 cpu-shares。当 all 其中 3 个尝试获得 100% 的 CPU 时间时，将发生以下情况：50% 的时间将转到具有 [=16] 的容器=] 份，其他人每人获得 25%；但这也只是当 CPU 位于 100% 时。
现在再读一遍那个 JEP——它只影响 JIT/GC 个线程——而不是你的应用程序线程；您仍然可以尽可能多地创建线程，因此无论该文章建议什么 - 它仍然有效，无论是容器还是非容器。
我的问题更多是关于 Java 线程的级别。但对于 OS 级别的线程来说，它可能更通用。
JAVA 具体：ThreadPool Tuning Size 的相关性是什么。 （公式）？冲击性能及其在引擎盖下的行为，与容器。 （我想我可以理解 cpu-sets 但不能理解 cpu-shares，我知道什么是 cpu-shares 只是不明白线程在这里的行为）。
所以我读了一篇关于 java in containers,(which I have observed while running applications on CloudFoundary), 3 and the 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-Share 为 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。假设你有 3 个容器，一个有 1024，另外两个有 512 cpu-shares。当 all 其中 3 个尝试获得 100% 的 CPU 时间时，将发生以下情况：50% 的时间将转到具有 [=16] 的容器=] 份，其他人每人获得 25%；但这也只是当 CPU 位于 100% 时。
现在再读一遍那个 JEP——它只影响 JIT/GC 个线程——而不是你的应用程序线程；您仍然可以尽可能多地创建线程，因此无论该文章建议什么 - 它仍然有效，无论是容器还是非容器。