reservations 设置内存和 CPU 最小保障值,仅在资源紧张时起作用:空闲时容器可超用(不超 limits),紧张时优先保留该资源;它不锁定物理内存,只影响 cgroup 回收行为,需配合 limits 和禁用 swap 才完整生效。
直接在 docker-compose.yml 中用 deploy.resources.reservations 设置内存和 CPU 的最小保障值,就能实现资源预留。关键在于它不占用物理资源,只在系统紧张时起作用——既避免服务“饿死”,又不浪费空闲资源。
预留(reservations)不是硬分配,而是调度器的承诺:
limits)预留值不能拍脑袋定,要结合实际运行数据:
docker stats <container> 观察服务稳定运行时的 RSS 内存,取其 1.2–1.5 倍作为起点limits.cpus 的 40%–60%,例如硬限 1.0 核,预留 0.4–0.6 核memory: 1G,则 reservations.memory: 512M–768M
以下是一个典型配置示例(适用于 Compose v3.8+):
version: '3.8'
services:
api:
image: my-api:latest
deploy:
resources:
limits:
cpus: '1.0'
memory: 1G
reservations:
cpus: '0.4'
memory: 512M
注意:该配置仅在 Docker Swarm 模式下(即使用 docker stack deploy)完全生效;若用 docker-compose up 启动,deploy 段会被忽略。非 Swarm 场景需改用容器运行时参数(如 --memory-reservation)或宿主机 cgroups 手动控制。
单独设预留不够,必须组合使用才能稳住关键服务:
limits.memory,防止内存泄漏拖垮整机memory_swap 与 memory 相同(如都为 1G),彻底禁用 swap,避免 I/O 延迟引发超时oom_score_adj: -500,降低被 OOM Killer 终止的概率