MongoDB副本集配置中如何设置wiredTigerCacheSizeGB以避免内存溢出？

本文共计768个文字，预计阅读时间需要4分钟。

《强化副本集节点内存限制，确保不重复使用单一配置逻辑——每个节点的wiredTigerCacheSizeGB值应按该节点独占内存比例计算，否则主从切换后易引发OOM。》

副本集各节点内存限制必须独立计算

副本集里每个 mongod 实例是独立进程，各自维护自己的 WiredTiger 缓存。即使配置文件完全一样，如果节点部署在不同规格机器上（比如 Primary 在 32GB 内存机器，Secondary 在 16GB 机器），共用同一个 cacheSizeGB: 8 就会出问题：Secondary 启动时缓存实际占用可能超限，触发系统 OOM Killer 杀进程。

• 按物理内存的 50%～60% 算只是默认行为，不是安全值；副本集必须显式设置
• Primary 和 Secondary 节点可能承担不同负载（如 Secondary 开了 readPreference: secondary 读流量），缓存压力不一致
• Arbiter 节点不用设 wiredTigerCacheSizeGB，它不存数据，也不用 WiredTiger 引擎

配置方式优先选启动参数而非配置文件

副本集滚动升级或节点替换时，配置文件同步容易遗漏或滞后，而启动参数更可控、更易验证。尤其在 Kubernetes 或 Docker Compose 场景下，--wiredTigerCacheSizeGB 直接写进 command 字段，比挂载统一配置文件更可靠。

• Linux systemd 服务：修改 /lib/systemd/system/mongod.service 的 ExecStart 行，追加 --wiredTigerCacheSizeGB=6
• Docker：在 docker-compose.yml 的 command 中写死，例如 mongod --replSet rs0 --wiredTigerCacheSizeGB=4 --bind_ip_all
• 不要依赖 mongod.conf 全局配置——副本集节点重启顺序不一，配置加载时机难保证

事务 + 副本集场景下 cacheSizeGB 要额外压低

副本集开启多文档事务时，WiredTiger 快照内存会在主节点累积，同时从节点同步 oplog 并应用时也会复用部分缓存结构。若 maxTransactionLifetimeMinutes 还是默认 60，一个长事务卡住，主节点缓存涨满，Secondary 同步延迟升高，最终双双被 OOM Killer 干掉。

• 先调小事务生命周期：db.adminCommand({setParameter:1, maxTransactionLifetimeMinutes: 2})
• 再压低缓存：比如原计划设 8GB，实际应设为 6 或 5，留出至少 2GB 给 oplog 应用、复制线程和系统开销
• 验证是否生效：连上每个节点执行 db.serverStatus().wiredTiger.cache，重点关注 maximum bytes configured 是否等于你设的值 × 1024³

最容易被忽略的是：副本集里某个 Secondary 节点临时扛了读流量，但它的内存规格比 Primary 低，而 wiredTigerCacheSizeGB 却没相应调低——这时候它不是“性能差”，而是随时可能静默崩溃。别只盯着 Primary 配置。