Linux如何解决MongoDB内存问题

Linux下MongoDB内存问题的定位与治理

一先判断是否为“真问题”

理解WiredTiger的默认缓存：自MongoDB 3.4起，WiredTiger 内部缓存默认取两者中较大者：50% ×（RAM − 1GB） 或 256MB。例如：4GB 内存默认约 1.5GB 缓存，1.25GB 内存默认 256MB。因此看到 mongod 占用接近或超过该值，多为正常行为。可用 db.serverStatus().wiredTiger.cache 查看命中率与使用情况。另需区分 VIRT（虚拟内存）与 RES（常驻内存），以及 Linux 会把大量文件页计入 buff/cache，这部分是可回收的，不能简单等同于内存泄漏。建议用 free -m、top/htop、sar -r/sar -W 观察真实压力与换页情况。

二立即可用的配置与系统层限制

限制WiredTiger缓存上限：在 /etc/mongod.conf 中设置 storage.wiredTiger.engineConfig.cacheSizeGB，建议为物理内存的50%–60%，为操作系统和其他进程预留空间。示例：
```
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 4.0
```
禁用透明大页（THP）：THP可能导致内存分配不均与延迟抖动。临时关闭：
```
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
```
建议写入系统启动脚本或发行版提供的 tuned 配置以持久化。
控制查询与排序的内存占用：为聚合/排序等重操作设置 allowDiskUse: true，并为高频查询建立合适索引、使用投影减少返回字段，避免无索引的大扫描与内存排序。
系统级资源隔离：使用 cgroups/systemd 或容器设置内存上限（如 Docker --memory=4g），为 MongoDB 设置硬性边界，避免影响同机其他服务。

三查询与数据模型优化

为高频查询路径建立复合索引，避免全表扫描；对大结果集使用 limit()/projection 减少传输与内存占用。
优化聚合管道：尽量在管道早期用 $match/$project 减少数据量，必要时启用 allowDiskUse 让中间结果落盘，避免单操作内存超限（MongoDB 默认对单操作内存有限制，超限需显式开启磁盘使用）。
控制文档与索引规模：避免过深嵌套与超大数组；定期清理冗余索引与过期数据，降低索引维护与缓存压力。

四架构与容量扩展

当工作集（热点数据+索引）长期大于可用内存时，单机内存命中率下降，需考虑水平扩展：对集合按高选择性字段进行分片（sharding），将数据分布到多台机器，分摊内存与 I/O 压力。示例：
```
sh.enableSharding("myDatabase")
sh.shardCollection("myDatabase.myCollection", { "shardKey": 1 })
```
若短期内无法扩容，可结合数据归档/冷热分层与TTL 索引减少常驻数据量，优先保证热点数据在内存中。

五监控与应急

持续监控：使用 mongostat、mongotop 观察操作延迟、扫描与命中率；结合 db.serverStatus().wiredTiger.cache 查看缓存命中、脏页与逐出情况；在系统层面用 free、sar -r/-W 观察内存与换页趋势，避免因 Swap 颠簸导致性能骤降。
应急与“释放内存”：Linux 层面可通过 sysctl -w vm.drop_caches=1 清理可回收页缓存（仅影响文件系统缓存，不影响 WiredTiger 缓存），或在万不得已时滚动重启 mongod 释放内存映射；在分片集群中可用 db.runCommand({flushRouterConfig: 1}) 刷新路由缓存。上述手段仅作临时缓解，根因仍需通过限流、优化与扩容解决。

最新问答