如何优化Linux下MongoDB内存使用

Linux下MongoDB内存优化实操指南

一 内存使用原理与预期

• WiredTiger 缓存默认上限：自 MongoDB 3.4 起，WiredTiger 内部缓存为以下两者的较大者：50% ×（RAM − 1 GB） 或 256 MB。例如：4 GB 内存默认约 1.5 GB 缓存；1.25 GB 内存默认 256 MB。这是“上限”，并非进程常驻占用，MongoDB 仍会利用操作系统页面缓存加速访问。
• 工作集与内存关系：当**工作集（常访问的数据+索引）**超过可用内存，会出现更多磁盘读、页面换入换出，性能下降。优化目标是让热数据尽量留在内存中，并减少一次性拉取的数据量。

二 快速检查与监控

• 系统层面：用 free -h 观察内存与 buff/cache（可回收），用 top/htop 查看 mongod 的 RES/VIRT；必要时用 sar -r/-W 观察内存与换页趋势。注意：Linux 的 cached 多为可回收，不能简单等同于“内存吃满”。
• 数据库层面：用 mongostat（吞吐、锁、页错误）、mongotop（集合读写耗时）定位异常集合与慢操作；开启 慢查询日志 捕获高成本操作。

三 配置层面优化

• 限制 WiredTiger 缓存上限（最直接有效）：在 /etc/mongod.conf 中设置
  storage.wiredTiger.engineConfig.cacheSizeGB，例如：
  storage:
  wiredTiger:
  engineConfig:
  cacheSizeGB: 2
  建议值：为系统内存的**20%–40%**起步，结合工作集与并发调优，避免把系统内存挤占殆尽。
• 控制内存密集型操作的内存上限：
  • 排序/聚合内存上限：db.setParameter({ internalQueryExecMaxBlockingSortBytes: 104857600 })（100 MB）
  • 单个查询可用内存：db.setParameter({ internalQueryExecMaxMemoryUsageMB: 512 })（512 MB）
• 降低连接数压力：合理设置 net.maxIncomingConnections（默认很大），避免每个连接占用额外栈与缓冲区。
• 数据模型与索引：避免大文档与过度嵌套；为高频查询建立复合索引并使用覆盖索引/投影减少回表与传输量。
• 读写分离与副本集：将报表/分析类读流量指向secondary，减轻 primary 内存与 I/O 压力。
• 水平扩展：当数据集显著大于内存且增长持续，优先考虑分片（sharding），将数据与内存压力分摊到多节点。

四 Linux 系统层面优化

• 调整 vm.swappiness：降低换页倾向（如设为 10），仅在必要时使用 swap；命令：sysctl vm.swappiness=10，并写入 /etc/sysctl.conf 持久化。
• 内存过量使用策略：设置 vm.overcommit_memory=2（更保守的分配策略），减少突发内存分配失败风险；写入 /etc/sysctl.conf 持久化。
• 容器/虚拟化环境：为 mongod 容器设置内存上限与 OOM 策略，避免影响宿主机稳定性。
• 谨慎使用 cgroups：如需“硬上限”，可用 cgroups memory.limit_in_bytes 限制 mongod 进程总内存，并预留余量给文件系统缓存与连接开销。

五 落地步骤与容量规划

• 基线采集：记录 free -h、top、mongostat/mongotop 与慢查询，明确当前工作集与瓶颈。
• 设定缓存上限：按“20%–40% 内存”为起点配置 cacheSizeGB，留出余量给系统与其他服务。
• 优化查询与索引：补齐缺失索引、改写大排序/大聚合、使用投影与分页策略，降低单次操作的内存与 I/O。
• 压测与回看：在接近生产的数据量与并发下压测，观察 page faults、eviction、queue、latency，微调 cacheSizeGB 与查询参数。
• 容量判断：若“工作集 > 可用内存”且无法通过索引/模型优化，优先加内存或分片；若只是偶发峰值，结合 连接池与慢查询治理 即可。
• 风险提示：变更配置前在测试环境验证；修改 cacheSizeGB 需重启实例；谨慎调整 swappiness/overcommit_memory，避免影响系统稳定性。