--cpus和--memory是docker中唯一能实现cpu与内存硬上限的参数,前者基于cfs配额节流,后者超限触发oom kill;其他如--cpu-shares或--memory-reservation仅为软限制,不构成强制约束。

直接限制 CPU 和内存上限,必须用 --cpus 和 --memory,其他参数(比如 --cpu-shares 或 --memory-reservation)不构成硬性上限,超了也不会被杀。
用 --cpus 限制 CPU 核心数,不是“百分比”
很多人误以为 --cpus=0.5 是“限制 CPU 使用率到 50%”,其实它表示“最多使用 0.5 个逻辑 CPU 核心的计算时间”。在 4 核机器上,这个容器最多能跑满半个核,不会抢走其他容器的调度份额。
-
--cpus是硬限制,基于 CFS 的cpu.cfs_quota_us实现,超了就 throttled(被节流),进程不会卡死但会明显变慢 - 不要混用
--cpus和--cpu-shares:前者管绝对上限,后者只在争抢时起作用,单独设--cpu-shares=512对单容器完全无效 - 如果宿主机是单核,
--cpus=1.5会被自动截断为 1.0;小数只在多核下有意义 - 绑定特定核心要用
--cpuset-cpus(例如--cpuset-cpus="0,2"),和--cpus是正交配置,可同时用
用 --memory 设硬上限,超了直接 OOM Kill
--memory(或简写 -m)才是真正生效的内存硬限制。一旦容器内进程申请内存超过该值,Linux 内核会触发 OOM Killer,随机选一个进程干掉——通常是主进程,容器随即退出,状态变成 Exited (137)。
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 必须配
--memory-swap:如果不设,Docker 默认允许使用等量 swap(即总内存上限 = 2 ×--memory)。想彻底禁用 swap,得显式写--memory-swap=512m(和--memory值一致) -
--memory-reservation是软限制,仅当系统内存紧张时才尝试压缩,不能防 OOM - 单位要写对:
512m、2g、1024M都合法,但512mb或512Mib会报错 - 实际可用内存略小于设定值:cgroup 开销、内核页表等会占用几 MB,别卡着 512m 给一个刚好吃 512m 的 Java 应用
docker-compose.yml 里怎么写才真正生效
在 docker-compose.yml 中,资源限制必须放在 deploy.resources.limits 下,且仅在 docker stack deploy(Swarm 模式)或 docker compose up(v2.20+)中被识别。旧版 docker-compose up 会静默忽略这些字段。
- 正确写法:
version: '3.8' services: api: image: myapp deploy: resources: limits: cpus: '1.2' memory: 1G # 注意:memswap_limit 不在 limits 下,而是单独字段(v3.8+ 支持) reservations: memory: 512M -
cpus必须是字符串(带引号),否则 YAML 解析器可能转成浮点数导致失败 -
mem_limit这种老写法已废弃,只在docker run里支持,compose 中无效 - 如果用
docker-compose up但没生效,先检查 CLI 版本:docker compose version,低于 v2.20 的需升级或改用docker run
最易被忽略的一点:--cpus 和 --memory 是独立生效的,但它们共同依赖宿主机的 cgroups v1/v2 支持。如果你在 WSL2 或某些嵌入式 Linux 上运行,cgroup2 可能未启用,此时 --cpus 会降级为 --cpu-shares 行为——看起来限制了,其实没硬控住。验证方式是进容器执行 cat /sys/fs/cgroup/cpu.max(cgroup v2)或 cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us(v1),看输出是否匹配你设的值。










