副本集内存需求需按角色分拆评估：主节点侧重写入、oplog常驻及写放大；从节点关注同步延迟与读负载；仲裁节点仅需2GB但须防配置错误导致OOM。
副本集内存需求不能只看数据大小，得按角色分拆算——主节点和从节点的内存压力来源完全不同。
主节点内存主要扛写入与Oplog压力
主节点不是“存多少数据就配多少内存”那么简单。WiredTiger引擎会把热数据缓存在内存中，但更关键的是：oplog本身要常驻内存做快速追加，同时还要支撑并发写入的事务上下文、索引构建、聚合管道中间结果等。
- 默认
oplogSize在64GB磁盘上约5%（即3GB），但高写入场景建议设为10–20GB，这部分需稳定驻留内存 - 写放大效应明显：一个
update可能触发多个索引更新+journal刷盘+oplog写入，瞬时内存峰值可达平均值的2–3倍 - 若开启
enableMajorityReadConcern，WiredTiger需额外保留旧版本文档快照，内存占用上升15–25%
从节点内存取决于同步延迟与读负载
从节点不处理写请求，但同步压力可能比主节点还猛——尤其当网络抖动或自身IO慢时，它会疯狂拉取oplog并重放，此时内存主要用于缓冲未应用的操作队列和临时排序空间。
- 同步延迟超过30秒时，
oplog回溯窗口扩大，内存中缓存的待重放操作数激增 - 如果配置了
slaveDelay（比如延迟1小时），内存需容纳对应时间窗口内的全部oplog条目 - 开启
readPreference: "secondary"后，从节点承担实际查询负载，其工作集（working set）必须能覆盖常用查询的索引+文档，否则频繁换页
仲裁节点几乎不消耗内存，但别误配成数据节点
仲裁节点（arbiter）只参与投票，不保存数据、不拉oplog、不响应读写请求，理论上2GB内存足够。但容易踩的坑是：配置文件里漏掉votes: 0或priority: 0，导致它被误认为数据节点——这时MongoDB会尝试加载数据文件，瞬间OOM。
- 启动时检查
rs.status().members[n].stateStr是否为ARBITER，而非SECONDARY或STARTUP - 配置中必须显式设置：
"votes": 0, "priority": 0, "hidden": true（隐藏可避免驱动误连） - 不要把仲裁节点和主/从节点部署在同一物理机——内核OOM Killer可能优先杀掉它，导致选举票数不足
真正卡住多数人的不是总内存大小，而是没意识到：同一副本集里三个节点的内存使用模式完全不对称。主节点怕写风暴，从节点怕同步积压，仲裁节点怕配置错——分开评估、分开压测，比统一按数据量乘系数靠谱得多。
