操作系统 cgroups 对进程资源的有效管理-CSDN博客

本文链接：https://blog.csdn.net/2501_91590464/article/details/148526612

操作系统cgroups：给进程资源分配装个"智能管家"

关键词：cgroups、进程资源管理、Linux内核、资源隔离、容器技术

摘要：当你的电脑同时运行视频剪辑、游戏和下载任务时，为什么有时会卡住？这是进程间资源争夺的典型场景。本文将带你认识Linux系统中的"资源大管家"——cgroups（Control Groups），用通俗易懂的语言解释它如何像幼儿园老师分配零食一样，公平高效地管理进程的CPU、内存等资源。我们将从核心概念讲到实战操作，最后揭秘它在Docker/Kubernetes等容器技术中的关键作用。

背景介绍

目的和范围

在多任务操作系统中，进程就像一群抢玩具的小朋友：有的"贪心"进程会霸占CPU不放，有的"大胃王"进程会吃掉所有内存，导致其他进程"饿肚子"。cgroups正是Linux内核为解决这个问题设计的机制，它能对进程的CPU、内存、磁盘IO等资源进行限制、统计和隔离。本文将覆盖cgroups的核心概念、工作原理、实战操作以及在容器中的应用。

预期读者

对操作系统原理感兴趣的开发者
想了解容器底层技术的云原生工程师
希望优化服务器资源利用率的运维人员

文档结构概述

本文将按照"故事引入→核心概念→原理剖析→实战操作→应用场景"的逻辑展开，最后总结未来趋势。你不需要提前了解内核知识，只需带着"如何让进程公平使用资源"的问题往下读。

术语表

术语	通俗解释
cgroups	进程资源管理的"智能管家"，负责分配CPU、内存等资源
子系统（Subsystem）	资源类型的"学科老师"，如CPU子系统管CPU分配，内存子系统管内存限制
控制组（Control Group）	进程的"班级"，同一组的进程共享资源配额
任务（Task）	被管理的进程/线程，就像班级里的"学生"
层级（Hierarchy）	控制组的"年级结构"，支持分层管理（如部门→项目组→具体任务）

核心概念与联系

故事引入：幼儿园的零食分配难题

想象你是幼儿园老师，班里有30个小朋友（进程），每天要分10盒饼干（CPU资源）和5包糖果（内存资源）。遇到的问题：

小明（某进程）一次拿5盒饼干，导致其他小朋友没得吃（CPU被占满）
小红（某进程）偷偷藏了3包糖果，其他小朋友只能饿肚子（内存泄漏）
手工课小组（某类进程）需要更多彩笔（磁盘IO），但总被游戏组抢光（IO竞争）

这时你需要：

给每个小组（控制组）分配固定饼干量（CPU配额）
限制每个小朋友最多拿2包糖果（内存上限）
统计手工组用了多少彩笔（IO统计）
当有人抢太多时，老师（cgroups）会及时制止

这就是cgroups在操作系统中的角色——做进程资源的"公平分配员"。

核心概念解释（像给小朋友讲故事）

核心概念一：子系统（Subsystem）——不同学科的老师

子系统是cgroups的"专业管理员"，每个子系统负责一种资源类型的管理。就像幼儿园里：

饼干老师（CPU子系统）：负责分配饼干（CPU时间）
糖果老师（内存子系统）：负责分配糖果（内存空间）
彩笔老师（IO子系统）：负责分配彩笔（磁盘IO带宽）

常见子系统有：

cpu：控制CPU时间分配
memory：限制内存使用上限
blkio：限制磁盘IO速度
cpuset：为进程分配特定CPU核心（适用于多核服务器）

核心概念二：控制组（Control Group）——进程的班级

控制组是进程的"班级"，同一组的进程共享资源配额。比如：

游戏组（控制组A）：最多拿3盒饼干（CPU配额30%）
学习组（控制组B）：最多拿5盒饼干（CPU配额50%）
空闲组（控制组C）：剩下的2盒饼干（CPU配额20%）

每个控制组对应/sys/fs/cgroup下的一个文件夹，里面有各种配置文件（如cpu.shares设置CPU权重）。

核心概念三：任务（Task）——班级里的学生

任务就是被管理的进程或线程，就像班级里的学生。一个学生（进程）可以属于多个班级（控制组）吗？答案是可以！比如一个进程既属于"游戏组"（CPU限制），又属于"内存限制组"（内存上限）。

核心概念四：层级（Hierarchy）——年级结构

层级是控制组的"树形结构"，支持分层管理。比如：

学校（根控制组）
├─ 一年级（部门控制组）
│  ├─ 一班（项目组控制组）
│  └─ 二班（测试组控制组）
└─ 二年级（其他部门控制组）

子控制组会继承父控制组的资源限制（可以覆盖），这种结构让资源管理更灵活（比如公司按部门→项目→任务分层限制资源）。

核心概念之间的关系（用幼儿园打比方）

概念关系	通俗解释
子系统 vs 控制组	饼干老师（CPU子系统）会去每个班级（控制组）检查饼干分配是否符合要求（如`cpu.shares`）
控制组 vs 任务	每个班级（控制组）的学生名单（进程PID）存在`tasks`文件里，老师按名单管理资源
层级 vs 控制组	年级结构（层级）让班级（控制组）可以分组管理（如一年级所有班级共享总饼干量）

核心概念原理和架构的文本示意图

内核空间
┌───────────────────────┐
│     cgroups核心模块    │
│ ┌───────────────┐     │
│ │  子系统插件   │     │  （如cpu、memory子系统）
│ └───────────────┘     │
└────────┬──────────────┘
用户空间               ▲
┌────────┼───────────────┐
│ /sys/fs/cgroup文件系统 │  （通过文件读写配置cgroups）
│ ├─ cpu/              │  （CPU子系统控制组目录）
│ │  ├─ groupA/        │  （控制组A的配置文件）
│ │  │   ├─ tasks      │  （控制组A的进程列表）
│ │  │   └─ cpu.shares │  （控制组A的CPU权重）
│ └─ memory/           │  （内存子系统控制组目录）
└───────────────────────┘

Mermaid 流程图（cgroups管理流程）

graph TD
    A[用户创建控制组] --> B[在/sys/fs/cgroup下生成目录]
    B --> C[设置资源参数（如cpu.shares=512）]
    C --> D[将进程PID写入tasks文件]
    D --> E[内核子系统监控进程资源使用]
    E --> F{是否超配额?}
    F -- 是 --> G[限制资源使用（如CPU throttling）]
    F -- 否 --> H[正常使用资源]

核心算法原理 & 具体操作步骤

CPU资源分配的核心算法：权重比例分配

cgroups的CPU子系统默认使用权重比例算法。假设总CPU时间为100%，每个控制组的cpu.shares值代表权重（默认1024）。分配规则：
$\frac{该组shares值}{所有活跃组shares总和} \times 100\%$

举个栗子：

控制组A：cpu.shares=512（权重512）
控制组B：cpu.shares=1024（权重1024）
总权重=512+1024=1536
组A获得：512/1536≈33.3% CPU时间
组B获得：1024/1536≈66.7% CPU时间

如果组A没有进程运行（无活跃任务），组B可以独占100% CPU时间（因为总权重变为1024）。

内存限制的核心逻辑：OOM控制

内存子系统通过memory.limit_in_bytes设置内存上限。当进程尝试超过限制时，内核会：

先尝试回收不活跃的内存（如缓存）
如果还不够，触发OOM（Out Of Memory）机制
OOM killer会根据进程优先级（memory.oom_control）选择"杀死"哪个进程

具体操作步骤（以CPU限制为例）

1. 检查cgroups挂载情况（cgroup v1）

# 查看已挂载的cgroups子系统
mount | grep cgroup
# 输出示例（表示cpu子系统挂载在/sys/fs/cgroup/cpu）
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)

2. 创建控制组目录

# 创建名为mygroup的控制组（属于cpu子系统）
sudo mkdir /sys/fs/cgroup/cpu/mygroup

3. 设置CPU权重（shares）

# 默认shares是1024，设置为512（权重减半）
echo 512 | sudo tee /sys/fs/cgroup/cpu/mygroup/cpu.shares

4. 将进程加入控制组

# 启动一个CPU密集型进程（这里用stress工具）
stress --cpu 1 &  # 启动后记录PID（假设是12345）
# 将PID写入控制组的tasks文件
echo 12345 | sudo tee /sys/fs/cgroup/cpu/mygroup/tasks

5. 验证效果

# 观察CPU使用率（用top命令）
top -p 12345  # 应该看到该进程CPU使用率约33%（假设只有它和默认组竞争）

数学模型和公式 & 详细讲解 & 举例说明

CPU时间分配公式

假设系统有N个活跃控制组，各控制组的shares值为 $s_1, s_2, ..., s_N$ ，则控制组i获得的CPU时间比例为：
$R_i = \frac{s_i}{\sum_{j=1}^N s_j} \times 100\%$

举例：

控制组A（s=2048）、控制组B（s=1024）、控制组C（s=512）
总s=2048+1024+512=3584
R_A=2048/3584≈57.1%，R_B=1024/3584≈28.6%，R_C=512/3584≈14.3%

内存限制的水位线模型

内存子系统支持软限制（memory.soft_limit_in_bytes）和硬限制（memory.limit_in_bytes）：

当内存使用超过软限制但未超硬限制时，内核会开始回收内存（不杀死进程）
当超过硬限制时，触发OOM killer

磁盘IO限制公式（blkio子系统）

blkio.throttle.read_bps_device可以限制磁盘读带宽，格式为设备号字节/秒。例如：

echo "8:0 10485760" | sudo tee /sys/fs/cgroup/blkio/mygroup/blkio.throttle.read_bps_device

表示对设备号8:0（通常是/sda）限制读速度为10MB/s（10×1024×1024）。

项目实战：用cgroups限制Redis内存

目标

限制Redis进程最多使用512MB内存，防止它"吃"光服务器内存。

开发环境搭建

系统：Ubuntu 20.04（内核5.4+）
工具：redis-server、cgroup-tools（可选）

源代码详细实现和代码解读

1. 挂载内存子系统（如果未挂载）

sudo mount -t cgroup -o memory none /sys/fs/cgroup/memory

2. 创建Redis控制组

sudo mkdir /sys/fs/cgroup/memory/redis-group

3. 设置内存限制（512MB）

# 512MB = 512×1024×1024 = 536870912字节
echo 536870912 | sudo tee /sys/fs/cgroup/memory/redis-group/memory.limit_in_bytes

4. 启动Redis并加入控制组

# 启动Redis（假设PID为6789）
redis-server &
# 将PID写入控制组tasks文件
echo 6789 | sudo tee /sys/fs/cgroup/memory/redis-group/tasks

5. 验证内存限制

# 观察Redis内存使用（用pmap命令）
pmap 6789 | tail -n 1  # 查看总内存使用，应该不超过512MB

# 尝试让Redis存储超过512MB数据（用redis-cli）
redis-cli set bigkey "$(head -c 600M /dev/urandom | base64)"
# 应该会报错：OOM command not allowed when used memory > 'maxmemory'

代码解读与分析

memory.limit_in_bytes是硬限制，Redis尝试超过时会触发OOM
控制组的memory.usage_in_bytes文件实时显示当前内存使用量
memory.stat文件包含详细统计（如缓存、进程内存等）

实际应用场景

1. 容器技术（Docker/Kubernetes）

Docker通过cgroups实现容器资源隔离：

--cpus 2：限制容器使用2核CPU（通过cpu.cfs_quota_us实现）
--memory 1g：限制容器使用1GB内存（通过memory.limit_in_bytes实现）

Kubernetes的Pod资源配置（requests和limits）本质上是调用cgroups接口。

2. 服务器资源分层管理

企业服务器可以按部门分层限制资源：

根控制组（总CPU=16核）
├─ 研发部（CPU=10核）
│  ├─ 项目A（CPU=5核）
│  └─ 项目B（CPU=5核）
└─ 测试部（CPU=6核）

3. 防止进程"饿死"

通过限制高优先级进程的资源使用，保证低优先级进程至少获得基本资源（如设置cpu.shares=2048让关键进程获得更多CPU时间）。

工具和资源推荐

工具/资源	说明
`cgexec`	快速将进程加入控制组（如`cgexec -g cpu:mygroup stress --cpu 1`）
`cgcreate`	创建控制组（`cgcreate -g cpu:mygroup`）
`cgroupfs-mount`	自动挂载cgroups文件系统（适用于旧系统）
Linux内核文档	`Documentation/cgroup-v1/cgroups.txt`（cgroup v1详细说明）
Docker官方文档	查看容器如何利用cgroups（https://docs.docker.com/config/containers/resource_constraints/）

未来发展趋势与挑战

趋势1：cgroup v2成为主流

cgroup v2（内核4.5+）相比v1有重大改进：

统一层级：所有子系统共享一个层级（v1每个子系统独立层级）
更高效：减少内核开销（v2用树结构代替v1的链表）
支持新特性：如memory.numa_stat（NUMA内存统计）

趋势2：与云原生深度整合

Kubernetes 1.25+已默认使用cgroup v2，未来云厂商会基于cgroup v2实现更细粒度的资源调度（如混合部署CPU密集型和内存密集型工作负载）。

挑战1：配置复杂性

cgroup参数众多（如CPU的shares、cfs_quota、rt_runtime），新手容易混淆。需要更友好的工具（如Kubernetes的资源模型）简化配置。

挑战2：内核兼容性

旧系统（如内核<4.5）不支持cgroup v2，混合部署时需要考虑兼容性（如Docker的--cgroup-driver参数）。

总结：学到了什么？

核心概念回顾

子系统：管理特定资源（CPU、内存等）的"专业老师"
控制组：进程的"班级"，共享资源配额
任务：被管理的进程/线程（“班级里的学生”）
层级：控制组的"年级结构"，支持分层管理

概念关系回顾

子系统通过控制组管理任务（饼干老师通过班级管理学生）
层级让控制组可以分组管理（年级→班级→学生）
所有操作通过/sys/fs/cgroup文件系统完成（配置像修改文本文件一样简单）

思考题：动动小脑筋

如果有两个控制组，A的cpu.shares=1024，B的cpu.shares=2048，当两个组都有活跃进程时，它们的CPU时间比例是多少？如果A组没有进程运行，B组能获得多少CPU时间？
如果你是运维工程师，需要限制部门A的所有进程最多使用4GB内存，你会如何用cgroups实现？（提示：可以创建层级结构）
Docker的--memory-swap参数和cgroups的哪个文件相关？（提示：查memory.swappiness和memory.memsw.limit_in_bytes）

附录：常见问题与解答

Q：如何查看进程属于哪些控制组？
A：查看/proc/[PID]/cgroup文件，例如：

cat /proc/12345/cgroup
# 输出示例（表示进程12345属于cpu子系统的mygroup控制组）
11:cpu:/mygroup

Q：cgroup v1和v2的主要区别是什么？
A：v2统一了层级（所有子系统共享一个树结构），支持更高效的资源统计，并且弃用了部分v1的子系统（如cpuacct合并到cpu）。

Q：设置内存限制后，进程为什么还能使用超过限制的内存？
A：可能是因为设置了memory.memsw.limit_in_bytes（包括交换空间），或者进程使用了共享内存（SHM），需要额外限制memory.deny_writeback。

扩展阅读 & 参考资料

Linux内核文档：https://www.kernel.org/doc/Documentation/cgroup-v2.txt
Docker资源限制指南：https://docs.docker.com/config/containers/resource_constraints/
cgroups官方维基：https://en.wikipedia.org/wiki/Cgroups
《深入理解Linux内核》（第3版）——cgroups章节