docker仅cpu可安全超配，内存仅支持软预留+硬上限，io和网络基本不可超卖；cpu靠cfs调度实现时间复用，内存超限触发oom，io/网络为硬限制。
Docker 本身不支持传统意义上的“资源超卖”（如虚拟机那样通过时间片复用+内存压缩实现远高于物理总量的分配），但它在 CPU 和内存层面存在可接受的、受控的超配空间，关键在于理解底层 cgroups 的行为逻辑和调度机制。
真正能安全“超卖”的只有 CPU；内存不能超卖，只能软性预留；IO 和网络则基本不可超卖。
CPU 资源可以合理超配：靠权重与空闲共享
CPU 是典型的“时间复用型”资源，内核 CFS 调度器天然支持多容器共享物理核心。只要不长期满载，多个容器的 --cpus 之和完全可以超过宿主机总逻辑核数。
- 例如：4 核机器上运行 8 个
--cpus=0.5的容器 → 总声明 4.0 核，实际无冲突 - 再如：启动 10 个
--cpu-shares=512容器（总权重 5120），而默认是 1024，只要它们不同时跑满，就都能获得响应
✅ 生效前提：
- 所有容器大部分时间处于 I/O 等待或空闲状态（典型 Web/HTTP 服务）
- 避免长期 CPU 密集型任务（如编译、转码）集中爆发
⚠️ 注意：--cpus=1.2 是硬限（每 100ms 最多用 120ms），超配后若全部触发上限，会排队等待——此时表现为延迟上升，而非崩溃。
内存不是超卖，而是“软预留 + 硬上限”配合
内存无法真正超卖（物理页不可复用），但可通过 --memory-reservation 实现类似效果：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
-
--memory=2g：硬上限，超了直接 OOM Kill -
--memory-reservation=1.2g：软目标，当系统内存紧张时，内核会优先回收低于此值的容器内存，但不阻止其临时突破到 2G
这样你可以在 8G 机器上部署多个 --memory=2g --memory-reservation=1g 的容器（比如 6 个），只要它们平均占用不到 1.3G，整体就能稳定运行。
✅ 关键操作：
- 必须设
--memory-swap=2g（禁用 swap）或--memory-swap=2g（等于 memory）→ 防止用 swap 掩盖真实压力 - 不要依赖
--oom-kill-disable=true，它会让进程被逐个 kill，更难诊断
IO 和网络基本不支持超卖
-
--blkio-weight只在争抢同一设备时调节比例，不提供总量超配能力 -
--device-read-bps是硬限，超出直接 throttled，无法绕过 - Docker 原生不支持网络带宽超卖；需靠 host 层 tc 规则做整形，且仍受限于物理网卡吞吐
所以 IO/网络应按峰值需求保守分配，避免“声明超配、实际拥塞”。
验证是否真能扛住超配
别只信 docker stats 或 top，要看真实 cgroup 状态：
# 查 CPU 实际配额（cgroup v2）
pid=$(docker inspect -f '{{.State.Pid}}' myapp)
cat /proc/$pid/cgroup | grep cpu
cat /sys/fs/cgroup/cpu$(cat /proc/$pid/cgroup | grep cpu | cut -d: -f3)/cpu.max
# 查内存当前使用与上限
cat /sys/fs/cgroup/memory$(cat /proc/$pid/cgroup | grep memory | cut -d: -f3)/memory.current
cat /sys/fs/cgroup/memory$(...)/memory.max
只有这些文件里的值匹配你的设置，才算真正生效。
