Docker容器资源限制需区分硬上限与软保障:CPU用--cpus设硬限、--cpu-shares调权重、--cpuset-cpus绑定核心;内存必须同时配置--memory(硬限)和--memory-reservation(软预留),禁用swap防IO毛刺;磁盘IO按业务选bps、iops或blkio-weight;Compose中非Swarm模式需在service同级设资源参数。
给 docker 容器设资源限制,不是加几个参数就完事——关键在分清“硬上限”和“软保障”,并匹配真实负载特征。不合理的配置反而会引发 oom 杀死、cpu 饥饿或调度失衡。
CPU 限制:别只盯 cpus,权重与绑定要协同用
单一使用 --cpus=1.5 能封顶,但无法解决多容器争抢时的响应抖动。生产中建议组合配置:
-
硬性上限:用
cpus(如"0.8")防止突发计算压垮宿主机 -
竞争优先级:配合
cpu_shares(如2048),让核心服务在 CPU 紧张时获得更高调度权重 -
亲和性优化:对延迟敏感服务(如实时音视频转码),加
--cpuset-cpus="1,3"绑定物理核心,减少上下文切换开销
内存限制:limits 和 reservations 必须成对出现
只设 memory: 512M 是危险操作——容器可能因瞬时峰值被 OOM Killer 直接终止。正确做法是:
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
-
硬上限(limits.memory):设为应用稳态峰值 + 20% 缓冲,例如 Java 应用堆设 1G,容器 memory 设
1280M -
软预留(reservations.memory):设为应用基础常驻内存,如
512M,确保调度器优先分配,避免频繁换页 - 禁用 swap:
--memory-swap=512M(等于 memory 值)可杜绝因交换导致的 IO 毛刺
磁盘 IO 与实际业务节奏对齐
Docker 默认不限 IO,但数据库或日志密集型服务极易拖慢整台宿主机。推荐按场景分级控制:
-
限带宽:对备份/同步类容器,用
--device-read-bps /dev/sda:10mb防止吞光磁盘吞吐 -
限 IOPS:对 MySQL、PostgreSQL,用
--device-read-iops /dev/sda:200更贴合随机读写特性 -
IO 权重:多个容器共用磁盘时,用
--blkio-weight 300(范围 10–1000)调节相对优先级
Compose 部署时绕过常见陷阱
很多人以为 deploy.resources 在 docker-compose up 下自动生效——其实它只在 Swarm 模式下触发 reservations。独立运行请改用顶层配置:
- 非 Swarm 场景:直接写
mem_limit: 1g和cpus: 0.5在 service 同级(v2/v3 兼容) - Swarm 场景:必须启用
docker swarm init,reservations才参与调度决策 - Proxmox 用户可直接调用 Helper-Scripts,如
var_ram=3072 bash mariadb.sh,自动注入 cgroups 规则

















