Docker容器内存超限与限制配置：别让Docker把外贸服务器挤爆了

很多做外贸独立站的朋友都有过这种经历：大促期间流量刚上来，或者半夜欧美客户下单的高峰期，网站突然打不开，报错502 Bad Gateway。连上SSH一看，MySQL挂了，或者PHP-FPM直接躺平。一查系统日志，全是Linux内核的Out of Memory（OOM）杀手在砍进程。说实话，这几年我看过太多站长为了省事，直接拿海外2核4G甚至2核2G的小鸡裸跑几个Docker容器，既不做资源规划也不做约束，最后容器无限吃内存导致整机瘫痪。做好Docker容器内存超限与限制配置，是保证外贸站、独立站业务能7x24小时稳定活着的最基本功，而不是等服务器崩了再去重启。

一、 为什么你的容器总在半夜“猝死”？

很多新手以为，我在宿主机上起一个容器，它占多少内存全凭自己心情，宿主机有空余它就能用。

逻辑没错，但现实很残酷。

默认情况下，Docker容器对宿主机的内存使用是没有任何限制的。这意味着如果你的WordPress容器因为被恶意扫描、或者爬虫疯狂抓取导致并发拉高，PHP进程能把宿主机的物理内存一点不剩地吃光。

当宿主机物理内存彻底耗尽时，Linux内核的守护机制——OOM Killer（Out of Memory Killer） 就会被触发。为了保住操作系统自己不崩溃，内核会根据内部算法算出一个得分最高（耗内存最多、优先级最低）的进程，直接发信号将其干掉。

在外贸服务器上，这个倒霉蛋90%的概率是你的MySQL容器。数据库一挂，整套站全停，询盘全泡汤。

二、 核心参数：限制内存的正确姿势

控制Docker内存，主要依靠两个维度：硬限制（Hard limit） 和 软限制（Soft limit）。别去死记那些复杂的理论，记住下面这几个参数就足够你跑生产了：

1. -m 或 --memory：硬限制。容器最多能吃多少物理内存。比如设为 1g，容器用到1GB时，就不能再要物理RAM了。
2. --memory-swap：内存 + Swap的总量限制。注意，这里是个巨大的天坑！ 很多人以为这是额外分给容器的Swap大小，其实它是“物理内存+Swap”的合计数。
   • 如果你设了 -m 1g --memory-swap 1.5g，说明容器能用 1G 物理内存和 500M Swap。
   • 如果设成和 -m 一样大，比如 -m 1g --memory-swap 1g，代表彻底禁用这个容器使用Swap。
3. --memory-reservation：软限制。平时不会卡死你，但当宿主机内存开始吃紧时，Docker会强制把容器压回这个数值以内。
4. --oom-kill-disable：禁止内核OOM杀掉这个容器。老手忠告：除非你设了严格的 -m 硬限制，否则千万别开这个！ 不然容器真失控的时候，它死不了，死的就是你的Linux操作系统本身。

三、 生产环境实操：怎么配最稳？

针对目前大部分做独立站最常用的场景，我把配置拆成命令行和Docker Compose两种。

1. 单容器直接启动（命令行）

比如跑一个Redis缓存服务，外贸站Redis崩了影响相对小一点，但绝不能让它占满机器：

docker run -d \
  --name site-redis \
  --memory 512m \
  --memory-swap 1g \
  --restart always \
  redis:alpine

这里给它512MB物理内存，外加512MB Swap空间缓冲，足够应付绝大部分小站的缓存击穿。

2. Docker Compose（站长主流部署方式）

在编写 docker-compose.yml 时，很多人的配置过时了。Docker Compose目前推荐使用规范的 deploy.resources 语法，虽然以前是给Swarm用的，但现在标准的Docker Compose v2也能原生识别它。

以最典型的外贸站组合（Nginx + WordPress + MySQL）为例，给出一套能在2核4G海外机器上稳跑的配置模版：

version: '3.8'

services:
  db:
    image: mysql:8.0
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: YourStrongPassword
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 1500M      # 硬限制：绝不允许超过1.5G
        reservations:
          memory: 512M       # 软限制：平时至少预留512M

  wordpress:
    image: wordpress:php8.2-fpm
    restart: always
    depends_on:
      - db
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 1200M      # 防止PHP-FPM进程突发泄露打满整机
        reservations:
          memory: 256M

  nginx:
    image: nginx:alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    deploy:
      resources:
        limits:
          memory: 256M       # Nginx占用极低，给256M绰绰有余

老鸟实测建议：如果你还在用 Compose 文件的旧版本格式（如在Service同级直接写 mem_limit: 1500m），虽然老版本Docker还能认，但赶紧切到上面这种规范写法，免得后续升级Docker Engine直接报错报废。

四、 线上排查：怎么确认容器是因为超限死的？

很多站长看网站挂了，第一反应是上去敲一个 docker restart。连原因都没排查，过两天还是得崩。

如果怀疑容器被OOM杀了，用这三个命令去抓现行：

1. 查看容器退出状态码

docker inspect <你的容器名或ID> --format='{{json .State}}'

看输出里的两项关键数据：

• "OOMKilled": true —— 只要这个值是 true，百分之百是内存超限被内核掐死的，没有任何借口。
• "ExitCode": 137 —— 退出码137代表进程收到了 SIGKILL 信号（128 + 9），通常就是OOM Killer下的狠手。

2. 查宿主机内核日志

执行：

dmesg -T | grep -i oom

或者看系统日志：

grep -i 'killed process' /var/log/messages
# Ubuntu/Debian下看这个：
journalctl -xb | grep -i oom

你能清晰看到内核在什么时间、抓到了哪个进程吃内存最多、把哪个PID给干掉了。

3. 实时盯紧资源开销

平时做压力测试或者黑五促销前，开个终端挂着：

docker stats

这个命令相当于Docker专用的 top。关注其中的 MEM USAGE / LIMIT 和 MEM %。一旦某个容器长时间飙到90%以上，你就得考虑两件事了：要么你的PHP代码或插件有严重的内存泄露，要么你的VPS该加钱升配了。

五、 避坑总结

1. 别拿Swap当真正的救命稻草：限制了容器内存之后，尽量只留少量的Swap作为突发缓冲。现在很多廉价云服务器的磁盘IO性能极差，一旦容器开始疯狂读写Swap分区，整台机器的I/O会瞬间拉满，甚至会导致SSH都连不上，网站同样得卡死。
2. 永远给宿主机留口饭吃：所有容器加起来的最大硬限制（limits.memory），绝对不能大于宿主机物理内存的80%。你得留下至少20%的余量给Linux系统自身的内核空间、SSH登录守护进程以及系统缓存。
3. 少用第三方臃肿镜像：很多非官方定制镜像里塞了一堆垃圾脚本，起步就吞几百兆内存。能用Alpine内核的尽量用Alpine，能用官方精简版的就别用第三方整合包。

把这些限制落到你的compose文件里，哪怕某天网站被CC攻击或者PHP脚本报错失控，撑死了也就是对应的Web容器自己重启一下，不至于拉着整台服务器同归于尽。