副本集各节点必须单独设置wiredTigerCacheSizeGB，按各自物理内存50%～60%独立计算，不可复用统一配置；Arbiter不需设置；优先使用启动参数而非配置文件；事务场景下需进一步压低缓存并缩短maxTransactionLifetimeMinutes。
副本集节点必须单独设内存限制，不能复用单机配置逻辑——每个节点的 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 配置。
