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

为什么容器必须限制内存？

未限制内存的容器就像没有刹车的汽车——一个内存泄漏或突发请求就能吞噬整个宿主机的内存，导致系统 OOM（Out Of Memory）并随机杀死进程（包括关键服务），最终网站崩溃、数据库断开。
真正的解决思路不是事后重启，而是提前用 cgroup 给每个容器划定硬性内存上限。

前提条件

• 一台安装了 Docker 的 Linux 服务器（CentOS 7+/Ubuntu 18.04+）。
• 有普通用户权限或 sudo 权限。
• 知道容器的名字或镜像名。

检查 Docker 是否运行：

sudo systemctl status docker

如果没安装，可参考官方文档安装。
本文所有命令在 Ubuntu 22.04 下测试通过。

第一步：启动容器时直接限制内存

最直接的方式是在 docker run 时加上 -m 或 --memory 参数。
例如启动一个 Nginx 容器，限制内存最大 256 MB：

docker run -d --name web-nginx -m 256m nginx:alpine

参数说明：

• -m 256m：硬限制，容器最多使用 256 MB 物理内存。
• 如果容器试图超过此限制，内核会触发 OOM-Kill 并杀死容器内的进程。

还可以同时设置 --memory-swap 控制 swap 使用。
通常建议让 swap 等于内存限制，避免大量换入换出拖慢性能：

docker run -d --name web-nginx -m 256m --memory-swap 256m nginx:alpine

第二步：通过 docker-compose 设置内存限制

如果使用 docker-compose，在服务配置中添加 deploy.resources.limits.memory：

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    deploy:
      resources:
        limits:
          memory: 256M

注意：deploy.resources 仅在 Swarm 模式下生效。
如果只需在单机 Compose 中限制，可以使用 mem_limit（旧版支持，最新版仍兼容）：

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    mem_limit: 256m

启动后可以用 docker stats 查看实时内存占用：

docker stats web

第三步：为已有容器添加内存限制（不重新创建）

Docker 允许在运行中更新容器的内存限制，无需停机。
使用 update 命令：

docker update --memory 512m my-running-container

也可以通过 --memory-swap 同时调整 swap。

注意： 如果容器原本没有限制，更新后会立即生效。
可以使用 docker inspect my-running-container | grep -i memory 确认新限制。

避坑指南

1. 硬限制 vs 软限制：-m 是硬限制，超过会 OOM 杀死进程。如果希望警告而非杀死，可用 --memory-reservation 设置软限制，但硬限制仍然建议设置，否则进程可能趁机突增。
2. 切记同时限制 swap：只限制物理内存而不限制 swap，容器会把内存压力转移到磁盘，性能急剧下降且仍可能耗尽 swap 空间。最佳实践：--memory-swap 等于 --memory 或更大（如果允许使用 swap）。
3. 监控 OOM 事件：查看 /var/log/kern.log 或使用 dmesg | grep -i oom 检查哪些进程被杀死。示例：

   sudo dmesg | grep -i "killed process"

如果看到容器进程被 kill，说明你的内存限制可能过小。

1. 不要依赖默认值：Docker 默认不限制内存，生产环境必须显式设置，哪怕只是较大的值。

效果验证：模拟内存压力

用 stress 工具在容器内测试限制是否生效：

# 启动一个限制内存的容器，并进入交互模式
docker run -it --rm -m 128m ubuntu:22.04 bash

# 在容器内安装 stress
apt update && apt install -y stress

# 尝试分配 200MB 内存
stress --vm 1 --vm-bytes 200M --timeout 10s

观察终端输出，容器内的 stress 进程会被 OOM-Kill，同时宿主机日志会出现类似信息：

[pid] stress invoked oom-killer...

此时宿主机的其他服务不受影响。
如果未设置限制，同一个 stress 命令可能导致宿主机 SWAP 飙升甚至死机。

高频问题 FAQ

Q：设置内存限制后为什么容器还是被 OOM 杀了？
A：可能是限制值过小，或者同时运行了多个容器，总内存超限。检查 dmesg 确认哪个进程被杀，并适当增大限制。

Q：Kubernetes 中如何限制 Pod 内存？
A：在 Pod 的 YAML 中设置 resources.limits.memory，写法与 Docker 类似。建议配合 requests.memory 使用。

Q：限制内存会影响容器性能吗？
A：只要限制值合理（大于容器正常工作所需），不会有明显影响。反而可以避免“吵闹邻居”效应，提升整体稳定性。

总结

给容器设置内存上限是运维中最基础也最重要的容错手段。
通过 docker run -m、docker-compose mem_limit 或 update 命令，就能有效预防单个进程耗尽内存导致所有服务宕机。
建议每次部署前先规划好每个容器的最大内存，并在监控面板上加上内存使用率告警。
这样即使进程出现异常，也能将故障范围控制在一个容器内，快速恢复。

如果你正在处理容器资源限制防止进程抢占内存宕机故障，建议先按本文步骤完整执行，再根据自己的环境微调限制值；
遇到异常时优先回看避坑和高频问题部分。