Linux限制进程CPU占用详解

本文深入解析了在 Linux 系统中精准、可靠地限制进程 CPU 占用的最优实践，明确指出 cgroups v2 的 `cpu.max` 是当前生产环境唯一推荐的硬性限频方案——它以简洁的“配额/周期”微秒格式（如 `"30000 100000"` 表示 30% 单核）实现可预测的绝对带宽控制，相比已过时且易被 systemd 干扰的 cgroups v1，以及仅在争抢时生效、无法防止单进程吃满 CPU 的软限制机制（如 `cpu.shares`/`cpu.weight`），它更安全、统一、稳定；同时文章直击实操痛点：从挂载验证、控制器启用、权限规避到进程加入、瞬时响应延迟等关键细节一一拆解，帮你避开九成线上踩坑场景。

直接说结论：限制进程 CPU 占用，最可靠、生产可用的方式是用 cgroups v2 的 cpu.max 文件；cgroups v1 的 cpu.cfs_quota_us + cpu.cfs_period_us 仍可工作，但权限混乱、路径分散、易被 systemd 覆盖，不建议新系统使用。

怎么用 cgroups v2 限制单个进程的 CPU 使用率（推荐）

cgroups v2 统一挂载在 /sys/fs/cgroup，所有控制器（如 cpu、memory）共用同一层级，权限和路径清晰。限制 CPU 的核心是写入 cpu.max，格式为 "max period"，单位是微秒。

• 想限制为 1 个逻辑 CPU 核心的 30%：执行 echo "30000 100000" > /sys/fs/cgroup/myapp/cpu.max
• 想限制为最多使用 0.5 个核（即 50% × 1 核）：写 "50000 100000"；想限制为 2 个核中的 1 个（即 50% × 2 核），也写 "50000 100000"——cpu.max 是绝对带宽，不随可用核数缩放
• 把进程加入该 cgroup：先确认进程 PID（如 1234），再执行 echo 1234 > /sys/fs/cgroup/myapp/cgroup.procs（注意是 cgroup.procs，不是 tasks）
• 必须确保该目录已启用 cpu 控制器：创建后需先写入 echo "+cpu" > /sys/fs/cgroup/cgroup.subtree_control（在父目录或本目录均可，推荐在 /sys/fs/cgroup 根下一次性启用）

为什么 cpu.shares 不适合做硬性限制

cpu.shares 是相对权重，只在 CPU 竞争时起作用，空闲时不生效。它无法阻止进程跑满 100% CPU —— 只要没其他进程争抢，哪怕 cpu.shares=1 也能吃光全部算力。

• 典型误用场景：给 MySQL 设 cpu.shares=512，结果高峰期它仍占满 CPU，因为此时没别的进程在争
• 它适合配合多个服务做“比例分配”，比如 Web 服务设 1024、后台任务设 512，两者同时高负载时，CPU 时间比约为 2:1
• v2 中对应的是 cpu.weight（范围 1–10000，默认 100），行为一致，仍是软限制

权限和挂载常见坑

cgroups v2 默认由 systemd 管理，普通用户通常无权在 /sys/fs/cgroup 下创建子目录；即使 root 创建了目录，若未显式启用控制器，写 cpu.max 会报错 Invalid argument。

• 检查是否为 v2：运行 mount | grep cgroup，输出含 cgroup2 且无 cgroup（v1）条目，才是纯 v2 环境
• 启用 cpu 控制器：在创建子目录前，先执行 echo "+cpu" > /sys/fs/cgroup/cgroup.subtree_control；否则子目录默认不继承控制器
• 权限问题：非 root 用户无法直接写 cgroup.procs；若需普通用户管理，得用 sudo tee 或配置 polkit 规则，不建议绕过权限模型
• systemd 会自动清理空的 cgroup 目录：如果进程退出后没手动移除目录，systemd 可能在几分钟后删掉整个 myapp 目录

别碰 cgroups v1 的 cpu.cfs_quota_us（除非你不得不）

v1 路径分散（如 /sys/fs/cgroup/cpu,cpuacct/）、控制器绑定松散、与 systemd 冲突严重。你在终端手动写的值，可能被 systemd 单元文件里的 CPUQuota=50% 覆盖，且两者语义不完全等价。

• v1 中写 cpu.cfs_quota_us 前必须确保 cpu.cfs_period_us 已设（默认 100000），否则内核拒绝写入
• 进程加入靠 tasks 文件，但 v1 的 tasks 是线程粒度，容易误把子线程漏掉；v2 的 cgroup.procs 是进程粒度，更稳
• Ubuntu 22.04+、RHEL 9+、Arch 默认启用 v2，强行用 v1 需额外挂载，徒增维护成本

真正容易被忽略的点是：cgroups 限制只对**后续的 CPU 调度周期**生效，不会中断当前正在执行的指令；如果你限制后看到 CPU 占用没立刻下降，不是配置失败，而是调度器还没轮到重调度。另外，cpu.max 对短时突发（比如 1ms 内密集计算）基本无效——它控的是平均带宽，不是瞬时峰值。

到这里，我们也就讲完了《Linux限制进程CPU占用详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于Linux的知识点！