cfs_quota_us 配合 cfs_period_us 可实现硬性 cpu 时间上限，比值即 cpu 使用率上限，如 40000/100000 为 40% 整机算力，不依赖优先级，适用于突发负载；需注意多核下非单核百分比、io 等待不计入配额、v1/v2 不可混用。
直接用 cfs_quota_us 配合 cfs_period_us 就能实现硬性 CPU 时间上限，不依赖进程优先级或调度策略，对突发型高负载应用特别有效。
理解配额机制的核心逻辑
Linux CFS 调度器把 CPU 时间划分为固定周期（cfs_period_us），每个周期内允许某组进程最多运行指定微秒数（cfs_quota_us）。两者比值就是实际 CPU 使用率上限。例如：
-
cfs_period_us = 100000（默认 100ms） -
cfs_quota_us = 30000→ 每 100ms 最多用 30ms CPU 时间 → 硬限 30% -
cfs_quota_us = 200000→ 每 100ms 最多用 200ms → 相当于绑定 2 个逻辑核（不限制在哪颗核上跑） -
cfs_quota_us = -1表示不限制，交由系统自由调度
手动创建并配置 CPU 控制组（cgroup v1）
适用于大多数生产环境（尤其 CentOS 7 / Ubuntu 18.04+ 默认仍为 v1）：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 确认 cpu 子系统已挂载：
mount | grep cpu，若无输出则执行：sudo mount -t cgroup -o cpu cpu /sys/fs/cgroup/cpu - 新建控制组：
sudo mkdir /sys/fs/cgroup/cpu/app-limited - 设周期为 100ms、配额为 40ms（即 40%）：
echo 100000 | sudo tee /sys/fs/cgroup/cpu/app-limited/cpu.cfs_period_us；echo 40000 | sudo tee /sys/fs/cgroup/cpu/app-limited/cpu.cfs_quota_us - 将目标进程 PID 加入该组：
echo $PID | sudo tee /sys/fs/cgroup/cpu/app-limited/tasks - 验证是否生效：用
pidstat -u -p $PID 1观察 CPU 使用率是否稳定在 40% 左右
使用 cgroup v2 的统一接口（推荐新系统）
v2 更简洁，且避免 v1 中 cpu + cpuacct 分离带来的混淆：
- 检查是否启用 v2：
cat /proc/filesystems | grep cgroup2，或运行stat /sys/fs/cgroup/ | grep Type看是否为cgroup2 - 在根 cgroup 下建子组：
sudo mkdir /sys/fs/cgroup/app-limited - 设置硬限（等价于 v1 的 quota+period）：
echo "40000 100000" | sudo tee /sys/fs/cgroup/app-limited/cpu.max - 加入进程：
echo $PID | sudo tee /sys/fs/cgroup/app-limited/cgroup.procs - v2 中无需单独挂载 cpu 子系统，所有控制器统一管理
关键注意事项与避坑点
配额看似简单，但多核环境下容易误判效果：
- 配额是按总 CPU 时间计算的，不是单核百分比。40000/100000 在 8 核机器上仍是 40% 整机算力，不是“每核 40%”
- 若需绑定特定 CPU 核心，必须额外配合
cpuset子系统，仅靠 cfs_quota_us 无法实现绑核 - 配额限制的是“可运行时间”，进程休眠、IO 等待不计入 quota，因此对 I/O 密集型应用限流效果可能不如预期
- 不要混用 v1 和 v2 接口；同一进程不能同时属于两个不同层级的 cpu cgroup
- 容器场景中（如 Docker），优先通过
--cpus=0.4或--cpu-quota=40000 --cpu-period=100000交由运行时自动配置，避免手动干预 cgroupfs
