算力冗余分配是通过cgroup的cpu.shares（v1）或cpu.weight（v2）按权重动态分配cpu时间片，仅在争抢时生效，空闲时全量可用；配置示例为4096:2048:1024实现4:2:1比例，数值仅表相对大小。

Linux 中通过 cpu.shares（cgroup v1）或 cpu.weight（cgroup v2）实现多个容器间按比例权重的算力分配，本质是让内核调度器在 CPU 资源紧张时，依据相对权重公平地切分可用时间片。它不提供硬性上限，但能保障关键服务在争抢场景下获得预期比例的 CPU 时间——这正是“算力冗余分配”的核心：预留弹性空间，按需倾斜调度。

下面从原理到实操，分三部分讲清楚怎么做：

什么是算力冗余分配？

不是固定锁死每个容器的 CPU 核心数，而是：

• 当系统空闲时，所有容器可自由使用全部 CPU；
• 当 CPU 使用率接近 100%（即发生争抢）时，内核按 shares 比例动态分配时间片；
• 高权重容器获得更多 vruntime 倾斜机会，从而实际获得更高占比的 CPU 时间；
• 这种“按需放大、空闲释放”的机制，就是算力层面的冗余设计。

如何配置 shares 实现比例分配？

Docker 层面直接用 --cpu-shares，底层对应 cgroup 的 cpu.shares 文件（v1）或 cpu.weight（v2）。

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

以三个容器为例，目标分配比为 4 : 2 : 1（即 57% : 29% : 14%）：

• Container A（关键服务）：--cpu-shares=4096
• Container B（普通服务）：--cpu-shares=2048
• Container C（后台任务）：--cpu-shares=1024

✅ 注意：数值本身无单位，只看相对大小。4096:2048:1024 = 4:2:1，和设成 400:200:100 效果完全一致。
✅ 默认值是 1024，所以设为 2048 就是默认的 2 倍权重，设为 512 就是默认的 0.5 倍。

启动命令示例：

docker run -d --name api --cpu-shares=4096 nginx
docker run -d --name worker --cpu-shares=2048 python:slim sleep 3600
docker run -d --name cron --cpu-shares=1024 alpine sh -c "while :; do date; sleep 60; done"

验证是否生效：

• 查看 cgroup 设置：cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.shares</container-id>
• 或进容器执行：cat /sys/fs/cgroup/cpu/cpu.shares（v1）或 cat /sys/fs/cgroup/cpu.weight（v2）

关键细节与避坑提醒

• 仅在争抢时生效：若 CPU 利用率长期低于 70%，shares 几乎不起作用——这是设计使然，不是 bug。
• 同级兄弟组才比较：shares 只在同一父 cgroup 下的直系子组之间做比例计算。例如：
  • /myapp/api 和 /myapp/worker 共享 /myapp 的 CPU 时间，按各自 shares 分配；
  • 但 /myapp/api 和 /batch/cron 不直接竞争，除非它们共同父级是 /（根 cgroup）。
• cgroup v1 与 v2 权重范围不同：
  • v1：cpu.shares 范围是 2–262144，默认 1024；
  • v2：cpu.weight 范围是 1–10000，默认 100，且映射非线性（新版 runc 用对数公式转换）；
  • 混用时注意 Docker 版本兼容性，建议统一用 --cpu-shares，Docker 会自动适配底层。
• 不要单独依赖 shares 做强隔离：它无法防止单个容器打满 CPU。如需硬限制，请叠加 --cpus=1.5 或 --cpu-quota。

不复杂但容易忽略。