Skip to main content

为什么必须限制资源

容器默认没有任何资源限制。一个容器可以申请全部内存,占满所有 CPU 核心。 内存泄漏的服务会吃光宿主机内存。死循环的进程会占满所有 CPU。结果是宿主机和其他容器一起变慢甚至崩溃。
生产环境的每一个容器都应该设置内存上限。这是成本最低、收益最大的稳定性措施。

内存限制

--memory-swap--memory 的关系:--memory-swap 减去 --memory 就是可用的 swap 大小。两者相等表示禁用 swap。

OOM Killer 行为

容器内存用超上限时,Linux 的 OOM Killer 会直接杀掉容器内的进程。容器退出码是 137。
OOM 杀的是容器内存占用最大的进程。它不会提前警告,进程直接消失。排查「容器无故重启」时先查 OOM。

CPU 限制

--cpu-shares 只在 CPU 争抢时生效。CPU 空闲时低权重容器照样可以用满。

验证限制生效

docker stats 输出里的 MEM USAGE / LIMIT 一列直接显示用量与上限的比例。

Compose 文件里的资源限制

deploy.resources 在 Swarm 模式下原生生效。普通 docker compose up 也会识别 limits。较旧的 Compose v2 写法是顶层 mem_limitcpus

与 Kubernetes 的概念对照

Docker 的资源限制概念在 Kubernetes 里几乎一一对应。 理解 Docker 资源限制后,Kubernetes 的 requests 和 limits 只是同一思想的调度器版本。

blkio 与 IO 限制

磁盘 IO 也可以用 --device-read-bps--device-write-bps 等参数限速。这类 blkio 参数在日志爆炸或备份任务场景下有用,日常用得少,知道存在即可。

延伸阅读