cgroup v2 是当前 Linux CPU 资源隔离的唯一推荐路径，cgroup v1 的 cpu 和 cpuacct 子系统已不建议新项目使用，且在较新内核（5.15+）中默认禁用；根本原因在于未启用 cgroup v2 统一层级或内核参数缺失 systemd.unified_cgroup_hierarchy=1，导致 cpu.weight、cpu.max 等配置被静默忽略。
直接说结论：
是当前 Linux CPU 资源隔离的唯一推荐路径，
的
和
子系统已不建议新项目使用，且在较新内核（5.15+）中默认禁用。
为什么
创建的
有时不生效？
根本原因是未启用
统一层级，或内核启动参数中缺失
。即使 systemd 版本 ≥ 243，若内核未启用 v2，
、
等配置会被静默忽略。
检查是否启用 v2：
—— 应只看到
，无
（v1）
验证当前 hierarchy：
—— 输出应含
且挂载点为
若未启用：编辑
，在
中追加
，再运行
和
的实际行为差异
是相对权重（1–10000），仅在多个 cgroup 同时争抢 CPU 时起作用；
是硬性配额（如
表示最多用 50% CPU 时间），无视其他 cgroup 是否空闲。
CentOS Linux 7.9.2009
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。
下载
和
在只有自己运行时效果完全一样
表示每 100ms 周期最多运行 10ms，超时即被 throttled（可通过
查看
）
设置
后，
不再参与调度决策——两者互斥使用场景
注意单位：第二字段是 period（默认 100000μs），第一字段是 quota；设为
表示不限制
用
快速测试 CPU 隔离是否生效
避免手动写
路径，用 systemd 接口更可靠，也自动处理生命周期。
限制某进程最多用 30% CPU：
等价于硬配额方式（更严格）：
验证是否生效：
或
常见陷阱：如果目标进程是多线程，且未绑定到特定 cgroup，线程可能逃逸到 root cgroup——务必用
包裹整个命令，而非仅启动器
真正容易被忽略的是：CPU 隔离效果高度依赖负载类型。对大量 syscalls 或锁竞争型程序，
可能导致显著延迟尖刺，而不仅仅是吞吐下降；监控时不能只看
，必须结合
中的
和
才算看清真相。
cgroup v2cgroup v1cpucpuacctsystemd.slicecgroup v2systemd.unified_cgroup_hierarchy=1cpu.weightcpu.maxcat /proc/filesystems | grep cgroupcgroup2cgroupmount | grep cgrouptype cgroup2/sys/fs/cgroup/etc/default/grubGRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy=1sudo update-grub && sudo rebootcpu.maxcpu.weightcpu.weightcpu.max50000 100000cpu.weight=100cpu.weight=1000cpu.max=10000 100000cat cpu.statnr_throttledcpu.maxcpu.weightmaxsystemd-run/sys/fs/cgroup/systemd-run --scope -p CPUWeight=10 --scope sleep 300systemd-run --scope -p CPUQuota=30% --scope sleep 300systemd-cgtop -Pcat /sys/fs/cgroup/$(systemd-run --scope --pipe true)/cpu.stat | grep throttled--scopecpu.maxcpu.usagecpu.statnr_throttledthrottled_time