写入慢但读取正常时，问题大概率在主节点本身：先用mongostat观察inserts/s、qr/qw、locked%、faults/s；再查slowlog中totaloplogslotdurationmicros；接着验证复制链路健康度；最后排查长事务阻塞。
写入慢但读取正常，先确认是不是主节点写入瓶颈
副本集里只有主节点接受写请求，如果写入卡顿而读取正常，问题大概率在主节点本身，而不是网络或从节点。别急着查复制延迟，先盯住主节点的实时负载。
用 mongostat 1 观察：inserts/s 是否远低于预期、qr/qw 队列是否持续 >0、locked% 是否频繁跳高、faults/s 是否 >100。这些指标比日志更早暴露问题。
-
qr/qw高 → 写操作排队，可能是索引缺失、锁争用或单线程瓶颈（如大量小文档高频插入） -
locked%>5% → 写锁或全局锁竞争，常见于未分片集合上的大批量更新 -
faults/s高 → WiredTiger 缓存不足，工作集超出cacheSizeGB，触发频繁换页
检查慢写入日志里的 totalOplogSlotDurationMicros
这个字段藏在 MongoDB 4.4+ 的慢日志里，它表示写操作从获取 oplog slot 到真正提交的时间差。如果这个值异常高（比如 >100ms），说明写入不是卡在业务逻辑，而是卡在存储引擎提交环节 —— 很可能和 WiredTiger 脏页刷盘有关。
查日志时用：grep "totalOplogSlotDurationMicros" /var/log/mongodb/mongod.log | tail -20，重点关注数值是否集中在毫秒级高位。
- 该值高 +
iostat -x 1显示%util接近 100% → 磁盘 IO 瓶颈，尤其 HDD 或低配 SSD - 该值高 +
mongostat显示%dirty持续 >15% → WiredTiger 缓存压力大，需调大cacheSizeGB或降低写入吞吐节奏 - 该值高 +
vmstat 1显示pgpgin/pgpgout频繁 → 系统内存紧张，WiredTiger 缓存被 OS 回收
验证副本集复制链路是否拖慢主节点写入
主节点写入完成前，会等待满足 writeConcern 要求（比如 w:2）。如果某个从节点响应慢或掉线，主节点会卡在等待阶段，表现为“写入超时”而非“写入慢”。
运行 rs.status() 后重点看：members[n].health 是否全为 1、members[n].stateStr 是否有 RECOVERING 或 UNKNOWN、members[n].optimeDate 是否明显落后于主节点。
- 发现某成员
optimeDate落后 >30 秒 → 检查该节点磁盘 IO（iostat -x 1）、网络延迟（ping和mtr）、是否开启priority:0却没设hidden:true - 所有成员健康但
w:2写入仍慢 → 临时降级为w:1测试，若写入恢复，说明复制链路是瓶颈，需优化从节点硬件或网络 - 主节点日志出现
replSetUpdatePosition失败或heartbeat failed→ 优先排查防火墙、MTU、DNS 解析等基础连通性
db.currentOp({secs_running: {$gt: 5}}) 找出阻塞写入的长事务
一个长时间运行的读操作（比如未加 maxTimeMS 的聚合）可能持有读锁，间接阻塞写入 —— 尤其在 WiredTiger 引擎下，虽然读写并发度高，但某些场景（如大量文档更新伴随复杂查询）仍会因资源争用导致写入排队。
执行：db.currentOp({secs_running: {$gt: 5}, "secs_running": {$exists: true}})，重点关注 secs_running >10 且 ns 涉及正在写入的集合。
- 发现
type: "query"且secs_running高 → 加maxTimeMS限制，或拆分聚合阶段 - 发现
type: "update"或"insert"本身卡住 → 结合.explain("executionStats")看是否扫描过多文档（docsExamined远大于nReturned） - 发现
waitingForLock: true→ 查db.currentOp({waitingForLock: true})定位持锁者，再 kill 对应 opid（慎用）
mongostat 显示写入 QPS 正常，但业务侧感知到延迟，这时得顺着 totalOplogSlotDurationMicros 往下挖，而不是只盯着 inserts/s。副本集的写入性能是主节点能力、复制链路稳定性、存储引擎配置三者共同作用的结果，漏掉任何一环都可能误判。
