深入理解cgroups：从CPU内存限制到容器资源治理实战

在做容器相关的工作时，我最常被问到的问题不是“镜像怎么构建”，而是“进程明明进了容器，为什么 CPU 还是被打满”“内存限制设了 2G，怎么容器里面只看到 1.5G 就 OOM”。这些问题的答案，基本都落在 Linux 内核的 cgroups 机制上。这个系列前面几篇把命名空间、文件系统、网络栈翻了个遍，这次终于轮到 cgroups。因为 cgroups 本身内容足够深，我打算拆成上下两篇来写，这一篇先把整体设计、核心子系统和实验过程讲清楚，下一篇再往控制器内部和性能建模方向深入。

这篇文章适合谁看？适合所有想让容器从“能用”走到“用得稳”的开发者、运维和平台工程师。如果你只是想写 Dockerfile，那确实不需要关心 cgroups；但如果你想排查容器内存抖动、给离线任务做 CPU 弹性配额、或者在自研运行时里做资源管理，那 cgroups 就是绕不开的地基。我会尽量把原理讲明白，同时给你可以直接在 Linux 上敲的命令。

1. 读懂 cgroups 之前，先理清容器资源控制的“设计骨架”

1.1 命名空间是“障眼法”，cgroups 才是“计量表”

很多人一开始接触容器，会觉得“容器就是轻量虚拟机”，这个类比有道理，但也有个致命误导：命名空间（namespace）只能让容器里的进程“看不见”宿主机上的其他东西，比如看不到别的进程、看不到宿主机的网络栈、看不到外部挂载点。但“看不见”不等于“管得住”。

打个比方：酒店给每个房间装了隔断，房间里的人看不到隔壁房间在干什么，但如果你在房间里半夜开大功率音响，整栋楼都会被吵醒。宿主机也一样，一个容器里的进程如果疯狂吃 CPU、疯狂写内存，其他容器、甚至宿主机本身的进程都会被拖垮。命名空间负责“隔断”，cgroups 负责“计量”和“限流”。

cgroups 的英文全称是 control groups，翻译过来就是“控制组”。它的本质是把一组进程归到一个组里，然后针对这个组设置资源上限、做资源统计、控制优先级。你可以把它理解成一个水电表：每个容器都接了一根独立的管道，管道上装了流量计和阀门，cgroups 就是那套阀门拧到哪里、表上读数是多少的实现机制。

1.2 两大版本：v1 与 v2 的设计哲学差异

cgroups 不是一次成型的，它经历了两代设计。第一代也就是 cgroups v1，是在 Linux 2.6.24 合入的，当时的设计思路是“每个子系统一个独立的挂载层级”。所谓子系统（subsystem），指的是 cpu、memory、pids、blkio、cpuset 这些资源控制器。v1 允许你把 cpu 子系统挂载到一个目录，memory 子系统挂载到另一个目录，一个进程可以同时存在于多个层级的不同路径之下。

这个设计非常灵活，但灵活过头了。实际用起来你会遇到一个很尴尬的情况：一旦多个子系统各自为政，想表达“这组进程同时受到 CPU 和内存双重限制”就很费劲，因为你得在多个挂载点下维护同一批进程的路径。如果路径不同步，CPU 的配置和内存的配置就难以保证一致性。内核社区花了很大力气去做 v2，也就是 cgroup v2，它在 4.5 版本开始合并，目标很明确：把所有控制器统一挂到一棵树下面，层级关系全局唯一，通过内部进程限制来简化统计模型。

现代发行版比如 RHEL 9、Ubuntu 22.04 的内核版本都已经默认支持 v2，大部分云厂商的节点镜像也切换到 v2 了。但生产环境里还有大量老节点在跑 v1，所以作为从业者，两套接口你都得看得懂。后面我会专门用一节来对比它们的行为差异。

1.3 在容器体系中，cgroups 位于哪一层

我们用 Docker 或者 containerd 跑容器的时候，表面上看到的是镜像和层，但真正落到内核里，容器进程被放进两套机制：一个是命名空间，负责隔离视图；另一个就是 cgroups，负责限额与统计。你执行docker run -m 512m这类命令时，容器运行时最终做的事情就是：在 cgroup 文件系统里创建一个目录（cgroup 节点），往里面写入限制数值，然后把进程 PID 写进cgroup.procs，让这个进程落到这个组里。

理解这个层级关系，对排障特别有用。你可以在容器里执行cat /proc/self/cgroup，会看到类似这样的输出：

0::/system.slice/docker-xxxx.scope

这个路径就是容器进程当前所属的 cgroup。如果它显示的是 v1 时代的:/docker/xxxx加一堆子系统路径，说明节点跑的还是 cgroups v1。这个文件是排障时第一个该看的，因为很多资源异常都和你进程实际落在哪个组有关。

2. 核心子系统逐一拆解：CPU、内存、Pids 与 IO 到底在管什么

2.1 CPU 子系统：从“按份分”到“按时间片分”

CPU 子系统是容器 CPU 限额的底层实现。在 cgroups v1 中，它有两类核心控制文件：cpu.shares和cpu.cfs_period_us、cpu.cfs_quota_us。这两类文件的语义完全不同，一个是相对权重，一个是绝对上限。

cpu.shares表示这个 cgroup 在 CPU 繁忙时能获得的权重比例。假设有容器 A 的 shares 是 1024，容器 B 的 shares 是 512，当两个容器同时在跑满 CPU 的任务时，A 拿到的 CPU 时间大约是 B 的两倍。但注意：如果 CPU 很空闲，两个容器的任务都可以用满 CPU，shares 不会限制你跑到 200%，因为没人跟你抢。所以 shares 解决的是“分蛋糕”问题，不是“禁止吃超过多少”的问题。

cpu.cfs_period_us和cpu.cfs_quota_us则是真正意义上的“可以吃掉多少 CPU”。它们配合 CFS 调度器的一段时间窗口机制工作。period是窗口周期，单位是微秒，默认通常是 100000（也就是 100 毫秒）；quota是这个周期内该组进程最多可运行的微秒数。假如你设置：

echo 100000 > /sys/fs/cgroup/cpu/cpu.cfs_period_us echo 150000 > /sys/fs/cgroup/cpu/cpu.cfs_quota_us

这就代表在每 100 毫秒的窗口里，组内所有进程合计最多只能跑 150 毫秒的 CPU 时间，等价于最多占用 1.5 个 CPU 核心。为什么虚拟化平台里经常说“限制 1.5 核”，原理就在这里：不是真的只给 1.5 核，而是让调度器保证该组进程平均使用率不超过 1.5。

这里有个实际经验：quota 不一定要在单个窗口内被用完，内核允许某段时间内“突击使用”配额，但长时间平均下来会贴近配额。你设了 1.5 核，任务在 50 毫秒的脉冲内可以瞬间吃掉 2 核甚至更多，但后面会被调度器压制，整体长期均值受影响。你要的是“稳定 QoS”还是“允许突发”，决定了这两个文件的配置策略。

2.2 memory 子系统：不是简单记账，是回收与 OOM 的博弈

memory子系统是生产环境里排查容器内存问题的重点，也是最容易踩坑的地方。v1 下主要的文件是memory.limit_in_bytes和memory.usage_in_bytes。v2 下对应变成了memory.max和memory.current，名字变了，语义大致相当，但细节多了不少。

当你把memory.limit_in_bytes设置成 2G，这个数值表示组内所有进程可以使用的“内核视角内存”上限。注意这个“内核视角内存”包含几部分：匿名页（进程堆栈）、文件页（文件读写产生的 page cache）、内核对象碎片等。也就是说，如果容器里大量读写文件，文件缓存也会被记到这个统计里。这会造成一个非常常见的困惑：容器里的free明明显示内存很充裕，宿主机却因为该 cgroup 超过限制而触发 OOM，把进程杀了。

内核处理 cgroup 内存超限的流程是这样的：当进程尝试分配新内存，超过 limit 之后，内核先尝试回收这个 cgroup 内的可回收页，比如干净的 page cache、可换出的匿名页。如果回收完还是无法满足分配，就会走向强制回收或者触发 OOM Killer。cgroups v1 提供了memory.oom_control，把值从 0 改成 1 后，组内触发 OOM 时内核不会立刻杀进程，而是让分配内存的任务进入休眠等待。听起来像是“免死金牌”，但注意：这会导致进程 hang 住，并不是被放行。实际生产中你要是发现容器状态变成不可中断的 D 状态，也要检查是不是这个原因。

另一个关键点是 OOM 评分。内核在决定杀哪个进程时，会结合进程本身的内存占用和它所在 cgroup 的份额做权衡。你可以通过/proc/<pid>/oom_score看到当前评分，数值越大越容易被杀。容器平台在设置memory.limit后，内核会动态调整组内进程的 OOM 评分，这就是为什么有时候被杀的进程不是内存占用最大的那个，而是“在受限 cgroup 里”的进程。

2.3 pids、blkio 与 cpuset：不常用但关键时刻救命的控制器

CPU 和内存是最常被配置的，但 pids 和 blkio 也不该忽略。pids 控制器非常好理解：pids.max限制该 cgroup 内可以创建的进程/线程总数。默认是 max，也就是不限制。但在跑 Java 应用、或者某些中间件 fork 大量线程时，这个限制能挡掉一次典型的线程风暴。要注意的是，它统计的是“任务数量”，也就是每个线程算一个。一个进程开 100 个线程，就占 100 个计数。

blkio 控制器在 v1 里叫 blkio，在 v2 里叫 io。它管的是磁盘读写带宽和 IOPS。v1 提供blkio.weight（权重，范围 10-1000）和blkio.throttle.read_bps_device这类绝对上限。v2 则用io.weight（范围 1-10000）配合比例调度。真实落地上，这类控制器的效果明显弱于 CPU/内存，原因是磁盘 IO 经过页缓存和内核异步回刷后，“到底算在哪个进程头上”并没有想象中那么精确。比如一个容器写完文件就退出，脏页可能由内核的flush线程回刷，这时候 IO 会被记账到flush线程所属的 cgroup，而不是原来的容器。所以我在生产环境一般不会只靠 blkio 做严格磁盘隔离，通常需要配合文件系统层限流或者 Storage QoS 方案。

cpuset 控制器是另一个值得专门留意的，它负责把容器固定到某几个 CPU 核心上，在 NUMA 环境下还能做内存节点亲和性。它的配置不是数值，而是 CPU 列表，比如：

echo 0-3 > cpuset.cpus

把 cgroup 里的进程绑定到 0 到 3 号核心。这对低延迟应用非常重要，因为 CPU 亲和性可以减少调度器迁移带来的缓存抖动。

3. v2 统一层级：这次大修解决了 v1 的哪些真实痛点

3.1 v1 的“多个挂载点”为什么让人抓狂

我在日常排障中见过太多因为 v1 多挂载点导致的困惑。举例来说，一台老节点上你可能会看到：

/sys/fs/cgroup/cpu/docker/abc /sys/fs/cgroup/memory/docker/abc /sys/fs/cgroup/pids/docker/abc

同一个容器，在三个不同子系统下都有路径。如果这个容器是被 Docker 管理的，路径还能保持一致；但如果有些组件直接操作 cgroup，或者 systemd 的 slice 体系掺和进来，CPU 路径和历史路径就容易对不上。这时候你和同事排查“为什么这个进程的 CPU 限制在内存路径里看不到”，会非常痛苦。

v1 更大的设计问题是不能有效地处理“层级之间的相互作用”。比如内核想把 CPU 调度、内存回收和 IO 回刷放在一起联动，比如当 cgroup 内存紧张开始回收脏页时，应该同时降低该 cgroup 的 IO 权重，避免大量回刷把磁盘打爆。这种跨控制器协同在 v1 里几乎没法做，因为各个控制器分散在不同层级，没法快速找到一个完整的组视角。

3.2 v2 的核心规则：内部进程必须为空

cgroups v2 最关键的规则叫 “No Internal Processes”，也就是非叶子节点不能直接放进程。一个 cgroup 内部要想“装进程”，它必须是叶子节点，不能同时拥有子 cgroup 和自己的进程。

这条规则一开始看着有点别扭，但它其实是在用约束换统计简洁。v1 里一个父 cgroup 可以同时有自己的进程和子 cgroup，父层的统计数据到底是只算自己，还是算自己加上后代？不同控制器答案还不一样，非常容易算重或者算漏。v2 强制把进程放到叶子节点后，每个非叶子节点的memory.current、cpu.stat天然就是其所有后代的总和。这叫“自上而下的统计一致性”。

实际用起来，这意味着你新建一个配置树时，要注意把进程写到最下层的cgroup.procs而不是中间层。如果你尝试往一个已经有子目录的 cgroup 里写 PID，会直接收到EBUSY错误。这类报错在初学 v2 时几乎必然遇到，记住“当前目录有子目录就不能直接放入进程”这条规则就行。

3.3 容器场景下怎么选版本

容器运行时对 cgroups 版本的适配也走过一段路。老版本 Docker 默认跑 v1，新版本和 containerd 新版本都优先探测 v2。你在部署新集群时，如果内核版本高于 4.15，我建议直接开启 v2，安装脚本把/sys/fs/cgroup挂载成 cgroup2 类型即可。v2 的接口更统一，后续想接 eBPF 做资源观测也更容易。

但如果你维护的是老集群，还是得老老实实看 v1。两套接口的差异不大，主要是文件名的变化，我列一个对照表：

让我解释一下 CPU 上下两个接口的区别：v2 的cpu.max把两个值合并成了一个文件，比如echo "150000 100000" > cpu.max，它的意思是 quota=150000、period=100000，与 v1 设置两个文件完全等效。用新接口的好处是，你写入和读取都是一整个配置，不会出现“只改了 period 忘了 quota”这种半配置状态。

4. 动手实操：亲手创建一个 cgroup 完成内存与 CPU 限制实验

4.1 先确认当前系统的 cgroups 版本

理论说再多，不如上手敲一遍。我建议你准备一台 Linux 虚拟机（内核 5.10 以上）。第一步是确认当前挂载的是 v1 还是 v2：

mount | grep cgroup

如果输出里有cgroup2且/sys/fs/cgroup是cgroup2类型，那就是 v2；如果输出里有cgroup类型的多个挂载点，比如cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)，那说明是 v1。用 systemd 的发行版通常会在/sys/fs/cgroup挂一个统一目录，下面再按子系统分目录。

在 v2 系统上，我们可以直接用systemd的接口，也可以手工操作。这里我选择手工操作，更能看清本质。首先挂载 cgroup2 到临时目录：

mkdir -p /mnt/cg2 mount -t cgroup2 none /mnt/cg2

这样就能得到一个干净的 cgroup2 文件系统。

注意：生产环境不要手工乱挂 cgroup2，因为 systemd 已经占用了/sys/fs/cgroup，重复挂载可能干扰节点上的容器运行时。实验请在虚拟机里做。

4.2 创建带内存限制的 cgroup，并放入一个进程

在/mnt/cg2下新建目录，目录名就是 cgroup 名：

mkdir /mnt/cg2/demo

此时这个目录里会出现一堆控制器接口文件。我们来设置内存上限为 128M：

echo 134217728 > /mnt/cg2/demo/memory.max

数字 134217728 等于 128 * 1024 * 1024 字节。接下来把当前 shell 放入这个组：

echo $$ > /mnt/cg2/demo/cgroup.procs

注意，因为/mnt/cg2/demo没有子目录，所以它允许直接放入进程。写入后，当前 shell 以及后续启动的所有子进程都会受到 128M 内存限制。这一点很关键：把 shell 放进去之后，你在 shell 里执行的任何程序和脚本，都自动属于这个 cgroup。

现在用一个工具来制造内存压力。先看系统有没有stress-ng，没有就装一下。然后运行：

stress-ng --vm 1 --vm-bytes 256M --vm-hang 10

这个命令会创建 1 个进程，尝试分配 256M 内存并挂住。因为我们设了 128M 上限，它很快就会触发 cgroup 级别的内存回收，并最终触发 OOM。观察dmesg输出，你会看到：

memory: cgroup out of memory Killed process ...

这正是 cgroups 第一层保护在起作用。如果你把memory.oom.group设为 1，这个 cgroup 内所有进程都会被一起杀掉，否则只杀其中得分最高的那个进程。

4.3 限制 CPU 实验：设置 quota 再观察负载

还是基于刚才的democgroup，把 CPU 配额设置成 0.5 核：

echo "50000 100000" > /mnt/cg2/demo/cpu.max

然后在该 shell 里启动一个计算密集任务：

stress-ng --cpu 2 --timeout 10

stress-ng会尝试把 2 个 CPU 跑满，但因为 cgroup 限制，整个组最多只能获得 0.5 核的平均 CPU 时间。开另一个终端，用top观察：你会看到虽然stress-ng启动了 2 个进程，两者的 CPU 使用率加起来却始终徘徊在 50% 左右。

这个实验结果非常直观地展示了 quota 的作用：哪怕进程请求再多的调度愿望，内核的 CFS 带宽控制都会按住它。如果你把cpu.max重新改成"max 100000"，限制立刻解除，CPU 使用率就能冲上去。注意这里max是特殊值，表示不限制。

4.4 清理实验环境：cgroup 的删除不是简单删目录

实验做完要清理。先让进程退出，或者手动把所有 PID 从cgroup.procs里移除：

echo "" > /mnt/cg2/demo/cgroup.procs

然后再删除目录。如果目录里没有任何子目录且没有进程引用，可以用rmdir删除：

rmdir /mnt/cg2/demo

如果删除失败，报Device or resource busy，几乎可以确定还有进程停留在这个 cgroup 里。这时候用cat /mnt/cg2/demo/cgroup.procs看看还有谁，把它踢到根组去再删。这个习惯在公司里尤其重要：手动创建的 cgroup 泄漏，会导致旧资源统计一直挂在内存里，还会造成宿主机上的资源“去向不明”。

5. 生产环境排障与避坑：cgroups 最常见的几个坑

5.1 内存“超限”但没触发 OOM，先看 file cache

有个现象我见过很多次：容器限制 4G 内存，memory.current已经 3.9G，但容器内free显示可用内存还有 3 个 G，也没 OOM。不用觉得内核算错了，真相大概率是 page cache 在作怪：容器内读文件时，内核把文件内容放进了 page cache，这些页虽然可以被回收，但在被回收之前会计入当前 cgroup 的memory.current。

排查思路是这样的：先看memory.stat文件里的anon和file两个值。anon是真正的匿名内存（堆、栈、共享内存），file是文件内存。如果file占比很高，说明内存消耗集中在文件缓存，这类内存理论上可以被回收，不会马上压垮节点。但要注意，如果脏页太多，回收时需要先回写磁盘，回写期间进程依然会感觉到内存压力，吞吐会明显下降。

经验之谈：不要尝试在生产环境用echo 3 > /proc/sys/vm/drop_caches来强行清缓存，那会影响宿主机全局。更合理的做法是调整这个 cgroup 内文件读写方式，或者通过监控区分anon与file的增长趋势，再判断到底是业务内存泄漏还是缓存波动。

5.2 cgroup 目录删不掉，很可能是僵尸进程或内核引用

前面实验里rmdir失败算是温和的；生产环境里能看到docker rm半天删不掉容器，或者在 cgroup 目录里写进程 PID 时总报No space left on device。这种往往不是磁盘满了，而是节点上的 cgroup 层级已经膨胀：容器频繁创建删除，产生了大量残留 cgroup。

有一次我排查一个节点，发现systemd-cgtop里有个服务已经停掉，但它的 cgroup 目录还在，里面挂着几十个已经变成僵尸状态的进程。这些僵尸进程的父进程一直在循环回收失败，导致它们始终占着 cgroup 里的名额。我的处理办法是先找到它们的父进程，用ps -ef查看 PID，把父进程重启后，操作系统自动回收了这些僵尸进程，cgroup 目录随即可正常清理。

这类问题的根子是“谁创建 cgroup 就得谁负责清理”。手工创建的 cgroup 特别容易泄漏，所以我建议：生产环境凡是需要自定义 cgroup 的功能，尽量走 systemd 的systemd-run --scope或者systemd-run --unit=xxx --slice=xxx，让 systemd 来管理生命周期，不推荐直接往/sys/fs/cgroup里写文件。systemd 至少会在服务退出时尝试清理，能省掉很多手尾。

5.3 常见问题速查表

5.4 几个值得养成的设计习惯

在容器平台的后端设计里，我建议把这几点当默认约束。第一，不要在业务进程里自己挂 cgroup，而是由容器运行时或 systemd 统一管理，这样生命周期和异常恢复都有依托。第二，监控数据一定要区分 cgroups v1 和 v2 的指标来源，文件名一样但语义可能有差异，比如 v2 的cpu.weight和 v1 的cpu.shares数值范围完全不同，误以为是同一种波动范围会导致告警规则失效。第三，在设置内存限制时，最好给memory.swap.max也留位置，如果节点用了 swap，你只限制内存不限制 swap，高负载时容器会把 swap 吃穿，造成更隐蔽的延迟问题。

我在实际操练这个系列的过程中，最大的体会是：cgroups 的接口虽然只是读写文件而已，但内核在背后做的事情极其讲究。write()一次文件操作，可能触发一次全节点调度器的重新计算，也可能触发一次内存回收风暴。它不是普通的“配置文件”，而是一套操作系统资源治理的接口。理解了这一点，你会对 Linux 的“一切皆文件”哲学多一层敬畏。

这一篇先讲到这里。cgroups 的上半场内容集中在“它是什么、为什么这么设计、怎么快速上手”。下一篇我准备继续深入cpuset与 NUMA 亲和、cpu.weight的 CFS 调度语义、io.weight与磁盘回写路径，以及如何通过 eBPF 观测 cgroup 内部指标。如果你想在团队里做容器资源治理，建议先把这个系列 1-6 篇连起来读，至少能把“容器限制”从黑盒变成白盒。