最可靠、生产可用的方式是用 cgroups v2 的 cpu.max 文件；cgroups v1 的 cpu.cfs_quota_us + cpu.cfs_period_us 仍可工作，但权限混乱、路径分散、易被 systemd 覆盖，不建议新系统使用。
直接说结论：限制进程 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 内密集计算）基本无效——它控的是平均带宽，不是瞬时峰值。
