容器CPU%长期100%但响应变慢，说明--cpus配额设在临界点：内核按配额切片调度，负载超限则线程排队等待、延迟飙升；验证需结合docker stats与/sys/fs/cgroup/cpu/cpu.stat中nr_throttled非零。
容器CPU%长期100%但响应变慢，说明配额设低了
这不是容器写得差，而是 --cpus 值卡在临界点上：内核按配额切片调度，一旦实际负载超过配额，线程就会排队等待，延迟飙升。常见于 Web API 在压测时 QPS 上升、P99 延迟陡增，或批处理任务耗时翻倍。
验证方法很简单：docker stats --no-stream 看 CPU% 是否持续 ≥95%，再进容器执行 cat /sys/fs/cgroup/cpu/cpu.stat，如果 nr_throttled 或 throttled_time 非零，就坐实了限频瓶颈。
- Web 类服务建议从
--cpus=1.0起步，逐步加到 1.5 或 2.0，目标是 CPU% 稳定在 70% 以下且延迟回落 - 批处理类（如导出、转码）别硬限
--cpus，改用--cpuset-cpus="0"绑定单核 +--cpu-shares=2048提高调度权重，吞吐更稳 - Java 容器必须加 JVM 参数：
-XX:ActiveProcessorCount=1，否则 JVM 会按宿主机核数启 GC 线程，引发误判和抖动
Windows/macOS 上 Docker Desktop 本身吃光 CPU 怎么办
Docker Desktop 不是直接跑容器，它靠 WSL2（macOS 是轻量 Linux VM）当“后厨”。这个后厨默认没上限——你有 16 核它就全拿，内存也一样。所以你看到系统风扇狂转、Chrome 卡顿，大概率不是某个容器的问题，而是 WSL2 自己占满了资源。
根本解法是管住这个“后厨”，而不是一个个调容器参数：
- macOS：点右上角 ? → Settings → Resources → Advanced，把
CPU调到物理核数的 50%~75%，Memory控在总内存的 25%~50% - Windows：在
C:\Users\你的用户名\下建.wslconfig（注意不是.wslconfig.txt），内容类似：
[wsl2] memory=8GB processors=4 swap=2GB
保存后运行 wsl --shutdown，再重启 Docker Desktop 才生效。
限制 CPU 后反而更卡？小心这些隐形坑
硬设 --cpus=0.5 看似安全，但对某些应用是毒药。比如 Node.js 的 event loop 或 Python 的 GIL 模型，它们依赖单核高频响应，切碎时间片反而让 I/O 等待拉长；又比如 Redis 这类单线程服务，配额太小会导致命令排队、连接超时。
更隐蔽的是 cgroups v2 的行为差异：Docker Desktop 新版本默认启用 cgroups v2，而部分老镜像或监控脚本仍按 v1 解析指标，可能误报“CPU 不足”。
- 别一上来就砍配额，先用
docker stats看真实负载，再决定是调高、绑定还是改权重 - 禁用
--memory-swap（即设--memory-swap=0）会剥夺内核最后缓冲空间，OOM 更频繁，建议设为--memory=4g --memory-swap=4.5g - Redis/Elasticsearch 这类内存敏感服务，优先用
--memory-reservation=3.5g软限，比硬限更抗流量突刺
怎么确认调对了？看这三个运行时信号
启动参数只是起点，真正有没有调好，得看容器跑起来之后的反馈。三个最便宜、最直接的验证方式：
- 每分钟跑一次
docker stats --no-stream，盯住 CPU% 波动幅度。如果连续三次峰值都 >90%，或 MEM USAGE / LIMIT 比值长期 >80%，就得调 - 进容器执行
cat /sys/fs/cgroup/cpu/cpu.stat，只要nr_throttled > 0，说明 CPU 配额已成瓶颈，必须加 - 对关键服务做轻量压测：用
hey -z 30s -q 50 http://localhost:8080/health，对比不同--cpus下的 P99 延迟和错误率
cgroups 的限制不是开关，是水龙头——拧太紧，水流不出；拧太松，漫出来。真正难的不是知道该拧，而是每次拧多少、往哪边拧，才刚好让应用呼吸顺畅又不泛滥。
