Cgroup 原理与容器资源限制实战：CPU、内存、IO 配置及 OOM 排查

1. 从一次容器集体雪崩说起为什么必须搞懂 Cgroup去年冬天我们一个跑了两年多的推荐服务突然在凌晨两点集体雪崩。监控面板上二十多个容器实例的 CPU 使用率同时飙到 100%内存曲线像被拉直的绳子一样顶在 limit 线上紧接着 OOM Killer 开始挨个点名Pod 一个接一个重启整个集群在十分钟内彻底失去响应。事后复盘根因简单得让人想骂人一个负责离线特征回填的批处理任务被误部署到了在线服务的节点上它没有任何资源约束像一头闯进瓷器店的野牛把整台物理机的 CPU 和内存吃干抹净。那次事故之后我把团队所有容器的资源限制配置从头到尾梳理了一遍也真正把 Cgroup 这套机制从会用逼到了懂原理。这篇文章就是那次梳理的产物。如果你正在用 Docker、Kubernetes 或者任何容器化方案却对--cpus、--memory、cpu.shares、memory.limit_in_bytes这些参数背后的逻辑一知半解那这篇内容就是写给你的。我会从 Cgroup 的底层结构讲起把 CPU 配额、内存限制、IO 控制这几块拆开揉碎再结合容器运行时的实际配置给你一套可以直接抄作业的参数模板和排查方法。先说清楚 Cgroup 到底是什么。它是 Linux 内核提供的一套机制用来对进程组做资源限制、优先级分配、资源统计和任务控制。注意这里的关键词是进程组——它不是针对单个进程而是把一组进程当成一个整体来管理。这个设计非常关键因为容器本质上就是一组被隔离的进程Cgroup 正好提供了把这组进程的资源用量框住的能力。没有 Cgroup容器就只是一个换了根目录的普通进程谈不上任何资源保障。Cgroup 在 2006 年左右由 Google 的工程师提出并合入内核最初叫 process containers后来改名 control groups简称 cgroups。它经历了 v1 和 v2 两个大版本v1 是多个子系统各自为政v2 做了统一层级。目前主流发行版和容器运行时大多还在用 v1但 v2 的推进速度在加快新一点的系统比如较新的 Fedora、Ubuntu 已经默认挂载 v2。这个版本差异会直接影响你看到的目录结构和参数名后面我会专门讲怎么判断和适配。理解 Cgroup 有一个特别形象的类比把它想象成公司里的部门预算制度。每个部门Cgroup有自己的人力编制上限pids、办公面积上限memory、用电额度cpu、报销额度blkio。部门内部怎么分配是部门自己的事但总额不能超。超了会怎样用电超了会被拉闸CPU throttling办公面积超了会被清退工位OOM Kill。这个类比能帮你记住大部分行为逻辑。对做容器的人来说Cgroup 的价值体现在三个层面。第一是隔离性防止一个服务把整台机器拖垮这是最基础的诉求。第二是可预测性通过配额让服务的性能表现稳定不会因为邻居的波动而抖动。第三是成本核算通过资源统计做容量规划和计费。很多人只关注第一点但真正在生产环境跑久了你会发现后两点才是决定系统能不能长期稳定运行的关键。2. Cgroup 的目录结构与子系统先搞清楚你在操作什么2.1 v1 与 v2 的目录差异以及怎么判断当前系统用的是哪个在动手配置之前你必须先确认自己面对的是哪个版本因为两者的操作方式完全不同。判断方法很简单直接看挂载点mount | grep cgroup如果输出里出现cgroup2或者/sys/fs/cgroup直接挂载为cgroup2类型那就是 v2。如果看到一堆cgroup类型、分别挂载在/sys/fs/cgroup/cpu、/sys/fs/cgroup/memory这样的子目录下那就是 v1。v1 的结构是一个子系统一个挂载点每个子系统独立管理一棵进程树。这意味着同一个进程可以同时属于 CPU 子系统的 A 组和内存子系统的 B 组配置起来灵活但容易混乱。v2 则强制统一所有控制器挂在同一棵树上一个进程在树里的位置决定了它所有资源的归属逻辑更清晰但迁移时会有兼容问题。我遇到过最坑的情况是宿主机是 v1但容器镜像里装的工具默认按 v2 的路径去读结果监控数据全是空的。所以无论你用什么监控方案第一步永远是确认版本。2.2 核心子系统逐个拆解cpu、memory、blkio、pids 各管什么Cgroup 的能力由各个子系统controller提供常用的有这几个子系统作用关键文件v1关键文件v2cpuCPU 时间分配与配额cpu.cfs_quota_us、cpu.sharescpu.max、cpu.weightcpuset绑定特定 CPU 核心与内存节点cpuset.cpus、cpuset.memscpuset.cpus、cpuset.memsmemory内存用量限制与统计memory.limit_in_bytesmemory.max、memory.highblkio块设备 IO 限速blkio.throttle.read_bps_deviceio.maxpids进程数量限制pids.maxpids.maxfreezer冻结/恢复进程组freezer.statecgroup.freezecpu子系统管的是 CPU 时间不是核心数。这点特别容易搞混。你设--cpus2并不是真的给它两个物理核心而是给它相当于两个核心的计算时间配额。cpuset才是真正绑定核心的它决定进程只能在哪些核上跑。生产环境里对延迟敏感的服务通常用 cpuset 绑核对吞吐敏感的服务用 cpu 配额。memory子系统管内存包括 RSS、page cache 等。这里有个大坑page cache 也算在内存用量里。所以一个大量读写文件的服务即使实际堆内存很小也可能因为 page cache 撑爆 limit 被 OOM。后面会详细讲怎么处理。blkio管磁盘 IO 的带宽和 IOPS对数据库类服务很重要。pids管进程数能防止 fork 炸弹。freezer用于批量暂停进程容器暂停功能就靠它。2.3 层级树与进程归属一个进程只能有一个家Cgroup 是一棵树每个节点叫一个 cgroup进程挂在树的某个节点上。在 v1 里一个进程在每个子系统树里各有一个位置在 v2 里所有子系统共用一棵树进程只有一个位置。这个树的结构决定了资源继承关系。子 cgroup 默认继承父 cgroup 的限制但可以设置得更严格。比如父组限制 4 核子组可以限制 2 核但不能超过 4 核——除非父组本身没设限制。查看某个进程属于哪个 cgroupv1 下可以这样cat /proc/pid/cgroup输出会列出该进程在各个子系统中的路径。v2 下输出只有一行格式是0::/路径。理解归属关系对排查问题至关重要。有一次我们一个服务莫名其妙被限流查了半天发现是它被错误地挂到了一个设置了 CPU 配额的父 cgroup 下继承了父组的限制。这种问题不看树结构根本找不到。3. CPU 配额shares、quota、period 到底怎么配合3.1 cpu.shares 是权重不是上限这个误解坑了太多人cpu.sharesv2 里叫cpu.weight是最容易被误解的参数。它的默认值是 1024作用是在 CPU 资源竞争时决定分配比例而不是限制上限。举个例子两个 cgroupA 的 shares 是 1024B 的 shares 是 512。当两个组都在满负荷跑、CPU 不够分时A 能拿到大约 B 两倍的 CPU 时间。但如果 B 闲着A 可以独占整个 CPU哪怕它的 shares 只有 1024。这就是权重和上限的本质区别。很多人以为给容器设了--cpu-shares512就能限制它只用半个核结果发现它照样能跑满然后一脸懵。记住shares 只在竞争时生效不竞争时形同虚设。要真正限制上限得用 quota。3.2 cfs_quota_us 与 cfs_period_us硬上限的计算逻辑CPU 硬限制靠cpu.cfs_quota_us和cpu.cfs_period_us这一对参数。period是统计周期默认 100000 微秒也就是 100msquota是在这个周期内允许使用的 CPU 时间总量。计算方式很直接允许使用的核心数 quota / period。想限制用 1 个核quota 100000period 100000想限制用 2 个核quota 200000period 100000想限制用 0.5 个核quota 50000period 100000在 Docker 里--cpus1.5会被运行时自动换算成 quota150000、period100000。Kubernetes 里的resources.limits.cpu: 1500m也是同样的换算。这里有个细节值得注意quota 可以超过 period 的整数倍比如 quota250000、period100000 就是 2.5 个核。但 period 不建议随便改默认 100ms 是经过大量实践验证的平衡点。改小会让限流更精细但调度开销变大改大会让突发流量更容易被允许但延迟毛刺更明显。3.3 CPU throttling 的真相为什么你的服务延迟会周期性抖动设了 quota 之后最常见的现象就是周期性延迟抖动。原因是当容器在一个 period 内用完了 quota它会被强制刹车直到下一个 period 开始才能继续跑。这个刹车动作就是 throttling。假设你的服务每个请求需要 10ms CPU 时间quota 设的是 1 核100000/100000。理论上一个 period 能处理 10 个请求。但如果这 10 个请求集中在 period 的前 50ms 全部到达它们会把这 100ms 的配额在前 50ms 内耗尽然后剩下的 50ms 里所有请求都被 throttle延迟直接翻倍。排查 throttling 的方法# v1 cat /sys/fs/cgroup/cpu/group/cpu.stat # 关注 nr_throttled 和 throttled_time如果nr_throttled持续增长说明你的服务在被频繁限流。这时候要么提高 quota要么优化代码降低 CPU 消耗要么调整 period 让配额分布更均匀。我的经验是对延迟敏感的服务quota 要留 30% 以上的余量。别卡着实际用量设否则流量稍微一波动就开始 throttle。3.4 绑核cpuset与配额quota该选哪个这是另一个高频困惑点。简单说cpuset 绑核进程只在指定核心上运行能获得更稳定的缓存局部性和更低的上下文切换开销。适合对延迟极度敏感的服务比如高频交易、实时计算。quota 配额进程可以在所有核心上跑但总量受限。适合吞吐型服务能更充分地利用多核。绑核的代价是灵活性差。如果绑了 2 个核这 2 个核就被独占了别的服务用不了资源利用率可能不高。配额则更共享但会引入 throttling 抖动。生产环境里我通常这样选核心交易链路绑核普通业务用配额批处理任务用低 shares 加配额兜底。4. 内存限制limit、soft limit 与 OOM 的那些事4.1 memory.limit_in_bytes 的硬约束与 OOM Killer 触发链路memory.limit_in_bytesv2 里是memory.max是内存硬上限。一旦 cgroup 内所有进程的内存用量包括 page cache触及这个值内核会先尝试回收可回收的内存主要是 page cache如果回收后仍然超限就会触发 OOM Killer从该 cgroup 内挑一个进程杀掉。这个挑一个的规则由oom_score决定分数高的先被杀。分数和进程的内存占用、运行时长、优先级等有关。你可以通过调整/proc/pid/oom_score_adj来干预范围是 -1000 到 1000值越低越不容易被杀。容器场景下OOM 的表现是容器直接退出退出码通常是 137128 99 是 SIGKILL。如果你看到 Pod 反复重启且退出码是 137第一反应就应该是查内存限制。4.2 为什么 page cache 会算进内存用量以及怎么应对这是内存限制里最反直觉的一点。Linux 的设计哲学是空闲的内存就是浪费的内存所以它会尽可能把读过的文件缓存在 page cache 里。这部分内存在系统层面是可回收的但在 cgroup 统计里它算在memory.usage_in_bytes里。结果就是一个服务实际堆内存只用了 500MB但因为大量读文件page cache 涨到了 1.5GB如果 limit 设的是 1GB它就会被 OOM——尽管那 1GB 里大部分是可回收的。内核其实会在 OOM 前尝试回收 page cache但回收需要时间如果内存增长太快回收跟不上还是会 OOM。应对方法有几个对 IO 密集的服务limit 要留出 page cache 的空间通常按实际堆内存的 1.5 到 2 倍设。用memory.soft_limit_in_bytesv2 的memory.high设一个软限制超过软限制时内核会温和地回收内存而不是直接杀进程。在容器里定期 drop cache不推荐影响性能。4.3 soft limit 与 memory.high温和限流的正确用法memory.soft_limit_in_bytes在 v1 里的行为比较弱只在内存紧张时作为回收优先级的参考。v2 的memory.high则强得多超过 high 之后内核会强制回收该 cgroup 的内存并限制分配速度但不会杀进程。这个机制特别适合做软性限流。比如你给服务设memory.max2G、memory.high1.5G那么内存涨到 1.5G 时开始被压制涨到 2G 才 OOM。这样既给了突发空间又能在接近极限时提前干预。4.4 swap 与内存限制的交互别让 swap 掩盖了问题如果宿主机开了 swapcgroup 的内存用量统计会包含 swap 部分v1 里通过memory.memsw.limit_in_bytes控制。这意味着进程可以把不活跃的内存换出去从而在 RSS 上看起来没超限。但 swap 是把双刃剑。它能让你的服务在内存压力下多撑一会儿但换入换出的开销会让延迟飙升。对延迟敏感的服务我建议直接禁用 swap让内存问题尽早暴露而不是被 swap 掩盖到某个临界点突然爆发。在容器里禁用 swap 的方式是启动时加--memory-swap等于--memoryDocker或者设置memory.swap.max0v2。5. 容器运行时如何映射 Cgroup从 docker run 到内核文件5.1 Docker 参数与 Cgroup 文件的对应关系Docker 的资源参数最终都会落到 Cgroup 文件上。理解这个映射关系能让你在容器里排查问题时知道该看哪个文件。Docker 参数Cgroup v1 文件Cgroup v2 文件--cpus2cpu.cfs_quota_us200000cpu.max200000 100000--cpu-shares512cpu.shares512cpu.weight换算后--memory1gmemory.limit_in_bytesmemory.max--memory-reservation512mmemory.soft_limit_in_bytesmemory.high--cpuset-cpus0,1cpuset.cpus0-1cpuset.cpus0-1--pids-limit100pids.max100pids.max100--blkio-weight500blkio.weight500io.weight注意 v2 的cpu.weight和 v1 的cpu.shares数值范围不同。v1 是 2 到 262144默认 1024v2 是 1 到 10000默认 100。Docker 会帮你做换算但如果你直接写 Cgroup 文件得注意这个差异。5.2 Kubernetes 的 requests 与 limits 在 Cgroup 层的落地Kubernetes 里每个容器有两组资源声明requests 和 limits。它们的落地方式不同requests主要影响调度决定 Pod 被分配到哪个节点。在 Cgroup 层CPU requests 会转成cpu.sharesv1或cpu.weightv2内存 requests 通常不直接设限制。limits是硬约束CPU limits 转成 quota内存 limits 转成memory.max。这里有个经典问题CPU limits 到底该不该设。设了会导致 throttling不设又怕影响邻居。我的建议是对大多数在线服务CPU limits 可以设得宽松一些比如实际用量的 2 到 3 倍主要靠 requests 保证基本资源靠 limits 兜底防止失控。对批处理任务limits 可以设得紧一些。内存 limits 则必须设而且要设准。内存不像 CPU 可以超卖超了就是 OOM。5.3 在容器内部查看自己的 Cgroup 限制容器里通常看不到完整的 Cgroup 文件系统但可以通过一些方式获取自己的限制。最简单的是读/sys/fs/cgroup下的文件如果挂载了的话。如果没挂载可以用 cgroup 的 namespace 信息cat /proc/self/cgroup拿到路径后如果宿主机文件系统可见就能读到对应的限制文件。很多语言运行时也提供了读取容器限制的库比如 Java 的-XX:UseContainerSupport会自动读取 Cgroup 限制来设置堆大小。这里有个坑JVM 在容器里默认可能读不到正确的内存限制导致堆设得过大被 OOM。JDK 8u191 之前的版本需要手动加-XX:UnlockExperimentalVMOptions -XX:UseCGroupMemoryLimitForHeap之后的版本默认支持。如果你用的是老版本 JDK务必检查这一点。6. 实战配置模板与踩坑排查手册6.1 三类典型服务的资源配置模板根据我这几年的经验把服务分成三类每类给一套模板在线 API 服务延迟敏感resources: requests: cpu: 1 memory: 1Gi limits: cpu: 2 memory: 2GiCPU limits 给到 requests 的 2 倍留足突发空间减少 throttling。内存 limits 给到 requests 的 2 倍容纳 page cache。批处理任务吞吐敏感resources: requests: cpu: 500m memory: 512Mi limits: cpu: 4 memory: 4Girequests 设低保证能调度limits 设高允许它跑满多核。内存 limits 要按任务峰值设准。数据库/中间件稳定优先resources: requests: cpu: 2 memory: 4Gi limits: cpu: 2 memory: 4Girequests 等于 limits保证资源独占避免被邻居影响。这类服务通常还会配合 cpuset 绑核。6.2 一次真实的 OOM 排查从现象到根因的完整链路回到开头那次雪崩我后来完整复盘了排查过程这里分享出来。现象多个在线服务容器同时重启退出码 137节点内存使用率 100%。第一步确认是 OOM 还是别的。查dmesgdmesg | grep -i oom\|killed process输出里能看到被杀的进程和它的内存用量确认是 OOM。第二步找出是谁把内存吃光的。查各 cgroup 的内存用量# v1 for d in /sys/fs/cgroup/memory/*/; do echo $d: $(cat $d/memory.usage_in_bytes 2/dev/null) done | sort -t: -k2 -rn | head发现一个批处理容器的用量远超其他。第三步查这个容器的配置。发现它压根没设 memory limit而它跑的是一个全量特征回填任务需要把几千万条数据加载进内存。第四步根因确认批处理任务被错误调度到在线节点且无资源限制。修复给所有批处理任务强制加 memory limit并通过 nodeSelector 把它们隔离到专用节点。这个案例的教训是没有限制的资源迟早会被用满。别指望这个任务不会用太多内存这种假设生产环境里任何假设都会被打破。6.3 排查工具清单从 cgroup 文件到 systemd-cgtop日常排查我常用的工具systemd-cgtop实时查看各 cgroup 的 CPU、内存、IO 用量类似 top 但是按 cgroup 聚合。cat /sys/fs/cgroup/cpu/group/cpu.stat看 throttling 统计。cat /sys/fs/cgroup/memory/group/memory.stat看内存明细区分 RSS 和 cache。cat /sys/fs/cgroup/memory/group/memory.failcnt看内存分配失败次数能反映内存压力。docker stats容器级别的实时资源用量。kubectl top podK8s 环境下的 Pod 资源用量。这些工具配合使用基本能覆盖 90% 的资源问题排查。6.4 几个反直觉的注意事项最后分享几个我踩过的坑都是文档里不会写的第一CPU quota 设得太紧反而更慢。因为频繁 throttling 会导致进程被反复挂起唤醒上下文切换开销剧增。宁可设宽松点。第二内存 limit 不是越小越安全。设太小会导致频繁 OOM服务根本跑不起来。要根据实际用量加合理余量。第三cpuset 绑核后要注意 NUMA。如果绑的核跨了 NUMA 节点内存访问延迟会不一致。绑核时最好同时绑内存节点。第四容器里的nproc可能不准。它读的是宿主机核心数不是 Cgroup 限制。程序如果按nproc来设线程池大小可能会创建过多线程导致 throttling。要用 Cgroup 限制来算。第五Cgroup v1 和 v2 混用环境要特别小心。有些监控工具只支持一种迁移时容易出问题。升级前务必确认所有依赖工具都兼容。Cgroup 这套机制看起来参数不多但每个参数背后的行为逻辑都很微妙。真正把它用好的关键不是记住参数名而是理解资源竞争时会发生什么。想清楚这一点大部分配置决策就都有依据了。