--cpu-shares调优核心是按业务优先级设定相对权重，确保cpu争抢时关键容器获得预期调度比例；它仅在资源紧张时生效，不设绝对上限，且需同级cgroup下才按比例分配。
调优 --cpu-shares 的核心不是“设得越高越好”，而是让权重比真实反映业务优先级，并确保在 cpu 争抢发生时，关键容器能稳定获得预期比例的调度机会。它不改变单个容器的绝对性能上限，只影响资源紧张时的时间片分配逻辑。
明确权重目标与业务等级映射
先梳理服务重要性层级，再换算为可比较的相对数值：
- 关键在线服务（如 API 网关、订单写入）→ 权重设为 4096（默认 1024 的 4 倍）
- 普通后台服务（如用户同步、缓存刷新）→ 设为 2048（2 倍）
- 低优先级任务（如日志归档、离线报表）→ 设为 512 或 256（0.5–0.25 倍）
数值本身无单位，只看比例关系。4096:2048:512 = 8:4:1，比值清晰即可，不必拘泥于 1024 基准。
验证是否真正在争抢场景生效
空闲状态下所有容器都能跑满 CPU，--cpu-shares 不起作用——这是正常行为，不是配置失败。要验证，必须主动制造竞争：
- 用
stress-ng --cpu 4 --timeout 60s在宿主机上压满 CPU - 同时让多个目标容器运行计算型任务（如
sha256sum /dev/zero） - 用
docker stats或top -H观察各容器内进程的 CPU% 占比是否接近理论比例（如 4096:2048 → 约 67% : 33%）
若压测后比例偏差大，检查是否混用了 --cpus 或 --cpu-quota：它们会覆盖 shares 的弹性分配逻辑，导致权重失效。
注意同级分组约束与 cgroup 层级
--cpu-shares 只在**同一父 cgroup 下的直系子组之间生效**。例如：
- 三个容器都直接启动在根 cgroup 下（默认 Docker 行为），彼此按 shares 比例竞争
- 若把 A、B 放进
/myapp组，C 放进/batch组，则 A 和 B 之间按 shares 分配/myapp的配额，C 独占/batch配额——此时 A/B/C 总体比例不再由各自 shares 直接决定
生产环境建议统一管理：要么全用 Docker 默认启动方式，要么统一挂到同一个自定义父 cgroup 下，避免隐式分层干扰权重效果。
结合实际负载动态调整而非一劳永逸
业务流量有峰谷，固定 shares 可能造成高峰时低权容器饿死、低谷时高权容器闲置浪费。可配合自动化手段动态调优：
- 用
echo 3072 > /sys/fs/cgroup/cpu/docker/<id>/cpu.shares</id>在运行中修改（Docker v20.10+ 支持热更新） - 基于 Prometheus + CPU 使用率告警，在持续超 85% 时临时提升关键容器 shares 值
- Kubernetes 中可通过
cpuShares字段（需 RuntimeClass 或定制 CRI 支持）或 Operator 自动注入
调优本质是让调度权重随业务水位变化，而不是设一个数就放任不管。
