Docker中CPU权重通过--cpu-shares设置相对调度优先级（默认1024），仅在多容器争抢CPU时按比例分配时间片，空闲时不限制；需搭配--cpus或--cpu-quota等软限制使用，并通过docker inspect或cgroup文件验证生效。
在 Docker 中配置 CPU 权重，核心是用 --cpu-shares 控制多个容器争抢 CPU 时的相对调度优先级，而不是硬性切分或固定分配。它不设上限、不保底限，只在资源紧张时起作用——空闲时所有容器都能自由使用 CPU。
CPU 权重怎么设才合理
权重是一个相对值，默认为 1024。关键不是绝对数字，而是容器之间的比例关系：
- 两个容器分别设为
--cpu-shares=512和--cpu-shares=2048，它们在竞争时获得的 CPU 时间比约为 1:4 - 若三个容器设为 512、1024、1536，实际时间分配会按 1:2:3 的比例动态倾斜
- 单个容器运行时，哪怕设成 1，也能跑满全部 CPU；只有多个容器同时高负载，权重才生效
怎么验证权重是否生效
启动容器后，不能只看命令是否写对，要确认内核真正读取了配置：
- 查容器 ID：
docker ps -q --filter name=high-priority - 进对应 cgroup 查权重（cgroups v2）：
cat /sys/fs/cgroup/docker/*/cpu.weight - 或用 inspect 看原始字段：
docker inspect high-priority | grep CpuShares - 观察真实调度效果：
docker stats持续对比多个容器的 CPU% 分布，尤其在压测阶段
单独用权重不够稳，建议搭配软限制
纯靠 --cpu-shares 容易被突发负载带偏，尤其当某个容器短时打满 CPU，可能影响其他服务响应。更稳妥的做法是组合使用：
- 用
--cpus=1.5或--cpu-quota=150000 --cpu-period=100000给出可执行的上限边界 - 再用
--cpu-shares=2048在这个边界内做公平调度，保障关键服务不被挤占 - 避免混用旧参数：比如不要同时设
--cpu-shares（v1 兼容）和--cpu-weight（v2 原生），可能导致行为异常
典型配置示例
假设你有 API 服务（高优）、日志采集（中优）、定时任务（低优）三个容器共存：
docker run -d --name api --cpus=2 --cpu-shares=2048 nginxdocker run -d --name log-agent --cpus=0.5 --cpu-shares=1024 fluent-bitdocker run -d --name cron-job --cpus=0.25 --cpu-shares=512 alpine crond
这样既防止任意一个失控吃光资源，又确保压力来临时，API 仍能拿到最多调度机会。
