时间戳

首页 > 解决方案 > CPU-Shares 对线程有什么影响

java - CPU-Shares 对线程有什么影响

问题描述

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

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

因此，我阅读了一篇关于容器中的 java的文章（我在 CloudFoundary 上运行应用程序时观察到了这一点），3以及JDK 10 中用于检测容器限制的增强功能。

在上述文章中：

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

现在，如果

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

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

标签： javamultithreadingdockercontainerscgroups

解决方案

是的，它将四舍五入为1。

实施正在进行中./hotspot/os/linux/osContainer_linux.cpp，基本上如下所示：

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

wherePER_CPU_SHARES = 1024和 share 根据您的示例512。该函数将导致1.

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

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

推荐阅读