CPU-Shares 对线程有什么影响

Question

我的问题更多是关于 Java 线程的级别。但对于操作系统级别的线程，它可能也更通用。

JAVA SPECIFIC：ThreadPool Tuning Size 的相关性是什么。 （公式）？影响性能及其在引擎盖下的行为方式，以及容器。 （我想我可以理解 cpu-sets 但不能理解 cpu-shares，我知道 cpu-shares 是什么，只是不明白线程在这里的行为方式）。

所以我阅读了一篇关于 java in containers（我在 CloudFoundary 上运行应用程序时观察到）、3 和 enhancements 的文章，它们被引入 JDK 10 以检测容器限制。

在上述文章中：

让我们简要了解一下 JVM 如何适应其运行的节点上可用的处理器/内核数量。实际上有许多参数默认情况下是根据核心数进行初始化的。 因此，如果 GC 线程、JIT 线程等的正常默认值是可用的“核心”总数。

现在，如果

number_of_cpus() 将根据 cpu_shares()/1024 计算

然后在假设 CPU-Share 为 512 的情况下。此计算结果为 0。（我假设该值将四舍五入为 1？？）。 那么这是如何工作的呢？

Answer 1

是的，将四舍五入到 1。

实现在./hotspot/os/linux/osContainer_linux.cpp 下，基本上是这样的：

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

其中PER_CPU_SHARES = 1024 和共享是根据您的示例512。此函数将产生1。

我不太确定我是否正确理解了您的编辑，但是当在同一操作系统上运行的多个容器尝试使用 100% 的 CPU 时，cpu-share 很重要。假设你有 3 个容器，一个有 1024，另外两个有 512 cpu-shares。当所有其中 3 个尝试获得 100% 的 CPU 时间时，将会发生以下情况：50% 的时间将用于拥有 1024 共享的容器，其他的将获得每个25%；但这只是在 CPU 位于 100% 时。

现在再次阅读该 JEP - 它只影响 JIT/GC 线程 - 而不是您的应用程序线程；您仍然可以尽可能多地创建线程，因此无论该文章建议什么 - 它仍然有效，容器或无容器。