MongoDB 在 Docker Compose 中运行约一分钟后崩溃

2026-11-04数据阿明

结论

这段日志显示 mongod 已成功启动，也没有记录到明确的 MongoDB 致命错误。日志只覆盖了启动阶段，因此无法说明它为什么在一分钟后退出。容器也可能是被 Docker 或宿主机直接终止的。

可以先检查 WiredTiger 配置中的 cache_size=30530M。如果容器可用内存明显少于约 30 GB，进程可能因内存不足被 OOM killer 终止。现有日志还不足以确认这一点。

先确认容器是否因 OOM 退出

在运行 Compose 的主机上执行：

docker compose ps -a

查看容器退出状态：

docker inspect <容器名或ID> --format 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} error={{.State.Error}} finished={{.State.FinishedAt}}'

如果 oom=true，或者退出码、Docker 事件显示容器因内存不足被终止，再检查容器内存限制和宿主机可用内存。Linux 主机还可以查看内核日志：

docker events --since 10m --filter container=<容器名或ID>
dmesg -T | grep -i -E 'oom|killed process'

同时查看退出前的日志：

docker compose logs --timestamps --tail=200 mongo

如果确认内存不足

调整 MongoDB 的 WiredTiger 缓存上限，使其适配容器内存。以下 2 GB 仅为示例。应根据容器内存上限和其他进程的开销选择，并为 MongoDB 进程本身留出额外内存：

services:
  mongo:
    image: "mongo:8.0.6"
    command: ["mongod", "--wiredTigerCacheSizeGB", "2"]
    ports:
      - "27017:27017"

修改后重建容器，并观察状态和日志：

docker compose up -d --force-recreate mongo
docker compose logs -f mongo

日志中的警告怎么理解

Access control is not enabled 表示数据库未启用访问控制，是一条安全配置警告。文件描述符、透明大页和 swappiness 的警告也不能单独证明它们导致了进程退出。弃用参数警告同样不能作为这段日志中的崩溃证据。排查时应重点查看容器退出状态、退出前的日志，以及宿主机是否记录了 OOM。

如果 OOMKilled 为 false，且没有内核 OOM 记录，请继续检查完整退出日志和容器事件，并确认是否有外部进程或平台在重启容器。当前材料无法确定崩溃原因。