Linux 内核 CFS CPU 使用说明

Question

我试图更好地理解 Linux 的 CFS（完全公平调度程序）在幕后如何工作，以便在 Kubernetes 方面做出一些改进。

好吧，假设我有一个只有 1 个核心的处理器。这意味着我可以一次执行 1 个任务，无论如何，这就是处理器的工作原理。如今，在 Linux 内核 (>=2.6.23) 上，我们有一个名为 CFS 的工具，它将尝试公平地为所有进程提供相同的 CPU 使用量。

然后对于同一个1核处理器，我有2个进程，在这种情况下，CFS会尝试为每个进程设置这个核心的50%（1/2=0.5），我知道它比这更复杂，我们有优先级和类别将定义

virtual runtime

，以便 CFS 可以从堆中弹出正确的优先级和类别，在这种情况下是最少的

virtual runtime

。

现在我知道 CFS 如何选择正确的进程来运行（基于

virtual runtime

）并将其分派到处理器核心。

所以，我要解释的下一部分对我来说还不够清楚，所以需要你们的帮助来澄清我的想法。这就是让我感到困惑的地方。

假设我有相同的 2 个进程（P1 和 P2）和一个 1 核处理器。 P1需要50ms才能完成其工作，P2需要100ms。忽略 CFS 并直接将 P1 发送到处理器核心将每 50ms 阻塞 P2，这意味着：P2 将花费 150ms = 50ms（被 P1 阻塞）+ 100ms（CPU 突发时间）。就像这个图一样：

当CFS设置

sched_latency_ns=10000000 (10ms)

时，意味着每个进程每次执行的时间不能超过10ms。所以，看看我的图表：

在这种情况下，P1 将需要 100ms 多一点的时间才能完成，因为我们有一些被 P2 阻塞的时间，但另一方面，P2 会比等待 100ms 等待 p1 释放 CPU 更有效率，这肯定更公平.

现在，当 Kubernetes 发挥作用时，我可以使用不同的单位，100 毫核，事情再次变得混乱，因为 CPU 是按时间测量的。这是我的理解：100milli = 100/1000 = 0.1，所以如果我的 Linux 内核上的 CFS 设置为

sched_latency_ns=10000000 (10ms)

，这意味着对于 100milli，我们一次将有 1ms 的 CPU 使用率（0.1*10ms=1ms）。因此，使用

cgroup

限制为 100 毫秒意味着无论

sched_latency_ns

是否大于该值，我的任务每次只需要 1 毫秒。

抱歉文字很长，但这不是一件容易解释的事情，所以在这里尝试说得非常清楚。无论如何，谢谢。

Answer 1

假设您有 1 个可用的 CPU 核心，并且通过

spec.resources.limits.cpu: 1

为 1 个 pod 分配了 1 个 CPU 核心。这意味着 Pod 每 1 实时秒允许运行 1 秒。 Pod 内运行的所有进程共享 cgroup，因此所有进程总共有 1 个 CPU 秒可供使用。

1. 如果 Pod 内有一个进程，那么该进程显然会一直运行。

2. 如果 Pod 中运行两个进程，那么每个进程平均运行一半时间。这意味着应用程序将在 50% 的时间内受到限制。

3. 如果您有 10 个进程正在运行，那么每个进程将运行 100 毫秒。该应用程序 90% 的时间都会受到限制。

可以使用 Cadvisor 指标

container_cpu_cfs_throttled_seconds_total

和

container_cpu_cfs_throttled_periods_total

来监控每个容器被限制的时间。

结论是，在高负载下，您不想启用 CPU 限制。