MongoDB无视Docker内存限制问题及Docker内存限制实现机制咨询

哈哈，这个MongoDB吃内存跑swap的坑我踩过！太影响性能了，先给你把Docker内存限制的原理讲透，再把Unix系统里的资源限制选项梳理清楚，帮你建立整体认知。

Docker底层完全依赖Linux内核的**cgroups（控制组）**机制来实现容器的资源隔离与限制，内存限制的核心逻辑如下：

• cgroups memory子系统：当你用docker run -m 2g或者在docker-compose里配置mem_limit: 2g时，Docker会为这个容器创建专属的cgroup，并设置memory.limit_in_bytes参数为2GB——这就给容器内所有进程划定了内存使用的硬上限。
• OOM Killer兜底：如果容器内进程（比如mongod）试图突破这个内存限制，Linux内核的OOM Killer会自动触发，优先杀掉容器内占用内存最多的进程，避免耗尽主机内存。不过你碰到的情况是Mongo先用到了swap，这是因为它默认会探测主机的总内存来设置缓存大小，没意识到自己处于容器隔离环境中。
• swap限制的补充配置：你可以用--memory-swap参数来限制容器能使用的「内存+swap」总量，比如docker run -m 2g --memory-swap 2g就等于完全禁用swap，强制MongoDB在内存不足时触发OOM，而不是慢悠悠地跑swap拖垮性能。

Unix/Linux里的资源限制主要分两类，覆盖从单个进程到系统级的场景：

1. 进程级限制：ulimit #

这是针对单个进程或shell会话的轻量限制，常用参数包括：

• -v：限制进程可使用的虚拟内存总量（物理内存+swap），比如ulimit -v 1048576就是限制为1GB
• -m：限制进程可使用的物理内存上限
• -n：限制进程能打开的文件描述符数量（MongoDB高并发场景下经常需要调大这个值）
  你可以用ulimit -a查看当前所有生效的限制，临时设置的话直接在命令行执行对应命令即可；如果要永久生效，可在/etc/security/limits.conf里添加规则。

2. 系统级/组级限制：cgroups #

这是Linux内核提供的更强大的资源隔离方案，也是容器技术的核心基础，除了内存，还能管控CPU、磁盘IO等资源：

• memory子系统：除了前面说的memory.limit_in_bytes，还有memory.memsw.limit_in_bytes用来限制「内存+swap」的总配额
• cpu子系统：通过cpu.cfs_quota_us和cpu.cfs_period_us组合，限制进程组的CPU使用率上限，比如设置cpu.cfs_quota_us=50000、cpu.cfs_period_us=100000就等于限制为50%的CPU使用率
• blkio子系统：可以限制进程组的磁盘读写速度，避免某组进程占满主机IO资源

除了给容器加内存限制，还可以手动设置MongoDB的缓存大小：在mongod的配置里设置wiredTigerCacheSizeGB，把它设为容器内存的70%-80%（比如容器限2GB内存，就设1.4GB左右），这样Mongo就不会误以为能用到主机的全部内存了，从根源上避免swap溢出。

内容的提问来源于stack exchange，提问作者rueberger