精准 CPU 分配需结合 --cpu-shares（软权重）与 --cpus 或 --cpu-quota/--cpu-period（硬配额）：前者决定争抢时的比例，后者限定绝对上限；同时必须配合内存限制，避免 OOM 或换页干扰调度。
在容器化环境中实现精准的 CPU 份额分配，关键不是“固定占多少核”，而是让多个容器在 CPU 竞争时按需、按权重公平分时。它和内存限制逻辑不同：内存是硬上限（超了被 OOM 杀掉），CPU 份额却是软调度策略（空闲时全用，争抢时才体现比例）。真正精准，得结合份额机制与硬性配额协同使用。
CPU 份额（--cpu-shares）只管相对优先级
CPU 份额本质是 CFS 调度器里的一个权重值，默认 1024，最小 2，最大 262144。它不设上限，也不保底——仅当多个容器同时跑满 CPU 时，内核才按比例切时间片。
- 两个容器：A 设 --cpu-shares 2048，B 设 --cpu-shares 512 → A 在争抢中约获得 B 的 4 倍 CPU 时间（即 80% : 20%）
- 若只有 A 在跑，且系统空闲，A 可以用满所有 CPU 核，不受 2048 限制
- 份额值本身无绝对意义，只在同主机、同调度层级下与其他容器比较才生效
要“精准控制使用量”，必须搭配 --cpus 或 --cpu-quota/--cpu-period
仅靠 --cpu-shares 无法防止某个容器吃光 CPU。需要硬性限流才能锁定资源边界：
-
--cpus=1.5：最简方式，等价于设置
cpu.cfs_quota_us=150000+cpu.cfs_period_us=100000，即每 100ms 最多用 150ms CPU 时间 - --cpu-quota=50000 --cpu-period=100000：手动控制，明确限定为 50% 单核带宽（0.5 CPU）
- 二者可与 --cpu-shares 共存：比如先用 --cpus=2 限制总量，再用 --cpu-shares=2048 让它在同组容器中拿更高比例
内存限制必须同步配置，避免干扰 CPU 调度
内存不足会触发 OOM Killer 或频繁换页，导致进程卡顿、调度延迟升高，间接破坏 CPU 份额的实际效果：
- Java 容器务必设 --memory=2g --memory-swap=2g，禁用 swap 防止 GC 拖慢
- 对内存敏感服务（如 Redis、Elasticsearch），建议预留 20% 缓冲，避免因 RSS 接近 limit 被节流
- 不要只限 CPU 不限内存：一个疯狂 malloc 的容器可能把系统拖慢，让所有容器的 CPU 分配都失真
生产环境推荐组合策略
单一参数难覆盖真实负载波动。建议按角色分级设定：
- 核心 API 服务：--cpus=1.0 --cpu-shares=2048 --memory=1g → 保底线 + 高调度权
- 日志聚合/批处理：--cpus=0.5 --cpu-shares=512 --memory=512m → 限总量 + 低优先级
- 监控采集器（如 Prometheus node_exporter）：--cpus=0.1 --cpu-shares=256 → 极低干扰，避免反噬自身
