Linux内存管理章节十二：资源的牢笼：深入Linux内存控制组（cgroups）机制

引言

在传统的Linux系统中，所有进程共享同一片内存资源。一个设计不良或存在内存泄漏的进程可以轻易耗尽所有物理内存和交换空间，导致其他关键进程被OOM Killer终止，引发系统级服务中断。这种“ noisy neighbor ”问题在共享的云环境和容器中是不可接受的。内存控制组（memory cgroup） 正是为了解决这一问题而生。它为进程组（如容器）构建了一个“资源的牢笼”，实现内存资源的隔离、限制与核算。本文将解析memory cgroup的实现原理、其限制统计机制以及与之紧密相关的OOM Killer工作机制。

一、 memory cgroup的实现原理：分层管理与电荷记账

memory cgroup的核心思想是：将系统内存资源划分成多个独立的子集，每个cgroup内的进程只能使用分配给该cgroup的内存份额。

1. 层次化组织

memory cgroup遵循经典的cgroup架构，以虚拟文件系统（通常挂载在/sys/fs/cgroup/）的形式暴露给用户空间。你可以像管理目录一样创建、删除cgroup，并将进程ID写入cgroup.procs文件来将其加入某个cgroup。

这种结构是层次化的，子cgroup会继承父cgroup的限制属性，并且其内存使用也会计入所有祖先cgroup。

2. 内存“电荷”记账

这是memory cgroup的会计学核心。内核中几乎所有分配物理页的路径（如缺页异常、mmap）都被插桩（instrumented）。当一个页被分配并映射给某个进程时，内核会执行以下操作：

1. 追溯归属：通过进程找到其所属的memory cgroup。
2. 记账：将该页的大小（通常是4KB）计入该cgroup的**memory.usage_in_bytes** 统计项中。
3. 传播：同时，这个“电荷”也会逐级向上累加到所有祖先cgroup的统计中。

这种机制确保了所有内存分配（包括页缓存、匿名内存、内核栈等）都能被准确无误地追踪和归属。

3. 页回收与cgroup

当系统需要进行全局内存回收时，kswapd会工作。但当某个cgroup达到其限制时，内核需要在该cgroup内部进行回收。
每个memory cgroup都有自己的一套LRU链表（与全局的LRU类似，包含active/inactive file/anonymous列表）。当cgroup内存超限时，内核的**“直接回收”逻辑会在这个cgroup的LRU链表上工作**，优先回收该cgroup内的文件页，然后才是匿名页（可能触发swap）。这实现了隔离的回收，一个cgroup的内存压力不会直接影响其他cgroup的页面回收。

二、 内存限制与统计机制：精细化的控制

memory cgroup通过/sys/fs/cgroup/memory/<group>/目录下的众多接口文件提供了极其精细的控制和统计能力。

核心限制接口：

• memory.limit_in_bytes：设置该cgroup中用户态进程所能使用的物理内存总量硬限。如果cgroup内的进程尝试分配更多内存，并触发了直接回收后仍无法满足，则分配会失败（用户进程看到ENOMEM），或触发cgroup内部的OOM Killer（见第三节）。
• memory.memsw.limit_in_bytes：设置物理内存 + 交换空间的总和限制。此限制必须 >= memory.limit_in_bytes。
• memory.soft_limit_in_bytes：软限制。系统更倾向于在超过此限制的cgroup中回收内存，但不会完全阻止其分配。它是在系统全局内存紧张时，指导内核回收优先级的一个提示。

核心统计接口：

• memory.usage_in_bytes：该cgroup当前使用的总内存量（近似值）。
• memory.stat：最详细的统计文件，包含数十个计数器，如：
  • cache：页缓存大小。
  • rss：匿名内存和共享内存的大小。
  • swap：被换出到交换空间的大小。
  • active_anon / inactive_anon：活跃/非活跃匿名页。
  • active_file / inactive_file：活跃/非活跃文件页。
  • … 这些统计是内核进行 per-cgroup 回收决策的依据。

其他高级控制：

• memory.swappiness：控制该cgroup内匿名页的相对回收权重。可以覆盖全局的/proc/sys/vm/swappiness设置。
• memory.oom_control：用于控制cgroup的OOM行为（详见下文）。

三、 OOM killer工作机制：从全局到局部的演变

传统的OOM Killer是全局性的，它会在整个系统中挑选进程终止。在cgroup时代，OOM Killer的工作方式变得更加精细和隔离。

Cgroup-local OOM

当某个memory cgroup的内存使用达到其硬限制（memory.limit_in_bytes），并且其内部的内存回收无法释放出足够空间时，会触发cgroup局部的OOM。

其处理流程如下：

1. 触发：cgroup内进程尝试分配内存，直接回收失败，且无法从伙伴系统获得空闲页。
2. 通知：内核生成日志：“Memory cgroup out of memory”。
3. 决策：
   • 如果该cgroup的memory.oom_control中的oom_kill_disable标志为1，则内核会挂起当前正在尝试分配内存的进程（使其进入D状态，不可中断睡眠），而不是杀死它。管理员可以后续介入，手动扩容或杀死进程。
   • 如果oom_kill_disable为0（默认），则OOM Killer被激活。
4. 选择受害者：OOM Killer的评分机制仅在触发OOM的cgroup内部进行。它会计算该cgroup内所有进程的oom_score（基于驻留内存、CPU时间、进程优先级等），并选择分数最高的进程作为受害者。
5. 终止：向选中的进程发送SIGKILL信号将其终止，从而立即释放其占用的所有资源。
6. 恢复：内存被释放后，之前被阻塞的分配请求得以继续。

全局OOM

即使使用了cgroup，全局OOM仍然可能发生。例如，所有cgroup的总和限制超过了机器物理内存，或者内核自身需要分配内存（GFP_KERNEL）但所有内存都已耗尽。

此时，OOM Killer会回退到全局模式，在所有进程中挑选受害者。然而，在现代容器化环境中，配置了合理cgroup限制后，全局OOM应该极为罕见。大部分OOM事件都应该是被隔离的cgroup-local OOM。

总结

Memory cgroup是Linux容器化技术的基石（如Docker、Kubernetes），它实现了：

• 隔离性：为进程组提供独立的内存资源视图，防止相互干扰。
• 可限制性：通过硬限和软限，精确控制内存消耗的上限。
• 可核算性：提供详尽的统计信息，实现成本核算和性能分析。
• 可控的OOM：将破坏性的OOM事件隔离在单个cgroup内，而非波及整个系统，极大地提升了系统的整体稳定性和可预测性。

理解memory cgroup，对于任何从事系统运维、云平台开发或容器相关工作的人来说，都是至关重要的。它赋予了管理员精细控制和管理系统内存资源的强大能力。