HDUO Lab

深入 CFS 调度器陷阱排查：cgroup quota 微突发引发的无辜节流与 P99 延迟雪崩实战

作者：

ningniu

在

在 K8s 容器环境中，CPU 使用率不到 20% 却频繁出现 P99 延迟毛刺，根本原因是 CFS 带宽控制（cfs_quota_us）在微突发场景下的过度节流（Throttling）。解决方案：要么升级内核至 5.14+ 开启 CPU Burst 特性，要么对核心时延敏感型服务启用 Kubelet static CPU Manager 策略以独占物理核并绕过 quota 限制，辅以 NUMA 节点绑定。

排查过程中，我们遇到一个典型且极其隐蔽的性能陷阱：一个用 Go 编写的高并发 API 服务，Pod 配置为 requests: 4, limits: 4，Prometheus 监控显示其 CPU 利用率峰值从未超过 1.5 核。然而，业务端频繁报出超时，网关层统计的 P99 延迟从平稳的 20ms 间歇性飙升至 300ms 以上。

没有 GC 停顿，网络抓包无丢包，存储 IO 处于极低水位。唯一的异常落在 cgroup 的 CPU 调度统计上。

执行以下命令查看该 Pod 对应容器的底层调度指标：

# 进入容器对应的 cgroup 目录 (路径依 Cgroup v1/v2 及容器运行时有所不同)
cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod<uid>.slice/docker-<cid>.scope/cpu.stat

输出令人吃惊：

nr_periods 542100
nr_throttled 184520
throttled_time 4851230000000

超过 34% 的调度周期（nr_throttled / nr_periods）发生了节流（Throttling），累计被限制运行的时间高达 4851 秒。容器被系统强制“按下了暂停键”。

为什么 CPU 使用率极低也会触发 CFS 节流（Throttling）？

要理解这个诡异现象，必须剖析 Linux 内核完全公平调度器（CFS）的带宽控制（Bandwidth Control）机制。

在 Kubernetes 中，设置 CPU limits 本质上是在配置 cgroup 的 cpu.cfs_period_us 和 cpu.cfs_quota_us。 默认情况下：

  • cpu.cfs_period_us = 100000（100 毫秒），即调度周期。

  • 对于 limits: 4，cpu.cfs_quota_us = 400000（400 毫秒）。

“微突发（Micro-burst）”导致的无辜节流： Go 程序的协程（Goroutine）极多。假设在某个 100ms 的调度周期初始，网关突然打来一波并发请求，Go runtime 唤醒了 16 个 OS 线程来处理。 这 16 个线程在多核宿主机上并行执行，虽然每个线程仅仅执行了 25ms，但总计消耗的 CPU 时间为 16 * 25ms = 400ms。

此时，距离当前 100ms 周期结束还有 100ms - 25ms = 75ms，但 400ms 的 quota 已经被瞬间耗尽。 CFS 调度器的直接反应是：强制剥夺该 cgroup 内所有线程的执行权，挂起等待下一个 100ms 周期。 这就导致了业务请求在这 75ms 内得不到任何 CPU 资源，直接反映为 P99 延迟无端增加 70~80ms，且多次叠加后引发雪崩。而在更高维度的 Prometheus 监控中（通常是 15s 或 1m 抓取一次），这种 100ms 级别内的剧烈波动被彻底抹平了，导致 CPU 使用率看起来极其“健康”。

破局方案与底层调优实战

为了彻底解决 CFS 调度导致的延迟毛刺，我们分层级实施了以下架构改造，拒绝简单的“无脑放大 limits”。

1. 终极解法：内核 CPU Burst 特性 (Kernel >= 5.14)

在较新的内核版本中（部分大厂针对 Kernel 4.19/5.4 已 backport 该特性），内核引入了 cpu.cfs_burst_us。它允许容器将历史周期内未用完的 quota 累积起来，应对突发流量。 通过向容器注入类似配置，允许最大爆发额度（比如额外允许 400ms）：

echo 400000 > /sys/fs/cgroup/cpu/kubepods.slice/.../cpu.cfs_burst_us

这一机制类似于令牌桶算法，有效吸收了微突发流量。开启后，nr_throttled 归零，P99 延迟恢复平滑。

2. K8S 侧解法：启用 CPU Manager 的 Static 策略

如果内核版本较低（如 CentOS 7 的 3.10 或标准 Ubuntu 20.04 的 5.4），我们必须规避 CFS quota。手段是通过 Kubelet 的 CPU Manager 将容器进程与物理 CPU 进行绑核（cpuset），并移除 cgroup quota 限制。

修改 kubelet 配置文件 /var/lib/kubelet/config.yaml：

cpuManagerPolicy: static
topologyManagerPolicy: single-numa-node

Pod 配置规范： 必须保证 QoS 为 Guaranteed，即 requests 必须等于 limits，且值为整数。

resources:
  requests:
    cpu: "4"
    memory: "8Gi"
  limits:
    cpu: "4"
    memory: "8Gi"

此时 Kubelet 会通过 cgroup 的 cpuset.cpus 分配 4 个独占的逻辑核（例如 4-7），由于是独占，底层不再依赖 cfs_quota_us 限制，从而彻底根除 Throttling。

3. 极客进阶：防御中断风暴与 NUMA 错位

仅仅使用 cpuset 绑核并不完美。即使应用独占了 CPU 4-7，依然可能被网卡中断（Hard IRQ）和软中断（Softirq）抢占。通过 perf sched 或 mpstat 可以看到上下文切换（CS）依然很高。

隔离内核调度（Isolcpus 配合 IRQ Affinity）： 修改宿主机 Grub 内核启动参数，将部分 CPU 从内核默认调度域中剔除：

GRUB_CMDLINE_LINUX="... isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7"

同时调整中断亲和性，避免网卡队列中断落到被隔离的核上：

# 将中断限制在 0-3 核上处理
for irq in $(ls /proc/irq/); do
    echo 0-3 > /proc/irq/$irq/smp_affinity_list 2>/dev/null
done

这就为高吞吐、低延迟的核心业务打造了一条纯粹的“物理超车道”。

常见问题 (FAQ)

Q1：K8s 中设置 requests == limits 会带来什么调度层面的影响？ A：除了触发 Guaranteed QoS 避免 OOM 驱逐外，在 CPU 调度层面，如果不开启 Kubelet CPU Manager static 策略，它依然受制于 CFS Quota 限制。只有在 static 策略下，整核的 requests==limits 才会触发底层 cpuset 独占逻辑，从而完全绕开 CFS 周期结算，这对时延敏感型（Latency-sensitive）应用至关重要。

Q2：绑核（Taskset/cpuset）后，为什么还会出现 CPU 缓存未命中（Cache Miss）飙升？ A：通常是因为 NUMA 节点未对齐。如果分配的 CPU 核在 NUMA Node 0，但进程访问的内存被分配在 NUMA Node 1，跨 QPI/UPI 总线访问内存会导致严重的延迟。解决方案是在 Kubelet 开启 topologyManagerPolicy: single-numa-node，强制 CPU 和内存在同一 NUMA 节点内分配。

Q3：内核参数 kernel.sched_min_granularity_ns 对高并发有什么直接作用？ A：该参数定义了 CFS 调度中一个任务在被抢占前能够保证运行的最小时间片段（默认一般为 3ms-10ms）。在极其密集的上下文切换场景（如成千上万个轻量级连接），适当调大该值可以减少上下文切换带来的开销，提升系统总吞吐量（Throughput），但代价是牺牲了一定的调度响应时延（Latency）。调整时需通过 perf 工具严格评估收益。

Q4：为什么在高并发数据库（如 MySQL/Redis）的宿主机上，极不推荐混部 RT（实时）调度策略的进程？ A：RT 任务（如 SCHED_FIFO / SCHED_RR）优先级高于所有的 CFS 普通任务。如果一个存在死循环或长时间未主动 yield 的 RT 进程跑满单核，不仅会饿死同核上的 MySQL 工作线程，甚至可能导致内核态的软狗（Soft Lockup）超时引发内核 panic。控制 RT 任务的爆炸半径，必须严格配置 kernel.sched_rt_runtime_us 和 kernel.sched_rt_period_us。

更多文章