线上服务偶发响应变慢、P99 延迟突然升高，但宿主机 CPU 平均利用率看起来并未跑满，这类“性能抖动”往往比持续高负载更难定位。对于运行在 Docker 中的应用，问题不一定出在业务代码，也可能是 CPU 配额耗尽、容器之间争抢资源、线程调度不均或监控粒度过粗造成的。本文给出一套从现象到根因的排查思路，帮助快速区分“应用真的忙”与“容器被限制”两种情况。🔍
一、先理解三类 CPU 控制参数
Docker 默认不会自动为容器设置 CPU 上限，容器能够使用多少计算资源，取决于宿主机调度情况以及启动时配置的限制。常见参数包括 CPU 配额、CPU 权重和 CPU 亲和性，三者作用并不相同，具体定义可参考 Docker 资源约束官方文档。
- --cpus：设置容器可使用的 CPU 算力上限。例如设置为 0.5，表示容器最多获得约半个逻辑核心的计算时间，而不是固定绑定某个核心。
- --cpu-period 与 --cpu-quota：通过调度周期和周期内可运行时间形成硬性配额。配额用完后，容器中的可运行任务会被暂时限流，等待下一个周期。
- --cpu-shares：表示资源竞争时的相对权重，不是硬上限。宿主机空闲时，低权重容器仍可能使用更多 CPU；发生争抢时，权重差异才会明显。
- --cpuset-cpus：把容器限制在指定逻辑 CPU 上运行，可用于隔离关键服务，但错误绑定也可能让多个高负载容器挤在同一核心上。
二、识别 CPU 限流的典型表现
CPU 限额导致的抖动通常具有周期性：吞吐量没有明显增加，接口延迟却突然上升；容器 CPU 使用率长期贴近配置上限；增加请求并发后，延迟快速恶化；宿主机仍有空闲核心，但目标容器无法继续获得计算时间。此时只看整体 CPU 百分比很容易误判，因为容器可能已经耗尽自身配额。
第一步可执行 docker stats，观察目标容器的 CPU 使用率是否持续接近限制值。随后通过 docker inspect 容器名检查 NanoCpus、CpuQuota、CpuPeriod、CpuShares 和 CpusetCpus 等配置，确认实际生效参数是否与部署文件一致。若容器由 Compose、Swarm 或其他平台启动，还应检查上层编排配置，避免只修改本地参数却未重新创建容器。
重点检查 cgroup 限流计数
仅凭 CPU 百分比不能直接证明发生了限流。更可靠的方法是读取容器对应的 cgroup CPU 统计。cgroup v2 通常可以在 cpu.stat中看到 usage_usec、nr_periods、nr_throttled 和 throttled_usec；cgroup v1 则常见 nr_periods、nr_throttled 与 throttled_time。不同系统的挂载路径可能不同，应先通过 docker info、mount 或 /proc/self/cgroup 确认 cgroup 版本和位置。
如果 nr_throttled 持续增加，并且它相对于 nr_periods 的比例在故障窗口内明显升高，同时 throttled 时间与接口延迟尖峰基本重合，就应优先怀疑 CPU 配额不足或短时突发负载耗尽配额。
三、排查宿主机上的资源争抢
如果限流计数不明显，下一步应从宿主机观察 CPU 争抢。使用 top、pidstat、mpstat 或 sar 按秒采样，重点关注每个逻辑 CPU 的利用率、运行队列、上下文切换和 iowait。整机平均利用率不高，不代表所有核心都空闲：当容器被绑定到少数核心时，指定核心可能已经满载，其他核心却处于空闲状态。
还要检查同机容器是否在同一时段执行批处理、日志压缩、镜像扫描、定时任务或垃圾回收。多个容器没有硬性上限时，会在峰值期间共同争抢 CPU；即使配置了 shares，关键服务也不一定获得稳定的绝对算力。建议把业务延迟、容器 CPU、宿主机每核负载和 cgroup 限流指标放在同一时间轴上对比，而不是分别查看不同时间范围的图表。📈
四、不要把所有抖动都归因于 CPU
CPU 使用率升高有时只是结果。例如磁盘 I/O 延迟、网络重传、锁竞争、线程池排队、频繁垃圾回收和内存回收，都可能让业务延迟出现尖峰。排查时应同步检查 iowait、磁盘延迟、内存压力、缺页、网络错误以及应用运行时指标。若容器 CPU 不高但运行队列很长，还需确认进程是否受 cpuset、线程亲和性或底层虚拟机 vCPU 调度影响。
五、通过对照实验确认根因
- 保留故障时段的请求量、延迟、CPU 使用率和 cgroup 统计，建立基线。
- 在可控环境中临时提高目标容器的 CPU 上限，其他配置保持不变，观察限流计数和延迟是否同步下降。
- 将高负载邻居容器迁移到其他节点，或错开批处理任务，再比较相同流量下的表现。
- 如果使用 cpuset，尝试为关键容器分配独立核心，并检查 NUMA、超线程和中断负载是否影响结果。
- 逐步增加并发进行压测，记录吞吐量开始停滞、延迟开始陡升时的 CPU 配额消耗，避免只做一次峰值测试。
调整时不要一次修改多个参数，否则即便故障消失，也难以确认真正原因。生产环境应优先采用灰度方式，并设置回滚条件。单纯取消 CPU 限额虽然可能暂时缓解问题，却可能把风险转移给同机其他服务。
六、长期治理建议
资源配置应同时考虑平均负载和短时突发。延迟敏感服务可预留一定余量，避免限额刚好等于日常峰值；批处理任务则适合设置明确上限，并与在线业务错峰运行。监控系统除 CPU 使用率外，还应持续采集限流次数、限流时间、每核负载、运行队列和应用延迟，并对“限流增长且延迟恶化”的组合条件告警。🛠️
部署变更后还应验证限制是否真正落入 cgroup，避免配置文件语法正确但运行参数未生效。容量规划应基于真实压测和历史峰值，而不是照搬固定核数；当单机争抢频繁出现时，应考虑重新分配工作负载、拆分节点池或为关键服务建立更明确的隔离策略。
总结
排查 Docker CPU 性能抖动的核心，是把应用延迟、容器配额、cgroup 限流和宿主机争抢串成完整证据链。先确认 CPU 参数，再检查限流计数，随后分析每核负载与邻居容器，最后通过单变量对照实验验证。只有区分硬配额耗尽、相对权重竞争、核心绑定不均和非 CPU 瓶颈，才能避免盲目扩容，让优化结果真正稳定、可复现。✅
