容器资源限制防止进程抢占内存宕机故障方案

容器里的进程如果不受限制，一个内存泄漏或突发流量就可能占满宿主机全部内存，触发 OOM Killer 甚至直接宕机。
本文给出容器资源限制防止进程抢占内存宕机故障方案：通过 Docker 的 --memory、--memory-swap 和 --oom-kill-disable 参数为容器设置内存上限，并教你验证配置是否生效。
适合刚接触容器、正在部署业务或排查过内存告警的用户直接照做。

先把环境准备到位

开始之前，确认以下条件：

• 已安装 Docker，版本建议 19.03 以上，旧版本参数可能不完整。
• 有宿主机 root 或 sudo 权限。
• 已知要限制的容器名称或镜像名称。

检查 Docker 是否可用：

docker version

如果输出 Client 和 Server 两段信息，说明 Docker 正常。

用 Docker 参数给容器加上内存护栏

核心是 docker run 里的三个参数：

• --memory：容器可用内存上限，比如 512m、1g。
• --memory-swap：内存加交换分区的总上限。只设置 --memory 时，默认 swap 和 memory 一样大，建议一起设置。
• --oom-kill-disable：内存耗尽时不立即杀掉容器内进程，而是让进程阻塞等待。不能单独使用，必须和 --memory 一起用，否则可能拖垮宿主机。

示例：限制容器的内存为 512M，swap 总量为 1G，并禁止直接 OOM Kill：

docker run -d --name myapp \
  --memory=512m \
  --memory-swap=1g \
  --oom-kill-disable=true \
  nginx:latest

如果容器已经创建，需要更新限制，可以用 docker update：

docker update --memory=768m --memory-swap=1.5g myapp

修改后重启容器使其生效：

docker restart myapp

确认限制是否真正生效

运行容器后，用 docker inspect 查看配置：

docker inspect myapp --format='{{.HostConfig.Memory}} {{.HostConfig.MemorySwap}}'

输出里的数字单位是字节。536870912 表示 512M，1073741824 表示 1G。

更直接的办法是进入容器内压测内存：

docker exec -it myapp stress --vm 1 --vm-bytes 600M --vm-hang 30

如果容器没有安装 stress，可以先安装：

docker exec -it myapp apt update && docker exec -it myapp apt install -y stress

压测时观察宿主机 free -h，如果 swap 增加但宿主机内存未被完全占满，说明限制生效。
压测结束后记得退出并删除测试容器，避免残留进程。

避坑：这些细节容易导致方案失效

实践中经常遇到限制不生效或主机仍被拖垮的情况，注意以下几点：

• 只设置 memory 不设置 memory-swap：默认情况下容器可使用的 swap 与 memory 相同，--memory=412m 时实际压力峰值可能接近 1G。建议两个参数一起设置。
• 不要在生产环境随意关闭 OOM Kill：--oom-kill-disable=true 会让容器进入不可恢复的阻塞状态，进程不死但业务也不响应。更稳妥的做法是设置合理的 memory，并搭配 --restart=on-failure 让容器自动重启。
• 宿主机内存不足优先清理无用容器：即使每个容器都设置了限制，宿主机上所有容器内存总和仍可能超过物理内存。预留 20%-30% 内存给操作系统和缓存。
• 注意 Docker Compose 配置：如果使用 docker-compose.yml，需要这样写：

services:
  myapp:
    image: nginx:latest
    mem_limit: 512m
    memswap_limit: 1g

然后执行 docker-compose up -d 让新限制生效。

验证效果并纳入日常监控

限制配置完成后，要形成可复用的验证流程：

1. 查看容器当前内存占用：docker stats，确认没超过设置的上限。
2. 观察宿主机内存：free -h，确认没有异常增长。
3. 检查系统日志里是否有 OOM 事件：dmesg | grep -i oom，有输出说明此前发生过内存耗尽，需要调整限制值。
4. 将限制参数写入部署脚本，避免下次重建容器时丢失。

建议在监控面板中加入容器内存使用率指标，当接近上限时提前扩容或排查进程。
如果你遇到容器间歇性被杀、宿主机内存突然飙高，按本文步骤检查限制是否生效，再结合实际负载微调参数。
遇到异常时优先回看避坑部分，通常能快速定位问题。