Debian系统MongoDB内存配置最佳实践

Debian 上 MongoDB 内存配置最佳实践

一 核心原则

• 以工作集为核心：优先确保工作集（索引 + 热点文档）能常驻内存，WiredTiger 内部缓存的目标是尽量容纳工作集，而非把整机内存吃满。生产上建议将缓存设置为物理内存的 60%–80%，并依据实例角色与其他进程占用动态微调。若主机上还有其他服务，需为系统和其他进程预留充足内存，避免资源争用。对于单实例独占主机的场景，可接近上限；多实例或容器化场景需按权重分配。WiredTiger 默认即为“约一半内存”，多实例/容器需显式配置以降低互相挤占风险。

二 关键配置步骤

• 配置 WiredTiger 缓存上限：编辑 /etc/mongod.conf，设置 storage.wiredTiger.engineConfig.cacheSizeGB。示例（总内存 64GB、单实例独占）：

  storage:
    wiredTiger:
      engineConfig:
        cacheSizeGB: 48   # 约 75%，可按工作集与并发再微调
  

  如部署了多个 mongod 或同机有其他大内存服务，按可用内存与权重下调该值，避免 OOM 或抖动。
• 仅在生产明确需要时使用 In-Memory 引擎：该引擎将数据完全驻留内存，宕机即失，且需显式设置内存上限（如 --inMemorySizeGB），一般仅用于低延迟且可容忍数据丢失的特定场景。
• 查询与索引侧的内存友好实践：为高频查询建立复合索引与覆盖索引，避免全表扫描；使用 limit() 与投影减少返回数据量；用 explain() 分析执行计划并持续优化慢查询。
• 主机与系统层保障：优先使用 SSD 降低 I/O 瓶颈；为 MongoDB 配置专用主机/容器与资源隔离；按需开启网络压缩（如 snappy）降低带宽占用；保持驱动与数据库版本及时升级以获得性能修复与优化。

三 监控与容量规划

• 观察内存与缓存命中：在 shell 中执行 db.serverStatus().mem 查看 resident/virtual/mapped 等指标；结合 wiredTiger 缓存命中率与页面错误等指标判断工作集是否超出缓存。使用 mongostat、mongotop 观察吞吐、延迟与扫描行为，定位慢查询与资源热点。
• 容量判断与调整：若发现工作集 > 缓存上限，优先考虑增加内存、优化索引/查询、归档冷数据或引入**分片（Sharding）**进行水平扩展；若内存长期富余，可适当上调 cacheSizeGB，减少磁盘 I/O。

四 系统层与风险提示

• Swap 策略：数据库对延迟敏感，建议开启适度大小的 Swap作为“安全网”，避免突发内存压力触发 OOM Killer 直接终止 mongod；同时应将 vm.swappiness 调低（如 1–10），让系统在内存紧张时再使用 Swap，减少抖动。权衡点是“可控的慢”优于“不可控的崩溃”。
• 资源隔离与单角色：尽量让每台主机只运行单一 mongod 实例，通过虚拟化/容器进行资源配额与隔离，避免多实例互相影响内存与 I/O。
• 变更流程：任何参数调整先在测试环境验证，观察 24–72 小时关键指标后再推广至生产；变更窗口内保持回滚预案与监控告警到位。