mongodb大事务触发oom是因为其在内存中维护完整写操作快照，修改文档多、单文档大或事务超时会导致wiredtiger缓存耗尽，os触发oom killer。

为什么MongoDB大事务会触发OOM

MongoDB 4.0+ 支持多文档事务，但事务在内存中维护完整的写操作快照（包括所有修改的文档原始版本），writeConcern 和 readConcern 级别越高，快照保留时间越长。当单个事务修改数万文档、或单文档超16MB（比如批量嵌套日志）、或事务持续超60秒，WiredTiger引擎的内存池（wiredTigerCacheSizeGB）极易被占满，OS直接触发OOM Killer杀掉 mongod 进程。

用maxTransactionLifetimeMinutes硬限事务时长

默认值是60分钟，对高吞吐业务太宽松。必须主动压低，否则长事务+并发一上来，内存增长完全不可控。

• 在 mongod.conf 的 setParameter 下设：

  setParameter:<br>  maxTransactionLifetimeMinutes: 2

• 线上已运行集群，可用 db.adminCommand({setParameter:1, maxTransactionLifetimeMinutes:2}) 热生效
• 注意：该参数只限制“空闲时间”，不阻止事务内操作耗时；若事务内有慢查询，仍可能因数据集膨胀OOM

避免在事务里做find().forEach()式遍历更新

这是最常见踩坑点：用事务包裹一个循环，每轮 updateOne 一次——表面看是“小操作”，实则每个 updateOne 都向事务快照追加旧文档副本，N次就是N份冗余内存。

• 改用单条 updateMany 替代循环：db.orders.updateMany({status: "pending"}, {$set: {status: "processing"}})
• 若逻辑复杂无法单条完成，拆成多个独立事务，每批控制在500文档以内（根据单文档大小动态下调）
• 绝对不要在事务里调 db.collection.find().toArray() —— 整个结果集会先加载进内存再进事务上下文

监控transactionMetrics里的currentActive和currentInactive

这两个指标藏在 serverStatus 的 metrics.transaction 节点下，比看 top 更早暴露问题：一旦 currentActive 持续 > 3 且 currentInactive 缓慢下降，说明事务提交/回滚卡住，快照正不断堆积。

• 用 db.runCommand({serverStatus: 1}).metrics.transaction 手动查
• 关键阈值：如果 currentActive × 平均文档大小 > 0.7 × wiredTigerCacheSizeGB（单位GB），立刻告警
• 注意：MongoDB 6.0+ 新增 transactionStats 命令，但仅限 internal 角色，生产环境通常不可用

事务真正危险的不是“大”，而是“看不见的膨胀”——一个看似只改3条记录的事务，如果其中一条文档含20MB二进制字段，它实际占用的快照内存就是60MB。别信日志里“transaction completed”的提示，得盯住 wiredTigerCacheSizeGB 实时使用率。