Linux 内核 cgroup v2 资源隔离深度实战——从权重分配到 memory.high 软限制与 IO 限速的生产级调优

引言：为什么 cgroup v2 终于统一了资源控制

在 Linux 容器化技术栈中，控制组（cgroup）是资源隔离的基石。自 2.6.24 内核首次引入 cgroup 以来，v1 版本长期面临多控制器层级树不一致的核心缺陷：每个子系统（cpu、memory、blkio）维护独立的层级树，导致策略冲突与资源分配歧义。cgroup v2 从 4.5 内核开始逐步成熟，通过统一层级树、递归资源统计、持续压力通知三大原则，彻底解决了 v1 的架构痛点。

截至 2024 年，systemd 已默认启用 cgroup v2，Docker、containerd、Kubernetes 1.26+ 全面迁移至 v2。本文将从内核数据结构、控制器机制、生产调优三个层面，深入剖析 cgroup v2 的完整资源隔离能力。

一、架构演进：从 v1 的混乱层级到 v2 的统一树

1.1 v1 的核心矛盾：多树交叉

在 cgroup v1 中，每个控制器拥有独立的层级树。一个进程可以同时位于 cpu 组的 /groupA、memory 组 /groupB，这种交叉导致不同控制器的统计口径不一致、策略冲突以及复杂度的指数级增长（N 个控制器 × M 层级的排列组合）。

1.2 v2 的统一树设计

cgroup v2 采用单一层级树，所有控制器在同一棵树下协同工作。核心设计约束：进程只能附加到叶子节点（内部节点仅用于流量分流控制）；统一统计口径（所有控制器从同一 cgroup 节点读取进程列表）；递归会计原则（子 cgroup 的资源消耗始终向父 cgroup 上报）。这一设计与 systemd 的 slice/service/unit 体系完美契合。

二、核心控制器机制深度解析

2.1 CPU 控制器：带宽 vs 权重

2.1.1 权重模式：cpu.weight（默认）

基于"权重比例"的 CPU 时间分配。取值范围 1-10000，默认 100。计算公式为：本地 cgroup 获得的 CPU 比例 = 本地 cpu.weight / 所有 sibling 的 cpu.weight 之和。权重模式的精髓在于只在 CPU 争抢时生效：若 sibling 空闲，本地 cgroup 可以超额使用剩余 CPU，最大化资源利用率。

2.1.2 硬限额模式：cpu.max

Format: $MAX $PERIOD，其中 $MAX 为每周期内允许消耗的 CPU 时间（quota），单位为微秒。示例：100000 100000 表示 1 核 100% 配额，50000 100000 表示限制到 50% 单核。超额流量将遭遇带宽节流（bandwidth throttling），进程被调度器跳过直到下个周期重置。

2.1.3 cpu.pressure：PSI 持续压力停滞

v2 集成 PSI（Pressure Stall Information）接口，cpu.pressure 返回 10/60/300 秒窗口内的平均阻塞时间百分比。"some" 行表示至少一个任务被阻塞，"full" 行表示所有任务同时阻塞，这是容量规划的重要信号。

2.2 内存控制器：限制、保护与回收

2.2.1 memory.max：硬性 OOM 上限

类似于 v1 的 memory.limit_in_bytes，但行为更严格：当 cgroup 总用量触及 memory.max 时，页分配直接失败，触发 OOM killer 回收。这是最后的防线。

2.2.2 memory.high：软限制与 throttle（核心创新）

cgroup v2 最精妙的设计之一。当用量超过 memory.high 时，不是立即 OOM，而是触发立即回收（direct reclaim）主动回收 inactive 页面；对回收速度超过降低速度的 cgroup 实施 CPU throttle 来减缓内存增长速度；进程短暂卡顿但避免 OOM 灾难。生产调优建议设为 memory.max 的 70-80%，给予回收缓冲。

2.2.3 memory.low：最低保障

保护关键 cgroup 不被其他兄弟挤出内存保障线。内核保证此 cgroup 的用量优先满足，回收压力不会向低于 memory.low 的 cgroup 传递。

2.2.4 memory.min：硬保留

绝对保留量，即使系统内存充裕，此内存也不会被借用或回收。仅限极关键进程使用，如数据库 WAL buffer。

2.3 IO 控制器：带宽与 IOPS 的双重限额

2.3.1 io.max：rbps/wbps + riops/wiops

对单设备同时限制读/写的带宽和 IOPS。语法：MAJ:MIN rbps=X wbps=Y riops=A wiops=B。这比 v1 的 token bucket 更精确，支持带宽+IOPS 四维控制。

2.3.2 io.weight：权重分配

类似 cpu.weight，默认 100，范围 1-10000。基于内核 BFQ 调度器的权重实现，自然地在设备空闲时允许借用带宽。

2.3.3 io.latency：延迟保护阈值

v2 引入的延迟 SLA 机制：io.latency MAJ:MIN target=$US。当目标设备的平均 IO 延迟超过 target，内核自动 throttle 该 cgroup 的 IO，实现延迟服务质量保障。这是对数据库和实时服务的革命性特性。

2.4 PID 控制器：递归进程数限制

pids.max 防止 fork bomb 溢出。v2 中 pids.current 包含所有叶子节点进程的递归统计，比 v1 精确得多。

三、内核数据结构透视

理解 cgroup v2 的内核实现能助力调优。核心结构包括：struct cgroup（每个 cgroup 目录对应一个，含 css、parent 等）、struct cgroup_subsys（控制器注册接口，含 alloc/free/css_online 等钩子）、struct cgroup_rstat_cpu（per-CPU 递归统计缓存，解决了 v1 的 procfs 读取竞态）、psi_group（PSI 压力状态机，每 2 秒窗口周期性更新）。

v2 采用 cgroup rstat（per-CPU 递归统计缓冲区）替代 v1 的原子计数：控制器只更新自己的 per-CPU 缓冲区，读取时合并，避免了 atomic64 在多核系统上的缓存行抖动。这对 200+ 核的 NUMA 系统性能提升巨大。

四、生产级调优策略

4.1 Web 服务：CPU 弹性 + 内存 SLA

• cpu.weight=500（中等优先级，允许弹性借用）
• memory.max=4G（硬 OOM 防线）
• memory.low=1.5G（保障线，防止高峰期被挤出）
• memory.high=3.2G（软限制触发点，留 800MB OOM 缓冲）
• io.weight=300（IO 优先级低于计算）

4.2 批处理任务：hard limit 严格隔离

• cpu.max=200000 100000（严格限制 2 核，避免饥饿 web 层）
• memory.max=8G
• memory.low=0（允许完全回收，批处理应等待）
• io.max=8:0 rbps=104857600 wbps=52428800（100MB/s 读/50MB/s 写 NVMe）

4.3 数据库层：io.latency 保障

• io.latency: 8:0 target=2000000（确保 NVMe 延迟不超过 2ms）
• io.weight=800（高 IO 优先级）
• memory.min=4G（WAL buffer 绝不被回收）

五、PSI 监控与容量规划

PSI（Pressure Stall Information）是 v2 时代的监控利器。解析 memory.pressure 中 "full avg10=15.3" 表示过去 10 秒内平均有 15.3% 的任务处于全部等待内存回收的状态。

容量规划核心公式：理想 memory.max = 当前用量峰值的 120%；理想 memory.high = memory.max 的 0.75；理想 memory.low = 保障用量基线的 0.85；合理 cpu.weight = (当前用量占比 / 目标占比) × 100。

监控告警阈值建议：cpu.pressure some avg60 > 80% 需扩容；memory.pressure full avg10 > 20% 需紧急加内存；io.pressure some avg300 > 50% 需升级磁盘带宽。

六、v1 迁移 v2 实战要点

6.1 系统配置

内核引导参数 systemd.unified_cgroup_hierarchy=1 启用 v2。Debian 11+、Ubuntu 22.04+、CentOS 9 默认已启用。切换需空载操作，因为在混合模式下部分控制器会被标记为独占不可用。

6.2 控制器映射

v1 的 cpu/cpuacgt 合并为 v2 的 cpu 控制器，stat 文件合并。memory 控制器移除了 kmem 统计，OOM 行为更严格。blkio 改为 io 控制器，从 token bucket 改为 BFQ 调度。systemd 单元文件中对应 CPUQuota→cpu.max、MemoryMax→memory.max、MemoryHigh→memory.high、MemoryLow→memory.low、IOWeight→io.weight 的映射。

6.3 安全注意事项

v2 初始版本中部分控制器（如 memory.oom_group）需要显式开启。containerd 的 SystemdCgroup=true 驱动要求完整的 v2 支持。Kubernetes pod 级别的 QoS 在 v2 中通过权重间接实现，行为与 v1 有微妙差异。

七、前沿方向：cgroup 与 eBPF 的融合

Linux 5.19+ 引入 cgroup eBPF hook，允许用户空间通过 BPF 程序动态注入 cgroup 策略。BPF_CGROUP_SYSCTL 拦截 cgroup 内进程的 sysctl 调用；BPF_CGROUP_SETSOCKOPT 实现统一的网络套接字选项控制；BPF_MAP_TYPE_CGRP_STORAGE 提供 per-cgroup BPF 本地存储，为容器编写自定义控制器提供基础。

未来方向包括：通过 BPF 编写自定义调度策略动态切换 cpu.weight、基于应用 QPS 自动调整 memory.high、使用 LSM BPF 替代 SELinux 的 cgroup 安全策略。内核已将 cgroup 从静态容器向可编程资源平面演进。

总结

cgroup v2 不是一个增量修复，而是对 Linux 容器资源模型的彻底重构。从权重分配的弹性到 io.latency 的延迟保证，从软限制 memory.high 避免 OOM 到 PSI 压力监控，每一步都体现了"不浪费、不挤占、可观测"的生产哲学。掌握 v2 不仅是运维技术，更是优化资源利用率、保障服务稳定性的核心能力。

在云原生密度与日俱增的今天，理解 cgroup v2 的深度机制，将使你在容器化战争中掌握资源调度的主动权。当每一核 CPU、每一字节内存、每一 IOPS 都被精准计量与控制时，你才真正拥有了驾驭现代 Linux 系统的底蕴。