如果你在生产环境跑 K8s、Docker，或者搞过 CPU 密集型服务调优，一定踩过这种坑：明明给容器配了 --cpu-quota=50000，进程还是能把 CPU 跑满；或者反过来，业务一卡顿，监控显示 throttled_time 暴涨，但 top 看每个核都没占满。
问题出在哪？出在你对 Linux 默认调度器 CFS（Completely Fair Scheduler）的理解上。
别被'完全公平'这四个字骗了。CFS 本身不保证 CPU 带宽上限，它只负责'公平分蛋糕'。想要给容器加 CPU 上限，必须靠 cgroup + CFS Bandwidth Control 这套组合拳。但很多兄弟连 cgroup 编译开关都没开全，限额当然形同虚设。
这篇咱们直接扒内核源码（基于 v5.10），把 CFS 的 vruntime 红黑树、cgroup 资源控制层级、CFS Bandwidth 控制原理全拆开。废话不多说，上硬菜。
🧠 CFS 到底是个啥？三个字讲透
CFS 是 Linux 内核从 2.6.23 开始取代旧 O(1) 调度器的默认进程调度器，专管 SCHED_NORMAL/SCHED_BATCH 这类'常规进程'（实时进程 SCHED_RR/SCHED_FIFO 走另一套 rt.c 调度器，优先级更高，永远插队）。
它的核心设计哲学，Ingo Molnar 大神在源码注释里写得很直白：
"将真实 CPU 建模为一个'理想、精确的多任务 CPU'——100% 物理资源，能精确地以相同速度并行执行多个进程，每个任务的速度都是 1/nr_running。"
说人话就是：假设 CPU 能分身，同时给每个进程匀速跑，谁也别想多吃一口。但现实里 CPU 只能一次跑一个，所以 CFS 用了一个叫 virtual runtime（vruntime） 的东西来记账——单位是纳秒（ns），跟 jiffies 和 HZ 都没关系。
🌲 vruntime 红黑树：CFS 的命根子
CFS 给每个 CPU 维护一个 runqueue（运行队列），里面所有可运行的进程都挂在一棵基于 vruntime 排序的 红黑树上。这就是 CFS 的核心数据结构。
调度逻辑贼简单：永远选 vruntime 最小的进程上 CPU 跑。跑完之后 vruntime 增加，被挪到树右边，新来或唤醒的进程用 min_vruntime 初始化（放最左边），保证它能尽快被调度到，避免饥饿。
看内核源码（kernel/sched/fair.c）里 pick_next_task 的逻辑，本质就是 rb_tree 的 leftmost 节点：
// include/linux/sched.hstruct sched_entity { struct rb_node run_node; // 红黑树节点 u64 exec_start; u64 sum_exec_runtime; u64 vruntime; // 虚拟运行时间，单位 ns u64 prev_sum_exec_runtime; u64 nr_migrations; struct sched_statistics statistics;};// kernel/sched/sched.hstruct cfs_rq { struct rb_root_cached tasks_timeline; // 基于时序的红黑树 u64 min_vruntime; // 单调递增的最小 vruntime unsigned int nr_running; struct sched_entity *curr;};这下明白了吧？CFS 之所以'公平'，全靠这棵红黑树和 vruntime 的加减。但注意——这玩意儿只能保证相对公平，没法给某个进程硬卡个 CPU 上限。
🚨 CFS 三大死穴：默认配置下你一定踩过
死穴一：CPU 没用满也会被多塞
CFS 是 work-conserving 的——一个进程 sleep/wait 的时间，会被另一进程抢走。所以两个进程理论各 50%，但只要一个经常 sleep，另一个实际能用超过 50%。
死穴二：优先级高也未必多吃
nice 值会影响时间片权重，但绝对值依然不保证。进程越多，每个进程分到的 CPU 时间越少，公有云按 CPU 时间计费的话，这就是个深坑。
死穴三：无法设置硬上限
CFS 本身不限制 CPU 使用上限，share/quota 只有相对意义。想给容器设硬上限？必须上 CFS Bandwidth Control。这也是为啥 Docker --cpu-quota 默认 0（不限制）的根本原因——它得靠内核 cgroup 机制才能落地。
🔧 cgroup + CFS Bandwidth：容器 CPU 限额的真相
Google 2010 年搞出了 CFS Bandwidth Control 方案合并进主线内核，专治 CFS 不能设上限的病。原理不复杂：给每个 cgroup 设个 周期（period） 和 配额（quota），quota 用完了就把这组进程 throttle（掐住），等下个 period 再放出来。
但这玩意儿依赖一长串编译开关，很多人内核压根没开全，等于装了个寂寞。
来看 init/Kconfig 里这几层依赖关系（缺一不可）：
要启用 CFS 带宽控制，必须四件套全开：
CONFIG_CGROUPS=y && CONFIG_CGROUP_SCHED=y && CONFIG_FAIR_GROUP_SCHED=y && CONFIG_CFS_BANDWIDTH=y查一下你的内核开了没：
grep -E 'CONFIG_CGROUPS|CONFIG_CGROUP_SCHED|CONFIG_FAIR_GROUP_SCHED|CONFIG_CFS_BANDWIDTH' /boot/config-$(uname -r)如果是 is not set，恭喜，cgroup CPU 限额对你这台机器就是摆设。多数发行版默认是开的，但精简版内核（云厂商自定义镜像、容器宿主机）经常被阉割。
⚙️ 关键参数详解：period / quota / burst
cgroup v1 下，CPU 限额在 cgroupfs 里体现为这几个文件：
举个栗子：设 cpu.cfs_period_us=100000、cpu.cfs_quota_us=50000，意思就是每 100ms 周期内最多用 50ms CPU——也就是 0.5 个 CPU。Docker 的 --cpus=0.5 底层就是这么算的。
再看内核里的硬性限制（kernel/sched/fair.c）：
const u64 max_cfs_quota_period = 1 * NSEC_PER_SEC; /* 1s */const u64 min_cfs_quota_period = 1 * NSEC_PER_MSEC; /* 1ms *//* tg_set_cfs_bandwidth() 里 */if (quota < min_cfs_quota_period || period < min_cfs_quota_period) return -EINVAL; // 小于 1ms 直接拒绝if (period > max_cfs_quota_period) return -EINVAL; // 超过 1s 也拒绝这就是为啥你写 500us quota 会被内核打回来报错——不在合法区间。
🛠️ 手把手实战：手动配 cgroup CPU 限额
别只盯着 Docker 命令行操作，直接玩 cgroupfs 才能看清底层。咱们来手动给一个进程设 0.5 核：
第一步，挂载 cgroup 文件系统（v1）：
mount -t tmpfs cgroup_root /sys/fs/cgroupmkdir /sys/fs/cgroup/cpumount -t cgroup -ocpu none /sys/fs/cgroup/cpu第二步，创建 cgroup 并设限额：
cd /sys/fs/cgroup/cpumkdir myapp# 周期 100ms，配额 50ms = 0.5 核echo 100000 > myapp/cpu.cfs_period_usecho 50000 > myapp/cpu.cfs_quota_us# 进程加入 cgroupecho $$ > myapp/tasks第三步，验证限额是否生效。最简单的方法：写个死循环脚本，观察 CPU 占用是否稳定在 50% 左右：
# 当前 shell 已经进入 myapp cgroup，直接跑死循环while true; do :; done &top -p $!你会看到 CPU 稳稳卡在 50%，再多一秒都给不了。这就是 throttle 的视觉效果。
📊 throttle 监控：生产环境排雷必备
限额生效了，但你想知道到底被掐了几次、掐了多久？看 cpu.stat 文件：
cat /sys/fs/cgroup/cpu/kubepods/pod<pod_id>/cpu.statnr_periods 1312889nr_throttled 100714throttled_time 22081774986248几个关键指标：
| | |
|---|
| | |
| | throttle 比例 = nr_throttled / nr_periods |
| | |
如果 throttle 比例长期 >10%，基本可以判定：要么配额设小了，要么业务真的有突发 CPU 需求，这时候要么扩 quota，要么上 burst（5.15+ 内核新特性）。
🧪 实战压测：Go 程序验证 throttle 行为
光说不练假把式。咱们用 Docker 跑一段 Go 代码，亲眼看下配额是否真的生效。代码逻辑很简单：每次循环 burn 5ms CPU，然后 sleep 10ms，记录实际耗时：
package mainimport ( "crypto/sha512" "flag" "log" "syscall" "time")func main() { sleep := flag.Duration("sleep", time.Second, "sleep between iterations") iterations := flag.Int("iterations", 100, "number of iterations") flag.Parse() time.Sleep(time.Second) b := time.Now() for i := 0; i < *iterations; i++ { s := time.Now() burn(time.Millisecond * 5) e := time.Since(s) log.Printf("[%d] burn took %dms, real: %dms, cpu: %dms", i, ms(e), ms(time.Since(b)), ms(usage())) time.Sleep(*sleep) }}func ms(d time.Duration) int { return int(d.Nanoseconds() / 1000 / 1000)}func burn(d time.Duration) { s := time.Now() for { sum := sha512.New() sum.Write([]byte("banana")) sum.Sum([]byte{}) if time.Since(s) > d { break } }}func usage() time.Duration { r := syscall.Rusage{} syscall.Getrusage(syscall.RUSAGE_SELF, &r) return time.Duration(r.Stime.Nano() + r.Utime.Nano())}场景一：不设限额（quota 充足），不会触发 throttle：
dk run --rm -it -v $(pwd):$(pwd) -w $(pwd) golang:1.19.4 \\ go run cfs.go -iterations 20 -sleep 10ms输出：每次 burn 稳定 5ms，real time 跟 cpu time 同步增长，没任何延迟。
场景二：设紧配额 --cpu-quota=25000 --cpu-period=100000（0.25 核），throttle 立刻显现：
dk run --rm -it --cpu-quota=25000 --cpu-period=100000 \\ -v $(pwd):$(pwd) -w $(pwd) golang:1.19.4 \\ go run cfs.go -iterations 20 -sleep 10ms输出里 burn took 出现 11ms、20ms 这种明显跳变——这就是 throttle 的代价：进程实际被挂起，等下个 period 才能继续跑。real time 涨得飞快，cpu time 涨得慢。
🪤 生产环境踩坑清单
坑一：多核容器的 quota 误区
Docker run 一个容器时，--cpus=2 实际是 --cpu-quota=200000 --cpu-period=100000。但这个 200ms 是整个容器在 100ms 周期内跨所有核的总配额，不是每个核的。如果容器跑在 8 核机上，可以瞬时吃 2 个核，但也可能单核吃满另 7 核完全闲置——多核下会出现短时间集中 throttle。
坑二：shares vs quota 傻傻分不清
shares 是相对权重（容器竞争 CPU 时的比例），quota 是绝对上限。一个设 shares=2048、quota=-1 的容器，机器空闲时照样能跑 100%，但机器挤时只能拿到 2 倍份额。生产环境想保业务不饿死，quota 必须设。
坑三：min_granularity 没调
CFS 有个 sched_min_granularity_ns（5.15+ 在 /sys/kernel/debug/sched/min_granularity_ns）控制最小时间片。过载情况下时间片如果掉到 1ms 以内，光上下文切换的开销就能吃掉所有 CPU。跑高并发服务的机器，把这个值适当调大（比如 4ms~8ms），能显著降低调度开销。
坑四：cgroup v1 和 v2 混用
新内核默认走 cgroup v2 unified hierarchy，配置文件路径全变了（cpu.max 取代 cpu.cfs_quota_us）。如果你按老教程抄命令发现路径不存在，先确认 mount 的 cgroup 版本。
🎯 工业级场景：什么时候该用 CFS Bandwidth
✔️ 公有云/容器租赁：按 CPU 时间计费，必须硬限，不然用户把核跑满你收不到钱。
✔️ K8s Pod 资源限制：resources.limits.cpu 底层就是这玩意儿。
✔️ 混部场景：在线业务和离线任务跑同一台机器，离线任务配 quota=0.5 防止它抢在线的 CPU。
❌ 低延迟交易/实时音视频：别用 quota，这种业务用 SCHED_FIFO/SCHED_RR 实时调度更靠谱。RT 调度有自己的带宽控制（CONFIG_RT_GROUP_SCHED），但配置复杂，且一旦配错可能把整个系统锁死。
❌ 纯计算批处理：闲着也是闲着，不如让 CFS work-conserving 跑满，何必自己卡自己。
📚 资料出处
本文所有数据来自 Linux 内核源码（v5.10，github.com/torvalds/linux），重点参考了 kernel/sched/fair.c 和 init/Kconfig，关键 commit：
https://github.com/torvalds/linux/commit/ab84d31e15502fb626169ba2663381e34bf965b2# sched: Introduce primitives to account for CFS bandwidth tracking核心数据结构在 include/linux/sched.h 和 kernel/sched/sched.h 里，有兴趣的兄弟直接看源码，注释写得很透。
🤔 最后说两句
调度器这玩意儿，90% 的开发者一辈子用不上底层，但踩坑的时候往往一脸懵——业务突然延迟飙升、监控看着 CPU 没满却卡成狗，这时候去翻 cpu.stat 看 throttled_time，定位效率比瞎猜快十倍。
所以别只记 docker run --cpus=2 这条命令，把它背后的 vruntime 红黑树、cgroup 层级、throttle 机制搞清楚，才能在容器云、混部、Serverless 这些场景里不被坑。
你的生产环境踩过 CFS/throttle 相关的坑吗？cpu.cfs_quota_us 怎么设的？评论区聊聊？
10个月宝宝每天需要喝多少奶粉？
