这个系列写到第六篇了。前几篇我们把命名空间拆开揉碎讲了一遍搞清楚了容器里的进程是如何看待文件和网络的也就是解决了“看得见什么”的问题。但有一个问题一直没正面展开容器凭什么只能用它该用的CPU和内存如果某个容器里跑了个内存泄漏的进程凭什么隔壁容器还能稳住不崩这就是cgroups——control groups——真正干的事。本篇作为cgroups的第一部分先带你把它的骨架、版本差异、核心文件系统和最基础的资源限额实操过一遍。这篇内容适合谁看如果你是刚接触底层技术的开发者这篇能帮你把“容器有资源限制”这句口号落到内核接口的实际操作上如果你已经在生产环境碰过容器OOM、CPU争抢这类问题这篇能帮你建立问题排查的内核视角。我会尽量把每一步命令、每一个字段都解释到“为什么这么设计”而不是直接丢给你一句“照抄就完事”。1. cgroups到底解决了什么问题1.1 namespace管“看得见”cgroups管“用多少”容器技术老是喜欢把两个概念绑在一起说但实际上它们解决的是截然不同的两件事。namespace是让容器里的进程只能看到自己的那套视图自己的PID表、自己的网络栈、自己的挂载点它解决的是“可见性”问题。cgroups则完全不管你看得见什么它只管你在物理机层面到底消耗了多少资源以及允不允许你消耗这么多解决的是“可配额”问题。一个很典型的场景就能看出两者差异两个容器共享同一个物理内核namespace把它们的文件系统隔离得清清楚楚但如果不做任何cgroups限制某个容器里的进程一旦进入死循环能把整个宿主机的CPU全部吃干另一个容器里的服务哪怕只是做一个普通请求都会慢如蜗牛。命名空间帮不了你这个忙因为它压根不追踪CPU时间片要拦住这个失控的进程必须靠cgroups在调度器层面、内存分配层面进行限额和记账。理解了这个区别后面看容器运行时各种参数就不会再迷惑了——它同时在做两件事一件是namespace隔离一件是cgroups限额。1.2 cgroups的四个核心能力把cgroups拆开看内核提供了一整套能力不只是“限制”这么简单资源限制设定CPU时间片上限、内存使用上限、块设备IO带宽上限、网络带宽上限等。这是容器技术最依赖的能力也是生产环境发生OOM时最先想去查的地方。优先级控制可以给不同的控制组配置不同的CPU份额权重和IO优先级。比如基础监控组件可以占比低一些核心业务进程可以占比高一些大家挤在一起时不至于平均主义。资源审计与统计内核会持续记录每个控制组的真实资源消耗情况。运维同学最常用的memory.current、cpu.stat就来自这里这比在容器内自己估算要准确得多。进程挂起与恢复cgroups的freezer控制器可以像按暂停键一样冻结一组进程。我常用它做实验环境的临时停机或者对一个失控进程组先冻结快照再进去排查比直接kill温柔很多。这四个能力里最容易被低估的是“资源统计”。很多人以为限制好配额就完事了其实统计能力才是排查问题的起点内存泄漏是从哪个容器的memory.current开始异常上涨的CPU限流是从哪个时间窗口的cpu.stat里看到throttled次数增多的没有这套统计你连问题在哪个容器里都定位不到。1.3 一个生活化的理解方式如果让我给刚接触这块的朋友打个比方我会说namespace相当于给每个合租室友发了一间独立卧室你看不到别人房间里的陈设也碰不到别人的东西cgroups则是给整间房定下来的公共水电规则每月电费额度多少、热水用多少分钟、公共区域Wi-Fi带宽怎么分配。卧室负责隐私水电表负责限流两者各司其职缺一不可。这个类比虽然粗糙但方向是对的namespace是“空间隔离”cgroups是“资源配置”。2. 先搞清楚版本v1与v2的设计差异2.1 早期v1架构每个子系统管理一棵树cgroups从内核早期版本开始就一直存在但真正进入生产环境广泛使用的是v1设计。v1的核心模型是每个资源子系统subsystem各自维护一棵独立的层级树。什么叫子系统简单说就是负责某一类资源管理的模块最常用的有cpuCPU时间片调度与限额memory内存使用统计与上限控制blkio块设备IO带宽限制devices控制组内进程对设备文件的访问权限freezer冻结与恢复进程组在v1里cpu是一棵树memory是另一棵树你可以在/sys/fs/cgroup/cpu下建控制组同时在/sys/fs/cgroup/memory下建同名控制组它们互相独立、各管各的。一个进程可以同时存在于多棵树中在CPU树里属于某个组在内存树里又属于另一个组。这种设计的好处是灵活想单独管CPU就只管CPU那棵树。但坏处也很明显多棵树之间的关系非常复杂。假设你在CPU树里创建了一个父子嵌套结构在内存树里又创建了另一套嵌套结构阅读和运维成本迅速上升。更麻烦的是线程粒度问题同属一个进程的不同线程在v1下有可能被分配到不同的tasks列表这对希望整组进程保持一致资源契约的场景很不友好。内核社区在维护v1的过程中逐渐意识到这套模型扩展性太差于是才有了v2。2.2 v2的关键变化一棵统一的树cgroups v2从设计上直接推翻了“多树并存”的模型改为所有控制器统一挂到一棵层级树上。你不用再分别去找cpu和memory目录整个系统就一个/sys/fs/cgroup挂载点目录结构就是层级树本身你创建的每一个子目录都是一个控制组所有你想启用的控制器都在同一个组里协同工作。v2还引入了一个非常关键的动态开关机制。每个cgroup目录下都有两个重要文件cgroup.controllers列出当前控制组可用的控制器列表cgroup.subtree_control列出当前控制组已经启用并下发给子组的控制器列表你需要在父组里向cgroup.subtree_control写入cpu memory子组里才能看到cpu和memory控制的对应文件。如果不写子组里即使有目录也不会出现cpu.max、memory.max这些资源接口文件。这个设计很巧妙它让控制器的启停不再是系统级的事而是每个子树范围内可以动态调整的事。v2另一个让人印象深刻的约束是“内部分配限制”英文就叫no internal process constraint。简单理解就是在v2的层级结构里非根控制组不能同时既拥有自己的进程又继续持有子控制组。进程只能放在树的叶子节点。这个规则让整个树结构变成了一条清晰的单向分配链每个节点要么负责分配资源给子节点要么负责承载进程本身职责不会混淆。2.3 现在系统里到底跑的是哪套截至我写这篇内容的时间点主流发行版的系统初始化基本都是cgroups v2了。你可以用一个简单命令确认自己的宿主机处于哪个版本stat -fc %T /sys/fs/cgroup如果输出是cgroup2fs说明当前跑的是v2如果输出是tmpfs大概率是v1或者v1 v2混合挂载的旧系统。需要注意v1和v2不是互斥的早期内核支持将部分控制器挂载到v1树、另外一些控制器挂载到v2树。不过日常使用中我强烈建议统一走v2不只因为它是内核社区的主推方向更因为容器运行时和systemd这些核心组件对v2的支持已经非常成熟你把精力集中在v2的文件结构上几乎所有现代工具的配置难点都能顺带理解。3. 实操第一回合先把cgroup v2的“性格”摸清楚3.1 这不是普通目录是内核接口很多第一次看/sys/fs/cgroup的人容易犯一个错误把它当成一个普通的sysfs目录去翻。实际上这个路径挂载的是cgroup2fs文件系统你在里面看到的不是普通文件而是内核状态在你面前的实时投影。先看最基础的内容直接列出根目录ls -la /sys/fs/cgroup/你会看到一堆形如cgroup.前缀的文件以及一些系统服务自动创建的子目录。重点先关注这三个文件cat /sys/fs/cgroup/cgroup.controllers cat /sys/fs/cgroup/cgroup.subtree_control cat /sys/fs/cgroup/cgroup.procscgroup.controllers显示当前根控制组可用的全部控制器。cgroup.subtree_control显示根控制组已经开放给了哪些子控制组。如果cpu memory已经出现在里面说明系统已经把CPU和内存两个控制器下放给子树了如果只有memory那你的子组里就不会出现cpu.max文件。cgroup.procs很有意思它列出了根控制组里的进程PID列表。所有没有被归入任何子控制组的进程默认都属于根控制组。你可以把它理解为系统默认的“收纳筐”所有孤儿资源都算在根组头上。3.2 亲手创建第一个控制组说一万句理论不如动手建一个组。下面这套操作我建议你在一台测试机器上跑一遍整个过程大概二十秒但它能帮你建立对v2文件系统的肌肉记忆。第一步创建子控制组目录。目录可以随意命名这里用一个模拟项目名demosudo mkdir /sys/fs/cgroup/demo创建完之后进入目录看看多了什么文件ls -la /sys/fs/cgroup/demo/你会看到里面自动继承了一批cgroup.开头的文件以及当前已经被根组下放的控制器文件。注意如果根组的cgroup.subtree_control里没有加入cpu或memory你会发现这个目录里也找不到对应的cpu.max或memory.max文件。第二步试着在demo目录下再建一个子组并观察它对资源的继承方式sudo mkdir /sys/fs/cgroup/demo/child cat /sys/fs/cgroup/demo/child/cgroup.controllers cat /sys/fs/cgroup/cgroup.procs你会看到demo/child刚创建时cgroup.controllers是空的因为控制器要层层下放。如果你想让child也能管CPU和内存需要先在demo目录下打开对应的控制器开关sudo sh -c echo cpu memory /sys/fs/cgroup/demo/cgroup.subtree_control cat /sys/fs/cgroup/demo/child/cgroup.controllers这个“层层开启”的机制一开始确实容易忘记我在这上面踩过不止一次坑——创建了子组、写好了配置脚本结果一执行就报“找不到文件”最后发现是父组根本没下放控制器。第三步把进程放进去。最简单的验证方式就是启动一个永不退出的睡眠进程sudo sh -c echo $$ /sys/fs/cgroup/demo/cgroup.procs注意这里用了$$也就是当前shell的PID。执行完之后你可以在demo/cgroup.procs里看到自己的shell进程号甚至你的shell所在的整个会话都因为子进程继承关系而受到了该控制组的影响。这一点非常值得记住进程放入控制组之后它fork出来的所有子进程依然留在同一个控制组里不会自动跳出。3.3 清理控制组时的正确姿势用完控制组之后你得知道自己下一步该做什么否则会留下一些“进程已经跑了但保底状态很诡异”的隐患。清理的步骤是先让组内进程迁移回父组再删除目录。直接把进程从demo/cgroup.procs迁回根组sudo sh -c echo $$ /sys/fs/cgroup/cgroup.procs或者如果进程已经退出其实demo/cgroup.procs会变成空文件你就能直接卸载目录sudo rmdir /sys/fs/cgroup/demo/child sudo rmdir /sys/fs/cgroup/demo如果你不迁移进程就直接rmdir一般会得到一个Device or resource busy的报错。这个报错理论上会吓到不少人实际上它只是在告诉你这个目录下面还绑定着活进程内核不会允许你删掉一个正在承载进程的控制组。记住这个排查思路它在生产环境里经常出现。4. 实操第二回合CPU与内存限额亲手压一压4.1 CPU时间片的分配逻辑v2里控制CPU上限的关键文件是cpu.max它的格式非常简单$MAX $PERIOD含义是在一个调度周期$PERIOD内该控制组内所有进程最多能消耗$MAX微秒的CPU时间。默认的PERIOD通常是100000微秒也就是100毫秒。如果MAX写成max表示不对CPU做上限限制。举个真实例子假设你只想给一个容器分配半个CPU核心sudo sh -c echo 50000 100000 /sys/fs/cgroup/demo/cpu.max cat /sys/fs/cgroup/demo/cpu.max这行配置的意思是每100毫秒周期内demo组最多用50毫秒CPU时间换算下来就是0.5个核的占用上限。这个配额粒度很细从几毫秒到几十毫秒都能指定不像某些资源管理工具那样只能按整数核分配。如果要把组里的CPU上限彻底放开就写sudo sh -c echo max 100000 /sys/fs/cgroup/demo/cpu.max动手验证一下。先放一个不断消耗CPU的进程到demo组里我通常用一个简单的循环脚本sudo sh -c while :; do :; done echo $! /sys/fs/cgroup/demo/cgroup.procs这个脚本会产生一个无限空循环疯狂占用单核CPU。如果你开了top或者htop能看到这个进程的CPU占用率在100%左右而整个demo组被限制在50%的配额内系统会通过调度器强制限流。如果这时候读CPU统计文件cat /sys/fs/cgroup/demo/cpu.stat你会看到nr_throttled被限流的次数和throttled_usec被限流的总微秒数在持续增加。这就是内核把“配额”变成“实际调度行为”的直接证据。注意cpu.max限制的是组内所有进程加起来的累计CPU时间不是一个进程单独的量。组里有四个进程它们共享这50毫秒配额谁先抢到谁先跑但总量不会突破上限。4.2 内存配额限制的是上限不是预留v2里内存控制核心文件是memory.max、memory.current、memory.events。memory.max写入的是该控制组内所有进程允许使用的物理内存上限单位是字节。memory.current是当前实时使用量。memory.events记录内存达到上限时触发的max事件次数。配置一个具体限额比如限制demo组最多只能用64MB内存sudo sh -c echo 67108864 /sys/fs/cgroup/demo/memory.max cat /sys/fs/cgroup/demo/memory.max这里有个很容易误解的地方memory.max限制的是“物理内存”的使用总量但它的计算口径包括了文件缓存。也就是说如果组内进程读了一堆文件这些页面缓存在内核里也算在该组的memory.current里。所以当你看到memory.current快接近memory.max时不要急着判断是进程真的在泄漏先排查一下是不是文件缓存占了大头。验证内存限制最直接的方式是写一个小程序或者用一些现成的内存压力工具。这里我借用Python来演示sudo sh -c python3 -c import time buf [] while True: buf.append(bytearray(1024 * 1024)) time.sleep(0.1) echo $! /sys/fs/cgroup/demo/cgroup.procs这段代码会持续申请1MB大小的字节数组直到demo组触顶。运行一段时间后再读memory.current和memory.eventscat /sys/fs/cgroup/demo/memory.current cat /sys/fs/cgroup/demo/memory.events不出意外的话memory.current会停在接近64MB的位置memory.events里会出现max次数增长。组内某个进程大概率会被内核的OOM killer杀掉对应的oom_kill计数也会加一。这段操作强烈建议在测试机做不要在生产环境随便拿内存控制器试刀。我当年第一次试的时候直接把测试机的数据库容器给杀掉了教训就是内存限制触发时内核是直接动杀手锏的不是跟你商量着来的。4.3 性能影响不是零要知道这事有代价很多人觉得cgroups既然是内核原生提供的那性能开销一定为零。这话只对了一半。cgroups的统计和限制本身确实非常轻量它是在CPU调度路径和内存管理路径上顺带做了一些记账正常负载下可以忽略不计。但一旦你启用非常细粒度的IO限速或者频繁读写memory.events这类文件内核中的锁竞争就会显现出来。我个人的经验是内存控制器对读写性能的影响比CPU控制器更敏感尤其是在大量线程同时对不同控制组分配内存的高并发场景。如果你在做性能基准测试建议先测一组开cgroups与不开cgroups的对比数据再用这个数据去评估线上服务是否需要精细化调优。5. 容器运行时怎么用cgroups的5.1 Docker、runc与cgroups的配合关系如果你用过主流容器运行时那你其实早就在跟cgroups打交道了只是隔了一层封装。以最典型的方式举例你执行一条资源限制命令比如docker run --cpus0.5 --memory64m --name demo busybox sleep 300这条命令的底层逻辑会通过容器运行时把参数翻译成cgroups文件写入。容器运行时会在/sys/fs/cgroup下创建一个类似.../docker/容器ID的子控制组目录然后把--cpus0.5翻译成cpu.max里写入50000 100000把--memory64m翻译成memory.max里写入67108864。这个映射关系极其直接你甚至可以在/sys/fs/cgroup下面找到正在运行的每个容器对应的目录直接去查看它的memory.current或cpu.stat。这也解释了一个现象为什么在容器内执行top看CPU使用率和在宿主机看到的不完全一样因为容器内看到的只是它自己的namespace视角和普通进程统计而宿主机上按cgroup维度统计的是这个组所有进程的累计资源消耗。两者口径不同不要混为一谈。5.2 systemd也是cgroups的重要玩家不只是容器运行时在用cgroupssystemd作为系统初始化进程早已把cgroups深度集成到了服务管理里。你在/sys/fs/cgroup下看到的很多子目录例如system.slice就是systemd为系统服务创建的控制组单元。每一个systemd服务默认就落在它自己的控制组里这样systemctl status才能查到服务的资源占用情况systemd-cgtop才能按服务维度展示CPU和内存使用量。如果你是自己在写服务脚本并且想用systemd的方式来管理cgroups可以直接用systemd-run创建临时scopesudo systemd-run --scope -p MemoryMax64M -p CPUQuota50% ./some_long_running_binary这条命令会在systemd的管理下新建一个临时的scope单元并应用对应的资源限制效果等同于手动创建cgroup再写文件。这个方法的好处是systemd会替你维护好控制组的生命周期不用你手动去创建和清理目录。不过要注意一个常见问题systemd和手动创建的cgroup目录之间可能产生管理冲突。如果你在systemd已经管理的目录下擅自改动资源文件systemd下次重载时可能会覆盖你的配置。实际环境中我的建议是能用systemd的统一入口就用systemd实在需要精细化手动操作就单独建一个systemd没在管的子树区域。5.3 容器内存统计里那些容易读错的字段在cgroups v2的控制组目录里有一组专门记录内存事件的字段它们对排查容器OOM非常有帮助但也最容易读错memory.current当前物理内存使用量含文件缓存。memory.max允许的最大物理内存使用量写入max表示不限制。memory.peak历史峰值内存用量这个字段是我排查内存泄漏时必看的它能告诉你“曾经涨到过多高”。memory.events包含high、max、oom_kill等计数。high是触发警告阈值max是触顶事件oom_kill是内核真正杀进程的次数。有一次我在线上看到一个容器频繁重启dmesg里没有出现OOM日志还是通过读容器的memory.events发现oom_kill计数不断增长才定位到问题。这类跨层信息在容器外往往容易被忽略大家在定位资源问题的时候建议直接去对应控制组目录里把这些事件文件从头到尾看一遍。6. 常见问题与排查技巧实录6.1 踩过的坑逐个拆给你看先整理一个我实际踩过、也在社区里经常见到的坑点速查表症状常见原因排查方向写cpu.max时报“No such file or directory”父组没有下放cpu控制器给子组检查父目录的cgroup.subtree_control先执行echo cpurmdir控制组报“Device or resource busy”组内仍有活着的进程先迁移进程回父组再删除目录容器内内存限制触发了但进程没被杀读的是memory.peak不是memory.current或者OOM killer选了别的进程结合dmesg查完整日志把PID写入tasks不再生效v2没有tasks文件只有cgroup.procsv2里所有线程统一通过cgroup.procs管理限制没生效CPU照常跑满cgroup.subtree_control中cpu未打开查看该目录的cgroup.controllers是否包含cpu其中第二个坑我印象最深。当时我在清理一个测试容器的控制组组内还有一个sleep进程留在里面直接rmdir一直报busy我还以为文件系统坏掉了。后来才明白cgroups不是普通的空目录只要有进程绑定在组里它就不允许被删除。这个“目录还有活人”的语义之后帮我避开了很多线上误操作。6.2 排查时快速定位问题的方法排查cgroups相关的问题我一般遵循下面这个顺序先确认内核版本与挂载模式。用stat -fc %T /sys/fs/cgroup看是cgroup2fs还是tmpfs。紧接着再看根目录的cgroup.subtree_control确认资源控制器到底下放没有。很多“配了没效果”的问题在这一步就能看到答案。再顺着进程找控制组。一个进程属于哪个控制组可以读它的/proc/PID/cgroup文件cat /proc/PID/cgroup输出类似于0::/system.slice/demo.service这个路径直接告诉你进程落在了哪棵树的哪个节点上。沿着这个节点路径去/sys/fs/cgroup对应目录看看该目录下的限额文件写没写对。然后看统计文件而不是只看限额文件。cpu.stat的nr_throttled、memory.current、memory.events才是实际运行后的效果反馈。如果cpu.max配置了但nr_throttled一直不涨、CPU却依然吃满说明配置根本没作用到目标进程组上或者进程在另一个组。最后记得看系统日志。OOM事件在dmesg里通常有非常明确的记录它会告诉你哪个cgroup内哪个进程被选为牺牲品。把memory.events里的oom_kill计数跟dmesg对照着看基本可以还原整个事件的来龙去脉。6.3 系统负载高峰期的排查顺序线上遇到宿主机突然hang住或者load飙高的时候cgroups能帮你把定位范围快速收敛。我的建议是先看systemd-cgtop它按控制组维度展示资源占用比直接top看单个进程容易发现问题。假如某个容器组的CPU占用异常就进对应控制组目录看cpu.stat的限流计数是否持续飙升再进容器内看具体进程。如果内存告急先在宿主机上看根控制组的memory.current确认整体水位。再用memory.peak对比各容器找出谁急速拉升。随后结合dmesg看内核有没有OOM动作。这套组合拳能让你在几分钟内把问题从“整机异常”缩小到“某个控制组内的某个进程”省掉大量盲目翻日志的时间。写在最后我始终觉得cgroups和namespace放在一起记才是最省力的namespace决定了进程的“视野边界”cgroups决定了进程的“资源边界”。理解了这两个词再看容器、再看systemd的服务管理你会觉得内核的这些设计其实是一套非常有逻辑的语言而不是一堆零散文件。这一篇侧重cgroups的整体架构和v2核心文件操作算是一个地基。后面的系列文章我会接着把CPU调度器怎么和cgroups配合、内存回收路径如何与cgroups联动、以及IO控制器和嵌套层级这些更深入的话题展开。如果你是用容器跑业务的人建议你上手多敲几遍文中的命令尤其是自己创建一个控制组、限制CPU和内存、再亲手验证一遍那种“内核真的听我话”的直观感受比看十篇理论都管用。最后再分享一个小技巧无论任何时候修改cgroups配置前可以先看一眼cgroup.procs里的现有进程动作之前弄清楚把谁放进去、把谁移出来能避免九成以上的误操作。祝操作顺利少踩坑。
这个系列写到第六篇了。前几篇我们把命名空间拆开揉碎讲了一遍搞清楚了容器里的进程是如何看待文件和网络的也就是解决了“看得见什么”的问题。但有一个问题一直没正面展开容器凭什么只能用它该用的CPU和内存如果某个容器里跑了个内存泄漏的进程凭什么隔壁容器还能稳住不崩这就是cgroups——control groups——真正干的事。本篇作为cgroups的第一部分先带你把它的骨架、版本差异、核心文件系统和最基础的资源限额实操过一遍。这篇内容适合谁看如果你是刚接触底层技术的开发者这篇能帮你把“容器有资源限制”这句口号落到内核接口的实际操作上如果你已经在生产环境碰过容器OOM、CPU争抢这类问题这篇能帮你建立问题排查的内核视角。我会尽量把每一步命令、每一个字段都解释到“为什么这么设计”而不是直接丢给你一句“照抄就完事”。1. cgroups到底解决了什么问题1.1 namespace管“看得见”cgroups管“用多少”容器技术老是喜欢把两个概念绑在一起说但实际上它们解决的是截然不同的两件事。namespace是让容器里的进程只能看到自己的那套视图自己的PID表、自己的网络栈、自己的挂载点它解决的是“可见性”问题。cgroups则完全不管你看得见什么它只管你在物理机层面到底消耗了多少资源以及允不允许你消耗这么多解决的是“可配额”问题。一个很典型的场景就能看出两者差异两个容器共享同一个物理内核namespace把它们的文件系统隔离得清清楚楚但如果不做任何cgroups限制某个容器里的进程一旦进入死循环能把整个宿主机的CPU全部吃干另一个容器里的服务哪怕只是做一个普通请求都会慢如蜗牛。命名空间帮不了你这个忙因为它压根不追踪CPU时间片要拦住这个失控的进程必须靠cgroups在调度器层面、内存分配层面进行限额和记账。理解了这个区别后面看容器运行时各种参数就不会再迷惑了——它同时在做两件事一件是namespace隔离一件是cgroups限额。1.2 cgroups的四个核心能力把cgroups拆开看内核提供了一整套能力不只是“限制”这么简单资源限制设定CPU时间片上限、内存使用上限、块设备IO带宽上限、网络带宽上限等。这是容器技术最依赖的能力也是生产环境发生OOM时最先想去查的地方。优先级控制可以给不同的控制组配置不同的CPU份额权重和IO优先级。比如基础监控组件可以占比低一些核心业务进程可以占比高一些大家挤在一起时不至于平均主义。资源审计与统计内核会持续记录每个控制组的真实资源消耗情况。运维同学最常用的memory.current、cpu.stat就来自这里这比在容器内自己估算要准确得多。进程挂起与恢复cgroups的freezer控制器可以像按暂停键一样冻结一组进程。我常用它做实验环境的临时停机或者对一个失控进程组先冻结快照再进去排查比直接kill温柔很多。这四个能力里最容易被低估的是“资源统计”。很多人以为限制好配额就完事了其实统计能力才是排查问题的起点内存泄漏是从哪个容器的memory.current开始异常上涨的CPU限流是从哪个时间窗口的cpu.stat里看到throttled次数增多的没有这套统计你连问题在哪个容器里都定位不到。1.3 一个生活化的理解方式如果让我给刚接触这块的朋友打个比方我会说namespace相当于给每个合租室友发了一间独立卧室你看不到别人房间里的陈设也碰不到别人的东西cgroups则是给整间房定下来的公共水电规则每月电费额度多少、热水用多少分钟、公共区域Wi-Fi带宽怎么分配。卧室负责隐私水电表负责限流两者各司其职缺一不可。这个类比虽然粗糙但方向是对的namespace是“空间隔离”cgroups是“资源配置”。2. 先搞清楚版本v1与v2的设计差异2.1 早期v1架构每个子系统管理一棵树cgroups从内核早期版本开始就一直存在但真正进入生产环境广泛使用的是v1设计。v1的核心模型是每个资源子系统subsystem各自维护一棵独立的层级树。什么叫子系统简单说就是负责某一类资源管理的模块最常用的有cpuCPU时间片调度与限额memory内存使用统计与上限控制blkio块设备IO带宽限制devices控制组内进程对设备文件的访问权限freezer冻结与恢复进程组在v1里cpu是一棵树memory是另一棵树你可以在/sys/fs/cgroup/cpu下建控制组同时在/sys/fs/cgroup/memory下建同名控制组它们互相独立、各管各的。一个进程可以同时存在于多棵树中在CPU树里属于某个组在内存树里又属于另一个组。这种设计的好处是灵活想单独管CPU就只管CPU那棵树。但坏处也很明显多棵树之间的关系非常复杂。假设你在CPU树里创建了一个父子嵌套结构在内存树里又创建了另一套嵌套结构阅读和运维成本迅速上升。更麻烦的是线程粒度问题同属一个进程的不同线程在v1下有可能被分配到不同的tasks列表这对希望整组进程保持一致资源契约的场景很不友好。内核社区在维护v1的过程中逐渐意识到这套模型扩展性太差于是才有了v2。2.2 v2的关键变化一棵统一的树cgroups v2从设计上直接推翻了“多树并存”的模型改为所有控制器统一挂到一棵层级树上。你不用再分别去找cpu和memory目录整个系统就一个/sys/fs/cgroup挂载点目录结构就是层级树本身你创建的每一个子目录都是一个控制组所有你想启用的控制器都在同一个组里协同工作。v2还引入了一个非常关键的动态开关机制。每个cgroup目录下都有两个重要文件cgroup.controllers列出当前控制组可用的控制器列表cgroup.subtree_control列出当前控制组已经启用并下发给子组的控制器列表你需要在父组里向cgroup.subtree_control写入cpu memory子组里才能看到cpu和memory控制的对应文件。如果不写子组里即使有目录也不会出现cpu.max、memory.max这些资源接口文件。这个设计很巧妙它让控制器的启停不再是系统级的事而是每个子树范围内可以动态调整的事。v2另一个让人印象深刻的约束是“内部分配限制”英文就叫no internal process constraint。简单理解就是在v2的层级结构里非根控制组不能同时既拥有自己的进程又继续持有子控制组。进程只能放在树的叶子节点。这个规则让整个树结构变成了一条清晰的单向分配链每个节点要么负责分配资源给子节点要么负责承载进程本身职责不会混淆。2.3 现在系统里到底跑的是哪套截至我写这篇内容的时间点主流发行版的系统初始化基本都是cgroups v2了。你可以用一个简单命令确认自己的宿主机处于哪个版本stat -fc %T /sys/fs/cgroup如果输出是cgroup2fs说明当前跑的是v2如果输出是tmpfs大概率是v1或者v1 v2混合挂载的旧系统。需要注意v1和v2不是互斥的早期内核支持将部分控制器挂载到v1树、另外一些控制器挂载到v2树。不过日常使用中我强烈建议统一走v2不只因为它是内核社区的主推方向更因为容器运行时和systemd这些核心组件对v2的支持已经非常成熟你把精力集中在v2的文件结构上几乎所有现代工具的配置难点都能顺带理解。3. 实操第一回合先把cgroup v2的“性格”摸清楚3.1 这不是普通目录是内核接口很多第一次看/sys/fs/cgroup的人容易犯一个错误把它当成一个普通的sysfs目录去翻。实际上这个路径挂载的是cgroup2fs文件系统你在里面看到的不是普通文件而是内核状态在你面前的实时投影。先看最基础的内容直接列出根目录ls -la /sys/fs/cgroup/你会看到一堆形如cgroup.前缀的文件以及一些系统服务自动创建的子目录。重点先关注这三个文件cat /sys/fs/cgroup/cgroup.controllers cat /sys/fs/cgroup/cgroup.subtree_control cat /sys/fs/cgroup/cgroup.procscgroup.controllers显示当前根控制组可用的全部控制器。cgroup.subtree_control显示根控制组已经开放给了哪些子控制组。如果cpu memory已经出现在里面说明系统已经把CPU和内存两个控制器下放给子树了如果只有memory那你的子组里就不会出现cpu.max文件。cgroup.procs很有意思它列出了根控制组里的进程PID列表。所有没有被归入任何子控制组的进程默认都属于根控制组。你可以把它理解为系统默认的“收纳筐”所有孤儿资源都算在根组头上。3.2 亲手创建第一个控制组说一万句理论不如动手建一个组。下面这套操作我建议你在一台测试机器上跑一遍整个过程大概二十秒但它能帮你建立对v2文件系统的肌肉记忆。第一步创建子控制组目录。目录可以随意命名这里用一个模拟项目名demosudo mkdir /sys/fs/cgroup/demo创建完之后进入目录看看多了什么文件ls -la /sys/fs/cgroup/demo/你会看到里面自动继承了一批cgroup.开头的文件以及当前已经被根组下放的控制器文件。注意如果根组的cgroup.subtree_control里没有加入cpu或memory你会发现这个目录里也找不到对应的cpu.max或memory.max文件。第二步试着在demo目录下再建一个子组并观察它对资源的继承方式sudo mkdir /sys/fs/cgroup/demo/child cat /sys/fs/cgroup/demo/child/cgroup.controllers cat /sys/fs/cgroup/cgroup.procs你会看到demo/child刚创建时cgroup.controllers是空的因为控制器要层层下放。如果你想让child也能管CPU和内存需要先在demo目录下打开对应的控制器开关sudo sh -c echo cpu memory /sys/fs/cgroup/demo/cgroup.subtree_control cat /sys/fs/cgroup/demo/child/cgroup.controllers这个“层层开启”的机制一开始确实容易忘记我在这上面踩过不止一次坑——创建了子组、写好了配置脚本结果一执行就报“找不到文件”最后发现是父组根本没下放控制器。第三步把进程放进去。最简单的验证方式就是启动一个永不退出的睡眠进程sudo sh -c echo $$ /sys/fs/cgroup/demo/cgroup.procs注意这里用了$$也就是当前shell的PID。执行完之后你可以在demo/cgroup.procs里看到自己的shell进程号甚至你的shell所在的整个会话都因为子进程继承关系而受到了该控制组的影响。这一点非常值得记住进程放入控制组之后它fork出来的所有子进程依然留在同一个控制组里不会自动跳出。3.3 清理控制组时的正确姿势用完控制组之后你得知道自己下一步该做什么否则会留下一些“进程已经跑了但保底状态很诡异”的隐患。清理的步骤是先让组内进程迁移回父组再删除目录。直接把进程从demo/cgroup.procs迁回根组sudo sh -c echo $$ /sys/fs/cgroup/cgroup.procs或者如果进程已经退出其实demo/cgroup.procs会变成空文件你就能直接卸载目录sudo rmdir /sys/fs/cgroup/demo/child sudo rmdir /sys/fs/cgroup/demo如果你不迁移进程就直接rmdir一般会得到一个Device or resource busy的报错。这个报错理论上会吓到不少人实际上它只是在告诉你这个目录下面还绑定着活进程内核不会允许你删掉一个正在承载进程的控制组。记住这个排查思路它在生产环境里经常出现。4. 实操第二回合CPU与内存限额亲手压一压4.1 CPU时间片的分配逻辑v2里控制CPU上限的关键文件是cpu.max它的格式非常简单$MAX $PERIOD含义是在一个调度周期$PERIOD内该控制组内所有进程最多能消耗$MAX微秒的CPU时间。默认的PERIOD通常是100000微秒也就是100毫秒。如果MAX写成max表示不对CPU做上限限制。举个真实例子假设你只想给一个容器分配半个CPU核心sudo sh -c echo 50000 100000 /sys/fs/cgroup/demo/cpu.max cat /sys/fs/cgroup/demo/cpu.max这行配置的意思是每100毫秒周期内demo组最多用50毫秒CPU时间换算下来就是0.5个核的占用上限。这个配额粒度很细从几毫秒到几十毫秒都能指定不像某些资源管理工具那样只能按整数核分配。如果要把组里的CPU上限彻底放开就写sudo sh -c echo max 100000 /sys/fs/cgroup/demo/cpu.max动手验证一下。先放一个不断消耗CPU的进程到demo组里我通常用一个简单的循环脚本sudo sh -c while :; do :; done echo $! /sys/fs/cgroup/demo/cgroup.procs这个脚本会产生一个无限空循环疯狂占用单核CPU。如果你开了top或者htop能看到这个进程的CPU占用率在100%左右而整个demo组被限制在50%的配额内系统会通过调度器强制限流。如果这时候读CPU统计文件cat /sys/fs/cgroup/demo/cpu.stat你会看到nr_throttled被限流的次数和throttled_usec被限流的总微秒数在持续增加。这就是内核把“配额”变成“实际调度行为”的直接证据。注意cpu.max限制的是组内所有进程加起来的累计CPU时间不是一个进程单独的量。组里有四个进程它们共享这50毫秒配额谁先抢到谁先跑但总量不会突破上限。4.2 内存配额限制的是上限不是预留v2里内存控制核心文件是memory.max、memory.current、memory.events。memory.max写入的是该控制组内所有进程允许使用的物理内存上限单位是字节。memory.current是当前实时使用量。memory.events记录内存达到上限时触发的max事件次数。配置一个具体限额比如限制demo组最多只能用64MB内存sudo sh -c echo 67108864 /sys/fs/cgroup/demo/memory.max cat /sys/fs/cgroup/demo/memory.max这里有个很容易误解的地方memory.max限制的是“物理内存”的使用总量但它的计算口径包括了文件缓存。也就是说如果组内进程读了一堆文件这些页面缓存在内核里也算在该组的memory.current里。所以当你看到memory.current快接近memory.max时不要急着判断是进程真的在泄漏先排查一下是不是文件缓存占了大头。验证内存限制最直接的方式是写一个小程序或者用一些现成的内存压力工具。这里我借用Python来演示sudo sh -c python3 -c import time buf [] while True: buf.append(bytearray(1024 * 1024)) time.sleep(0.1) echo $! /sys/fs/cgroup/demo/cgroup.procs这段代码会持续申请1MB大小的字节数组直到demo组触顶。运行一段时间后再读memory.current和memory.eventscat /sys/fs/cgroup/demo/memory.current cat /sys/fs/cgroup/demo/memory.events不出意外的话memory.current会停在接近64MB的位置memory.events里会出现max次数增长。组内某个进程大概率会被内核的OOM killer杀掉对应的oom_kill计数也会加一。这段操作强烈建议在测试机做不要在生产环境随便拿内存控制器试刀。我当年第一次试的时候直接把测试机的数据库容器给杀掉了教训就是内存限制触发时内核是直接动杀手锏的不是跟你商量着来的。4.3 性能影响不是零要知道这事有代价很多人觉得cgroups既然是内核原生提供的那性能开销一定为零。这话只对了一半。cgroups的统计和限制本身确实非常轻量它是在CPU调度路径和内存管理路径上顺带做了一些记账正常负载下可以忽略不计。但一旦你启用非常细粒度的IO限速或者频繁读写memory.events这类文件内核中的锁竞争就会显现出来。我个人的经验是内存控制器对读写性能的影响比CPU控制器更敏感尤其是在大量线程同时对不同控制组分配内存的高并发场景。如果你在做性能基准测试建议先测一组开cgroups与不开cgroups的对比数据再用这个数据去评估线上服务是否需要精细化调优。5. 容器运行时怎么用cgroups的5.1 Docker、runc与cgroups的配合关系如果你用过主流容器运行时那你其实早就在跟cgroups打交道了只是隔了一层封装。以最典型的方式举例你执行一条资源限制命令比如docker run --cpus0.5 --memory64m --name demo busybox sleep 300这条命令的底层逻辑会通过容器运行时把参数翻译成cgroups文件写入。容器运行时会在/sys/fs/cgroup下创建一个类似.../docker/容器ID的子控制组目录然后把--cpus0.5翻译成cpu.max里写入50000 100000把--memory64m翻译成memory.max里写入67108864。这个映射关系极其直接你甚至可以在/sys/fs/cgroup下面找到正在运行的每个容器对应的目录直接去查看它的memory.current或cpu.stat。这也解释了一个现象为什么在容器内执行top看CPU使用率和在宿主机看到的不完全一样因为容器内看到的只是它自己的namespace视角和普通进程统计而宿主机上按cgroup维度统计的是这个组所有进程的累计资源消耗。两者口径不同不要混为一谈。5.2 systemd也是cgroups的重要玩家不只是容器运行时在用cgroupssystemd作为系统初始化进程早已把cgroups深度集成到了服务管理里。你在/sys/fs/cgroup下看到的很多子目录例如system.slice就是systemd为系统服务创建的控制组单元。每一个systemd服务默认就落在它自己的控制组里这样systemctl status才能查到服务的资源占用情况systemd-cgtop才能按服务维度展示CPU和内存使用量。如果你是自己在写服务脚本并且想用systemd的方式来管理cgroups可以直接用systemd-run创建临时scopesudo systemd-run --scope -p MemoryMax64M -p CPUQuota50% ./some_long_running_binary这条命令会在systemd的管理下新建一个临时的scope单元并应用对应的资源限制效果等同于手动创建cgroup再写文件。这个方法的好处是systemd会替你维护好控制组的生命周期不用你手动去创建和清理目录。不过要注意一个常见问题systemd和手动创建的cgroup目录之间可能产生管理冲突。如果你在systemd已经管理的目录下擅自改动资源文件systemd下次重载时可能会覆盖你的配置。实际环境中我的建议是能用systemd的统一入口就用systemd实在需要精细化手动操作就单独建一个systemd没在管的子树区域。5.3 容器内存统计里那些容易读错的字段在cgroups v2的控制组目录里有一组专门记录内存事件的字段它们对排查容器OOM非常有帮助但也最容易读错memory.current当前物理内存使用量含文件缓存。memory.max允许的最大物理内存使用量写入max表示不限制。memory.peak历史峰值内存用量这个字段是我排查内存泄漏时必看的它能告诉你“曾经涨到过多高”。memory.events包含high、max、oom_kill等计数。high是触发警告阈值max是触顶事件oom_kill是内核真正杀进程的次数。有一次我在线上看到一个容器频繁重启dmesg里没有出现OOM日志还是通过读容器的memory.events发现oom_kill计数不断增长才定位到问题。这类跨层信息在容器外往往容易被忽略大家在定位资源问题的时候建议直接去对应控制组目录里把这些事件文件从头到尾看一遍。6. 常见问题与排查技巧实录6.1 踩过的坑逐个拆给你看先整理一个我实际踩过、也在社区里经常见到的坑点速查表症状常见原因排查方向写cpu.max时报“No such file or directory”父组没有下放cpu控制器给子组检查父目录的cgroup.subtree_control先执行echo cpurmdir控制组报“Device or resource busy”组内仍有活着的进程先迁移进程回父组再删除目录容器内内存限制触发了但进程没被杀读的是memory.peak不是memory.current或者OOM killer选了别的进程结合dmesg查完整日志把PID写入tasks不再生效v2没有tasks文件只有cgroup.procsv2里所有线程统一通过cgroup.procs管理限制没生效CPU照常跑满cgroup.subtree_control中cpu未打开查看该目录的cgroup.controllers是否包含cpu其中第二个坑我印象最深。当时我在清理一个测试容器的控制组组内还有一个sleep进程留在里面直接rmdir一直报busy我还以为文件系统坏掉了。后来才明白cgroups不是普通的空目录只要有进程绑定在组里它就不允许被删除。这个“目录还有活人”的语义之后帮我避开了很多线上误操作。6.2 排查时快速定位问题的方法排查cgroups相关的问题我一般遵循下面这个顺序先确认内核版本与挂载模式。用stat -fc %T /sys/fs/cgroup看是cgroup2fs还是tmpfs。紧接着再看根目录的cgroup.subtree_control确认资源控制器到底下放没有。很多“配了没效果”的问题在这一步就能看到答案。再顺着进程找控制组。一个进程属于哪个控制组可以读它的/proc/PID/cgroup文件cat /proc/PID/cgroup输出类似于0::/system.slice/demo.service这个路径直接告诉你进程落在了哪棵树的哪个节点上。沿着这个节点路径去/sys/fs/cgroup对应目录看看该目录下的限额文件写没写对。然后看统计文件而不是只看限额文件。cpu.stat的nr_throttled、memory.current、memory.events才是实际运行后的效果反馈。如果cpu.max配置了但nr_throttled一直不涨、CPU却依然吃满说明配置根本没作用到目标进程组上或者进程在另一个组。最后记得看系统日志。OOM事件在dmesg里通常有非常明确的记录它会告诉你哪个cgroup内哪个进程被选为牺牲品。把memory.events里的oom_kill计数跟dmesg对照着看基本可以还原整个事件的来龙去脉。6.3 系统负载高峰期的排查顺序线上遇到宿主机突然hang住或者load飙高的时候cgroups能帮你把定位范围快速收敛。我的建议是先看systemd-cgtop它按控制组维度展示资源占用比直接top看单个进程容易发现问题。假如某个容器组的CPU占用异常就进对应控制组目录看cpu.stat的限流计数是否持续飙升再进容器内看具体进程。如果内存告急先在宿主机上看根控制组的memory.current确认整体水位。再用memory.peak对比各容器找出谁急速拉升。随后结合dmesg看内核有没有OOM动作。这套组合拳能让你在几分钟内把问题从“整机异常”缩小到“某个控制组内的某个进程”省掉大量盲目翻日志的时间。写在最后我始终觉得cgroups和namespace放在一起记才是最省力的namespace决定了进程的“视野边界”cgroups决定了进程的“资源边界”。理解了这两个词再看容器、再看systemd的服务管理你会觉得内核的这些设计其实是一套非常有逻辑的语言而不是一堆零散文件。这一篇侧重cgroups的整体架构和v2核心文件操作算是一个地基。后面的系列文章我会接着把CPU调度器怎么和cgroups配合、内存回收路径如何与cgroups联动、以及IO控制器和嵌套层级这些更深入的话题展开。如果你是用容器跑业务的人建议你上手多敲几遍文中的命令尤其是自己创建一个控制组、限制CPU和内存、再亲手验证一遍那种“内核真的听我话”的直观感受比看十篇理论都管用。最后再分享一个小技巧无论任何时候修改cgroups配置前可以先看一眼cgroup.procs里的现有进程动作之前弄清楚把谁放进去、把谁移出来能避免九成以上的误操作。祝操作顺利少踩坑。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
