Docker容器资源限制：–memory与–cpus参数详解、实践配置

上一章我们聊了容器为什么比虚拟机轻量，但轻量不意味着可以无节制地吃资源。特别是在宏基因组分析这种“内存大户”场景下，一个容器如果没设限制，OOM（Out of Memory）能把整个宿主机的稳定性拖垮。我最早踩这个坑是在部署某套16S分析流程时，一个容器不小心吃掉了40GB内存，把旁边跑着的重要数据库给挤挂了——从那以后，每次跑容器我都先看一遍资源参数。

为什么需要限制资源？

说白了，Docker容器的共享内核特性既是优势也是隐患。宿主机上跑多个容器，如果没有资源隔离，一个容器的内存泄漏或CPU 100% 会直接影响其他进程。你想想看，宏基因组流程里经常同时启动几十个样本的比对任务，每个样本的Kraken2或Bracken可能会瞬间吃掉大量内存。不设上限就等于“裸奔”。

Docker通过Linux cgroup（Control Group）实现资源限制。限制参数直接传递给cgroup，内核负责执行。我们眼前的接口就是两个最常用的参数：--memory 和 --cpus。

–memory参数：内存限制详解

硬限制：–memory / -m

--memory 设置的是容器能使用的硬上限。如果容器尝试分配超过这个值的内存，内核会直接触发OOM Killer，把容器内的进程杀掉。注意，这里的“杀掉”可能会是整个容器退出，也可能会是某个进程被吃掉，具体取决于cgroup配置。

常用的单位：b、k、m、g。比如 -m 4g 就是4GB。

docker run -it --rm -m 4g ubuntu:22.04 bash

我在项目中遇到过内存泄漏的容器，-m 参数相当于一道防火墙。但要注意，这个限制不包含swap。默认情况下Docker会给容器分配和 --memory 等量的swap，导致实际可用内存可能翻倍。如果你希望严格限制物理内存 + swap的总和，需要额外指定 --memory-swap。

软限制：–memory-reservation

软限制是一种“尽力而为”的约束。当宿主机内存充足时，容器可以使用超过软限制的值（只要不超过硬限制）。当宿主机内存紧张时，内核会优先回收超过软限制的内存，并尝试将容器压回软限制以内。

docker run -it --rm -m 4g --memory-reservation 2g ubuntu:22.04 bash

上面这个例子：硬限制4GB，软限制2GB。平时容器可以跑到3.9GB，但如果宿主机内存压力大，容器会被主动收缩到2GB附近。这非常适合宏基因组流程中的批量任务：每个样本的分析可以吃多一点资源，但整体不压垮宿主机。

OOM Killer行为控制

你可以通过 --oom-kill-disable 关闭OOM Killer，但仅当设置了 --memory 硬限制时才能用。关闭后，容器申请超过限制的内存会被阻塞，直到有内存释放——这可能导致进程卡死。我个人建议不要轻易关掉OOM Killer，除非你有非常明确的理由。

–cpus参数：CPU限制详解

核心：–cpus

--cpus 控制容器能使用的CPU核心时间比例。比如 --cpus 2 表示容器最多使用2个完整的CPU核心（可以跨多个核心累加，但总量不超过2）。注意，这不是“绑定到哪个核心”，而是CPU时间片配额。

docker run -it --rm --cpus 2 ubuntu:22.04 bash

这里有个容易混淆的点：如果你的宿主机是16核，--cpus 2 并不意味着容器只能跑在固定的两个核上，而是每秒钟容器最多获得2个核心的CPU时间。忙时会动态调度到不同核心。

相对权重：–cpu-shares

--cpu-shares 设置的是CPU的相对权重，而不是绝对限额。默认值为1024。如果两个容器都跑在同一个宿主机上，A设置2048、B设置1024，那么当CPU竞争时，A获得的时间会是B的两倍。但如果CPU空闲，两者都可以跑满。

这在宏基因组场景中很有用：你可以给重要的分析流程（比如比对）分配更高的权重，而把次要的预处理任务设为低权重。

绑定核心：–cpuset-cpus

--cpuset-cpus 直接指定容器可以使用的CPU核心编号。比如 --cpuset-cpus 0-3 表示容器只能在核心0~3上运行。这可以减少CPU缓存切换，但也会降低调度灵活性。

docker run -it --rm --cpuset-cpus 0-3 ubuntu:22.04 bash

我一般只在性能调优的极端场景才用 --cpuset-cpus，比如要让某个高频交易程序的延迟稳定。对于宏基因组流程，使用 --cpus 或 --cpu-shares 就足够了。

实践配置与避坑

下面是我在宏基因组流程中常用的资源配置模板。假设我们要跑一个Bracken定量任务，通常需要8GB内存和4个CPU核心。

docker run --rm \
  -m 8g --memory-swap 8g \
  --cpus 4 \
  -v /data:/data \
  my-bracken-image \
  bracken -d /data/db -i /data/input.kraken2 -o /data/output.bracken

注意三点：

• –memory-swap 和 -m 保持一致：杜绝swap，降低IO抖动。
• –cpus 不要超过宿主机的核心数：超配会导致调度混乱，反而变慢。
• 先跑一次基准测试：我习惯用 time 和 docker stats 观察实际资源使用，再调整参数。

docker stats [容器名或ID]

我个人的做法是：在docker-compose.yml里定义服务级别资源，这样每次启动都是一致的。

version: '3'
services:
  bracken:
    image: my-bracken-image
    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 8G
        reservations:
          memory: 4G
    volumes:
      - /data:/data

嗯，这里要注意，deploy 下的resources需要在Docker Swarm或Compose v3里生效。如果只是单机用 docker-compose up，则需要同时设置 mem_limit 和 cpus 等顶层参数（v2语法）。推荐直接使用 --compatibility 模式。

上面这张图把整个限制的传递路径画清楚了。从cgroup根节点出发，容器启动时创建自己的memory和cpu子组，参数被写入对应的cgroup文件，内核按这个配额调度资源。你想想看，理解了这张图，docker run的参数就不再是“死记硬背”了。

docker inspect [容器ID] | grep -A 10 "Memory"