简介在现代 Linux 服务架构中容器、虚拟机、多租户业务集群已经成为服务器部署的主流形态。一台物理机往往同时运行数十个容器、多组业务进程如何精准划分 CPU 算力、避免单个租户业务耗尽整机 CPU 资源、实现租户间资源强隔离是运维、内核开发、云原生工程师必须解决的核心问题。LinuxCFS 完全公平调度器原生支持组调度Group Scheduling机制而 cgroup控制组则是用户态与内核组调度交互的标准接口二者深度结合构成了 Linux 容器 CPU 资源隔离的底层基石。我们日常使用的 Docker、Kubernetes、LXC 等容器技术其 CPU 配额、权重分配、资源限制功能全部依赖cpu子系统 cgroup CFS 组调度实现。传统单任务调度仅针对进程做 CPU 时间均分无法满足批量进程的整体资源管控需求。组调度将一组关联进程视为一个调度实体先在组与组之间分配 CPU 资源再在组内进程间做二次调度配合 cgroup 的cpu.shares权重配置、CPU 配额限制就能实现精细化的资源隔离与优先级划分。对于底层研发人员而言吃透组调度与 cgroup 的联动逻辑能够深入理解容器资源限流、抢占、CPU 争抢异常的根因对于云原生运维、容器开发工程师掌握这套机制可以合理规划容器资源、优化集群调度性能、排查 CPU 资源争抢类线上故障。本文从原理、环境、实战代码、排错、最佳实践全维度讲解内容基于主流 Linux 长期内核版本附带大量可复现的命令与内核源码可直接用于技术报告、论文撰写与工程落地。一、核心概念与术语解析1.1 CFS 调度基础CFS完全公平调度器是 Linux 2.6.23 及之后版本默认的普通进程调度器核心设计思想是模拟理想并行 CPU让所有就绪进程尽可能公平地分享 CPU 时间。vruntime虚拟运行时间CFS 核心计量值单位纳秒。进程每占用 CPU 执行一段时间vruntime 就会累加。调度器永远选择vruntime 最小的进程运行以此实现公平调度。调度实体sched_entityCFS 的调度单元不仅可以是单个进程也可以是一个进程组这也是组调度实现的基础。运行队列 rq每个 CPU 核心拥有独立运行队列队列内就绪调度实体以红黑树排序排序依据为 vruntime。1.2 组调度Fair Group Scheduling普通 CFS 仅对单个进程做公平调度而组调度开启CONFIG_FAIR_GROUP_SCHED会改变调度层级系统先将 CPU 资源按照权重分配给不同任务组每个任务组内部再按照标准 CFS 规则将分配到的 CPU 资源平分给组内所有进程。简单来说组间按权重分配组内按公平调度。组调度天然解决了 “一组进程整体抢占资源” 的问题是多租户隔离的核心。1.3 cgroup 控制组cgroup 是 Linux 内核提供的资源管控框架用于对一组进程做资源限制、统计、隔离。其中cpu子系统专门对接 CFS 组调度cpu.shares组调度核心配置项代表任务组的 CPU 权重默认值1024。权重仅在组间竞争 CPU时生效数值越大分到的 CPU 时间越多。tasks文件向该文件写入进程 PID即可将进程加入当前 cgroup 任务组。cpu.cfs_quota_us / cpu.cfs_period_us硬 CPU 配额限制任务组在单个周期内最大可使用的 CPU 时长用于做硬限流。1.4 关键内核配置与依赖想要启用组调度与 cgroup CPU 隔离内核必须开启以下编译选项CONFIG_CGROUPS总开关启用 cgroup 功能CONFIG_FAIR_GROUP_SCHED启用 CFS 组调度本文核心CONFIG_CGROUP_CPUACCTCPU 资源统计CONFIG_CPUSETS可选配合实现进程与 CPU 核心绑定。1.5 调度层级关系整机 CPU 资源 → 多个 cgroup 任务组按cpu.shares权重瓜分 → 组内多个进程CFS 公平调度。 该层级模型也是 Docker/K8s CPU 资源调度的底层逻辑。二、环境准备2.1 软硬件环境清单分类版本 / 配置要求用途说明操作系统Ubuntu 20.04 / 22.04、CentOS 7/8/964 位主流服务端发行版默认开启 cgroup v1 与组调度内核版本Linux 5.4、5.10、5.15LTS 长期版组调度、cpu 子系统逻辑完全一致兼容性最好硬件x86_64 多核 CPU≥2 核、4G 以上内存多核便于观测组间 CPU 抢占效果工具集gcc、stress、util-linux、trace-cmd、perf压力测试、调度跟踪、性能观测文件系统debugfs、tmpfscgroup 挂载、内核调试跟踪说明本文基于cgroup v1讲解目前容器生产环境主流cgroup v2 逻辑同源仅挂载与配置接口略有差异。2.2 环境检查与基础配置1. 检查内核是否启用组调度与 cgroup执行以下命令校验内核配置# 检查是否开启cgroup与CFS组调度 zcat /proc/config.gz | grep -E CGROUPS|FAIR_GROUP_SCHED正常输出示例CONFIG_CGROUPSy CONFIG_FAIR_GROUP_SCHEDy CONFIG_CGROUP_CPUACCTy若输出为# CONFIG_xxx is not set则需要重新编译内核开启对应选项。2. 安装依赖工具# Ubuntu/Debian 系列 sudo apt update sudo apt install -y stress gcc trace-cmd perf # CentOS/RHEL 系列 sudo yum install -y stress gcc trace-cmd perf工具说明stress生成 CPU 密集型压力进程模拟业务负载perf观测进程 CPU 占用、调度行为trace-cmd/ftrace跟踪内核组调度函数调用。3. 挂载 cgroup cpu 子系统主流系统默认已挂载 cgroup手动挂载命令适用于未自动挂载环境# 创建cgroup根目录 sudo mkdir -p /sys/fs/cgroup/cpu # 挂载cpu子系统cgroup sudo mount -t cgroup -o cpu none /sys/fs/cgroup/cpu # 查看挂载结果 ls /sys/fs/cgroup/cpu挂载成功后目录下会出现cpu.shares、tasks、cpu.cfs_*等标准配置文件。2.3 内核源码路径说明组调度与 cgroup 交互核心源码位置后续代码分析以此为准kernel/sched/fair.c # CFS组调度核心逻辑、调度实体维护 kernel/cgroup/cpu.c # cgroup cpu子系统接口、cpu.shares读写逻辑 include/linux/sched.h # 调度实体、任务组结构体定义 include/linux/cgroup.h # cgroup基础结构体三、应用场景组调度 cgroup CPU 隔离是云原生、服务器运维领域的基础设施落地场景十分广泛。在公有云多租户服务器中云厂商通过 cgroup 为每个租户分配独立任务组配置不同cpu.shares权重防止单个租户的高负载业务抢占整机 CPU保障多租户平稳运行。容器场景下Docker、K8s 会为每个容器创建独立 cgroup 组根据业务优先级设置 CPU 权重与硬配额核心业务容器分配更高权重后台日志、监控容器降低权重。在企业内部服务器中运维人员可将线上业务、测试程序、数据分析任务划分至不同 cgroup 组限制测试任务的 CPU 占用避免影响生产业务。此外虚拟化 KVM 虚拟机也依赖该机制对虚拟机整体做 CPU 资源划分实现宿主机与虚拟机、虚拟机之间的资源隔离整套机制支撑了现代服务器多业务混部的稳定性。四、实际案例与步骤命令 源码 实操本章分为用户态 cgroup 实操、内核源码解析、压力测试验证三部分所有代码、命令均可直接复制运行。4.1 基础实操创建任务组、配置 cpu.shares、迁移进程目标创建两个 cgroup 任务组设置不同 CPU 权重放入压力进程观测资源分配差异。步骤 1创建两个测试任务组# 进入cpu cgroup根目录 cd /sys/fs/cgroup/cpu # 创建group1、group2两个任务组 sudo mkdir group1 sudo mkdir group2查看目录每个子目录都会自动生成全套 cgroup 配置文件ls group1/步骤 2配置 cpu.shares 权重cpu.shares默认值为 1024我们设置两组权重比例为2:1# group1 权重 2048 echo 2048 | sudo tee group1/cpu.shares # group2 权重 1024 echo 1024 | sudo tee group2/cpu.shares原理说明当两个组同时争抢 CPU 时在多核满载场景下group1 与 group2 获得的 CPU 时间比例约为 2048:1024 2:1。权重仅在资源竞争时生效CPU 空闲时所有组均可占满资源。步骤 3创建 CPU 压力进程并迁移至对应组打开两个独立终端执行压力命令模拟 CPU 密集型任务# 终端1创建4个CPU压力进程根据CPU核心数调整 stress -c 4 # 记录该进程组PID取主进程PID echo $!假设 PID 为10001将其迁移到group1echo 10001 | sudo tee group1/tasks# 终端2同样创建4个CPU压力进程 stress -c 4 echo $!假设 PID 为10002迁移到group2echo 10002 | sudo tee group2/tasks步骤 4观测 CPU 占用比例使用top/htop/perf观测整机 CPU 分配top在多核满载状态下能清晰看到group1内进程总 CPU 占用约为group2的 2 倍完全符合我们设置的2048:1024权重比例。步骤 5清理测试环境测试完成后停止压力进程并删除任务组# 结束stress进程 pkill stress # 删除cgroup组必须先清空tasks sudo rmdir group1 group24.2 进阶实操硬 CPU 配额限制cfs_quota除了权重cgroup 还支持硬 CPU 上限限制适用于严格限流场景。cpu.cfs_period_us调度周期单位微秒默认 100000100mscpu.cfs_quota_us单个周期内允许使用的 CPU 时长单位微秒。示例限制 group1 在 100ms 周期内最多使用1 核 CPU100000uscd /sys/fs/cgroup/cpu sudo mkdir group1 # 设置周期为100ms echo 100000 | sudo tee group1/cpu.cfs_period_us # 设置配额为100ms最多占用1个核心 echo 100000 | sudo tee group1/cpu.cfs_quota_us # 放入压力进程 stress -c 4 echo $! | sudo tee group1/tasks观测结果无论组内有多少 CPU 压力进程该组整体 CPU 占用不会超过 100%1 核实现硬限流。4.3 内核源码解析组调度与 cpu.shares 底层逻辑4.3.1 任务组核心结构体sched.h开启CONFIG_FAIR_GROUP_SCHED后内核使用struct task_group描述一个调度任务组对应一个 cgroup cpu 组// include/linux/sched.h 核心结构体节选 struct task_group { /* 每个CPU对应的组运行队列 */ struct cfs_rq **cfs_rq; /* 组的CPU权重对应cgroup cpu.shares */ unsigned long shares; /* 组内调度实体 */ struct sched_entity se; #ifdef CONFIG_FAIR_GROUP_SCHED /* 层级关系、cgroup关联指针 */ struct task_group *parent; struct list_head siblings; struct list_head children; #endif /* 其他统计、带宽控制成员省略 */ };代码说明shares字段直接对应用户态cpu.shares配置项写入 cgroup 文件本质就是修改该内核变量cfs_rq是每个 CPU 核心对应的组 CFS 运行队列组调度的红黑树、vruntime 全部维护在此每个 cgroup 任务组在内核中都会映射为一个task_group实例。4.3.2 cpu.shares 读写接口cpu.c用户态执行echo xxx cpu.shares最终调用内核cpu_cgroup_write函数节选核心代码// kernel/cgroup/cpu.c static ssize_t cpu_cgroup_write(struct kernfs_file *f, const char *buf, size_t nbytes, loff_t *off) { struct cgroup *cgrp file_cgroup(f); struct task_group *tg cgroup_tg(cgrp); unsigned long shares; int ret; /* 将用户态字符串转为数值 */ ret kstrtoul(buf, 10, shares); if (ret || shares 1) return -EINVAL; /* 更新任务组权重并触发调度实体刷新 */ sched_group_set_shares(tg, shares); return nbytes; }代码作用接收用户态写入的权重值调用sched_group_set_shares更新内核task_group-shares并重新计算组调度权重。4.3.3 组调度权重生效逻辑fair.cCFS 在计算调度实体权重、vruntime 偏移时会优先读取任务组 shares再读取进程自身 nice 权重// kernel/sched/fair.c static unsigned long calc_group_shares(struct task_group *tg) { /* 返回当前任务组的总权重即cpu.shares值 */ return tg-shares; } /* 组间调度实体选择逻辑 */ static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq) { /* 组调度下先选组再选组内进程 */ struct sched_entity *se __pick_first_entity(cfs_rq); return se; }核心逻辑当存在多个任务组时CFS 运行队列中挂载的是组调度实体调度器根据各组shares计算虚拟运行时间权重越高vruntime 增长越慢被选中执行的概率越大选中某个组之后再进入组内队列按照普通 CFS 规则选择进程。4.3.4 进程加入 cgroup 组的内核逻辑将 PID 写入tasks文件内核会执行进程调度组迁移核心流程// 简化版流程函数 void sched_move_task(struct task_struct *tsk) { /* 1. 将进程从旧任务组出队 */ dequeue_task(tsk, DEQUEUE_SLEEP); /* 2. 修改进程所属task_group指针 */ tsk-sched_task_group new_tg; /* 3. 将进程加入新任务组队列 */ enqueue_task(tsk, ENQUEUE_WAKEUP); }每次进程跨组迁移都会重新调整红黑树与 vruntime保证组调度规则生效。4.4 内核跟踪ftrace 观测组调度函数调用使用 ftrace 跟踪组调度核心函数直观验证执行链路命令可直接复制# 挂载debugfs若未挂载 sudo mount -t debugfs none /sys/kernel/debug # 清空跟踪缓存 sudo echo /sys/kernel/debug/tracing/trace # 设置要跟踪的组调度、cgroup函数 sudo echo sched_group_set_shares /sys/kernel/debug/tracing/set_ftrace_filter sudo echo cpu_cgroup_write /sys/kernel/debug/tracing/set_ftrace_filter sudo echo sched_move_task /sys/kernel/debug/tracing/set_ftrace_filter # 开启跟踪 sudo echo function /sys/kernel/debug/tracing/current_tracer sudo echo 1 /sys/kernel/debug/tracing/tracing_on此时重新执行修改 cpu.shares、迁移进程操作然后停止跟踪并查看日志sudo echo 0 /sys/kernel/debug/tracing/tracing_on sudo cat /sys/kernel/debug/tracing/trace日志解读可以清晰看到cpu_cgroup_write写 cpu.shares→sched_group_set_shares更新组权重的调用链路完整复现内核执行流程。4.5 自定义测试程序代码实现进程加入 cgroup编写 C 语言代码在程序内部将自身加入指定 cgroup 组脱离命令行手动操作适合嵌入式、容器底层开发场景#include stdio.h #include stdlib.h #include unistd.h #include fcntl.h #include string.h #define CGROUP_CPU_PATH /sys/fs/cgroup/cpu/mygroup /* 将当前进程PID加入指定cgroup的tasks文件 */ int move_self_to_cgroup(void) { char tasks_path[256]; char pid_buf[32]; int fd, ret; // 拼接tasks文件路径 snprintf(tasks_path, sizeof(tasks_path), %s/tasks, CGROUP_CPU_PATH); // 打开tasks文件 fd open(tasks_path, O_WRONLY); if (fd 0) { perror(open tasks failed); return -1; } // 将当前PID转为字符串 snprintf(pid_buf, sizeof(pid_buf), %d, getpid()); // 写入PID完成进程迁移 ret write(fd, pid_buf, strlen(pid_buf)); if (ret 0) { perror(write pid failed); close(fd); return -1; } close(fd); printf(Process %d move to cgroup success\n, getpid()); return 0; } int main(void) { // 第一步调用函数加入cgroup if (move_self_to_cgroup() 0) { return -1; } // 模拟CPU密集型业务 printf(Run CPU busy loop...\n); while(1) { // 空循环占用CPU } return 0; }编译与运行步骤# 1. 提前创建cgroup组 sudo mkdir /sys/fs/cgroup/cpu/mygroup # 2. 编译代码 gcc cgroup_demo.c -o cgroup_demo # 3. 运行程序需要root权限操作cgroup sudo ./cgroup_demo代码说明程序启动后主动将自身 PID 写入 cgroup 的tasks文件内核自动完成调度组迁移后续该进程的 CPU 资源完全受mygroup的cpu.shares和配额限制。五、常见问题与解答Q1设置了 cpu.shares 权重但 CPU 空闲时两组占用比例不是设定值解答cpu.shares是竞争权重仅当整机 CPU 满载、组间发生资源争抢时比例才会严格生效。CPU 资源充足时所有任务组都会占满空闲 CPU权重规则不触发。测试权重必须用stress打满整机 CPU。Q2修改 cpu.shares 之后需要重启进程才能生效吗解答不需要。修改cpu.shares会直接调用内核sched_group_set_shares更新任务组权重CFS 调度器在下一次调度周期就会应用新权重进程无需重启、无需重新迁移。Q3进程已经写入 tasks 文件但不受 cgroup CPU 限制解答常见三个原因内核未开启CONFIG_FAIR_GROUP_SCHED组调度进程存在子线程 / 子进程子进程未加入 cgroup使用了实时调度策略SCHED_FIFO/SCHED_RR实时任务不受 CFS 组调度管控需要开启CONFIG_RT_GROUP_SCHED。Q4cpu.cfs_quota_us 设置为 -1 代表什么解答默认值-1表示关闭硬配额限制任务组可以无限制使用 CPU 资源。当需要限流时必须设置为大于 0 的数值。Q5多个 CPU 核心场景下cfs_quota 如何计算多核配额解答cpu.cfs_quota_us支持超过cpu.cfs_period_us的值。例如 period100000usquota300000us代表该组最多可占用3 个完整 CPU 核心。Q6删除 cgroup 目录提示 “设备或资源忙”解答目录内还有未迁出的进程 / 线程。先清空tasks文件echo 0 tasks无效停止组内所有进程后再执行rmdir删除。六、实践建议与最佳实践6.1 资源划分最佳实践权重分配原则核心业务组cpu.shares设置更高如 2048~4096日志、备份、监控等非核心业务设置低权重512 及以下保证核心业务优先抢占 CPU。混部服务器组合使用线上生产组用cpu.shares做软优先级测试 / 离线任务搭配cpu.cfs_quota_us做硬限流双重保障。避免权重极端值不使用 1、100000 等极端数值推荐以 1024 为基准做倍数调整降低调度计算异常概率。6.2 容器场景优化技巧Docker/K8s 本质封装 cgroup生产环境不要直接修改宿主机原生 cgroup 目录优先使用容器平台原生参数--cpu-shares、--cpus。高并发容器集群尽量将同优先级业务划分到同一任务组减少内核任务组数量降低组调度计算开销。对延迟敏感的业务容器不要过度限制 CPU 配额避免调度抖动。6.3 调试与排错技巧CPU 争抢故障排查流程top/htop 定位高占用进程 → 查看进程所属 cgroup 组 → 检查cpu.shares与配额配置 → ftrace 跟踪组调度函数确认内核规则是否生效。调度性能调优大量任务组场景下可微调sysctl kernel.sched_min_granularity_ns平衡吞吐与延迟。内核问题定位出现组调度失效、权重不准时优先检查内核CONFIG_FAIR_GROUP_SCHED配置再排查进程是否跨组迁移异常。6.4 开发规范自研程序操作 cgroup 时务必保证权限控制cgroup 属于内核敏感接口普通用户无写入权限。程序退出时建议主动将进程迁出 cgroup避免残留进程导致目录无法删除。嵌入式 Linux 裁剪内核时容器 / 多租户场景必须保留CGROUPS与FAIR_GROUP_SCHED不可裁剪。七、总结与应用延伸本文完整讲解了 Linux CFS 组调度与 cgroup cpu 子系统的联动原理、内核源码、实操命令、代码开发与排错方案。核心要点回顾组调度改变了 CFS 的调度层级从 “单进程调度” 升级为 “组间调度 组内调度” 两层模型是资源隔离的核心cpu.shares对应内核task_group-shares实现基于权重的软 CPU 资源划分竞争场景下生效cpu.cfs_quota_us与cpu.cfs_period_us实现硬 CPU 配额严格限制任务组最大算力Docker、Kubernetes、LXC、KVM 等虚拟化 / 容器技术全部基于这套底层机制实现 CPU 隔离。从工程落地角度这套机制支撑了云计算、容器集群、多租户服务器、嵌入式多业务系统的稳定运行从技术研究角度组调度的分层设计、调度实体复用、cgroup 与内核调度器的接口交互是学习 Linux 内核架构、资源管理模块的典型案例相关源码与实验数据可直接用于技术论文、内核调研报告。建议读者结合本文的压力测试代码、ftrace 跟踪命令、C 语言 cgroup 示例在测试机上反复复现实验尝试修改内核task_group相关源码观察调度变化真正理解底层运行逻辑。在实际项目中合理利用组调度与 cgroup 资源隔离能力能够大幅提升服务器混部能力、业务稳定性与资源利用率。