mongodb 在宝塔中被 oom kill 是因未限制内存，wiredtiger 缓存默认占内存过高，需在 /www/server/mongodb/etc/mongod.conf 中显式配置 wiredtiger.engineconfig.cachesizegb（如 1），并设置 systemd 的 limitnofile=65536 防文件数不足。
为什么 MongoDB 在宝塔里总被 OOM kill？
宝塔面板默认用 systemd 管理服务，但 mongod 进程启动时没限制内存，而 Linux 内核的 OOM killer 会优先干掉占用内存突增的进程——这正是你看到 mongod 随机挂掉、日志里出现 Killed process mongod (pid 1234) 的根本原因。不是 MongoDB 本身崩了，是系统把它“清退”了。
关键点在于：MongoDB 默认使用内存映射（mmapv1）或 WiredTiger 引擎的缓存机制，它不主动释放内存，而是依赖操作系统回收；但宝塔环境常跑在小内存 VPS（如 2GB）上，没做任何约束时，WiredTiger 的 cacheSizeGB 可能占满可用内存的 50% 以上，再叠加 Nginx、PHP、MySQL，OOM 几乎必然发生。
怎么安全设置 WiredTiger 缓存大小？
必须通过 mongod.conf 显式配置，不能靠启动参数临时加。宝塔用户常误改 /www/server/mongodb/bin/mongod 启动脚本，这是无效的——systemd 会忽略它，实际读的是配置文件。
操作步骤：
- 编辑配置文件：
/www/server/mongodb/etc/mongod.conf - 在
storage:下添加或修改wiredTiger:块（注意缩进，YAML 对空格敏感） - 设缓存上限，例如 1GB：
wiredTiger:<br> engineConfig:<br> cacheSizeGB: 1
- 重启服务：
systemctl restart mongodb
⚠️ 注意：值不能写小数点后太多位（如 0.75 可以，0.755 会报 YAML 解析错误）；生产环境建议设为物理内存的 30%~40%，且不超过 2GB（避免 swap 频繁）。
宝塔环境下哪些配置项容易冲突？
宝塔自动生成的 systemd 服务文件（/usr/lib/systemd/system/mongodb.service）可能覆盖你的 ulimit 设置，导致 MongoDB 打开文件数不足，引发连接拒绝或 journal 写入失败。
必须同步检查并修正：
- 运行
systemctl cat mongodb，确认LimitNOFILE至少为65536 - 若未设置，在
[Service]段手动追加：LimitNOFILE=65536<br>LimitNPROC=65536
- 重载配置：
systemctl daemon-reload && systemctl restart mongodb
另外，宝塔「软件管理」里点击「设置」→「配置修改」打开的编辑器，有时会偷偷把 tab 转成空格、删掉末尾换行，导致 YAML 格式损坏——建议用 nano 或 vim 直接编辑，改完用 mongod --config /www/server/mongodb/etc/mongod.conf --dryRun 验证语法。
要不要关 journal 或启用 numactl？
journal 关系数据安全性，不建议关。但如果你确定业务可接受秒级丢失（比如日志分析库），可在 storage: 下加：
journal:<br> enabled: false，能小幅降低写放大和内存压力。
numactl 在单路 CPU 的 VPS 上基本无效，反而可能因绑核失败导致启动失败；宝塔部署的 MongoDB 多数跑在虚拟化环境（如 KVM/OpenVZ），NUMA 节点不可见，强行加 numactl --interleave=all 到启动命令里，只会让 systemctl status mongodb 显示 failed to execute numactl。
真正该盯住的是 top 里 %MEM 和 RES 列——如果 mongod 的 RES 长期稳定在 cacheSizeGB × 1.2 附近，说明调得合理；如果持续上涨逼近总内存，就得查是否有未关闭的游标、聚合管道没加 $limit、或索引缺失导致全表扫描。
