1. 从一次深夜告警说起：mongod 到底在忙什么
凌晨两点，监控面板上一条写入延迟曲线突然翘头，从 8ms 一路爬到 400ms。登录机器一看，mongod进程 CPU 占用 780%，磁盘 IO 打满，慢查询日志里全是同一个集合的更新操作。那一刻我意识到，很多人天天连 MongoDB，却从没认真看过mongod这个主守护进程到底在干什么。它不是一个黑盒，它有自己的内存模型、线程调度、存储引擎和刷盘节奏，你越了解它，线上就越少出幺蛾子。
mongod是 MongoDB 体系里最核心的进程，没有之一。你启动的每一个单机实例、每一个副本集节点、每一个分片集群里的分片，背后跑的都是它。它负责监听客户端连接、解析查询、管理内存、调度磁盘读写、维护副本集心跳、执行数据压缩与校验。换句话说，MongoDB 的所有能力，最终都要落到mongod这个进程身上。这篇文章我想从一线运维和调优的视角，把mongod拆开讲透：它启动时做了什么、运行时内存怎么分配、存储引擎怎么选、常见故障怎么排查。适合已经用过 MongoDB、但想进一步搞懂底层行为的开发和运维同学，也适合正准备把 MongoDB 上生产、需要提前避坑的团队参考。
我踩过的坑不算少：有一次因为没配wiredTiger缓存上限，mongod把机器内存吃光被系统 OOM Killer 干掉；还有一次副本集选举卡住，排查半天发现是mongod之间的心跳端口被防火墙拦了。这些经历让我明白，光会写db.collection.find()远远不够，理解mongod的运行机制才是真正的分水岭。
2. mongod 启动流程与核心参数拆解
2.1 启动时它到底做了哪几件事
很多人启动mongod就是一句命令丢过去，其实它内部走了一条相当严谨的初始化链路。我把它拆成几个关键阶段，理解了这条链路，配置文件和命令行参数你就不会再瞎填。
第一阶段是配置加载与校验。mongod会先读取配置文件（通常是mongod.conf），把 YAML 里的storage、net、replication、security等段落解析成内部配置对象。这里有个细节：命令行参数的优先级高于配置文件，如果你在配置文件里写了port: 27017，命令行又加了--port 27018，最终生效的是 27018。我见过有人改了配置文件却忘了自己启动脚本里硬编码了端口，排查半天以为是配置没生效。
第二阶段是存储引擎初始化。默认是 WiredTiger，它会打开数据目录、恢复日志文件、校验元数据。如果上一次是异常宕机，这一步会触发 journal 重放，把未落盘的操作补回来。这个阶段如果数据目录权限不对，或者磁盘满了，mongod会直接启动失败并打印明确错误。
第三阶段是网络监听与副本集状态机启动。mongod绑定bindIp指定的地址和端口，开始接受连接。如果配置了replSetName，它会进入副本集模式，尝试与其他节点建立心跳。这里要注意，副本集模式下mongod启动后不一定立刻可写，它需要先完成选举或找到主节点。
第四阶段是后台线程与周期任务拉起。包括 journal 刷盘线程、检查点线程、TTL 索引清理线程、副本集心跳线程等。这些线程是mongod长期稳定运行的保障，也是很多性能问题的根源。
2.2 必须搞懂的几个核心启动参数
下面这张表是我在实际生产里最常调整、也最容易出问题的参数，整理出来方便对照。
| 参数 | 作用 | 常见取值 | 踩坑提示 |
|---|---|---|---|
dbPath | 数据文件存放目录 | 独立大容量数据盘 | 不要放系统盘，IO 争抢严重 |
bindIp | 监听地址 | 内网 IP 或0.0.0.0 | 生产环境慎用0.0.0.0 |
port | 监听端口 | 默认 27017 | 副本集各节点端口可不同 |
wiredTigerCacheSizeGB | WT 引擎缓存上限 | 物理内存的 50%~60% | 不设会吃满内存 |
replSetName | 副本集名称 | 自定义字符串 | 同一副本集必须一致 |
journal | 是否开启日志 | true | 生产必须开启 |
logpath | 日志文件路径 | 独立日志盘 | 便于问题追溯 |
关于wiredTigerCacheSizeGB，这里有个计算逻辑值得展开。WiredTiger 默认会使用(物理内存 - 1GB) * 0.5作为缓存上限，但这个公式在容器环境下经常算错，因为容器看到的可能是宿主机内存。我的经验是：如果机器只跑mongod，可以给到物理内存的 60%；如果还跑其他服务，压到 40% 甚至更低。留出的内存要供操作系统做文件系统缓存，因为 WiredTiger 的压缩数据读取也依赖页缓存。
提示：容器里部署
mongod时，务必显式设置wiredTigerCacheSizeGB，不要依赖自动计算，否则很容易触发 OOM。
2.3 配置文件写法与启动命令的取舍
我倾向于用配置文件而不是一长串命令行参数，原因是配置文件可版本化管理，改动能追溯，团队协作也清晰。一个典型的生产配置大概长这样：
storage: dbPath: /data/mongodb journal: enabled: true wiredTiger: engineConfig: cacheSizeGB: 8 net: port: 27017 bindIp: 10.0.0.11 replication: replSetName: rs0 systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true operationProfiling: slowOpThresholdMs: 100 mode: slowOp启动命令就变得很干净：mongod -f /etc/mongod.conf。这里slowOpThresholdMs设成 100 毫秒，是我根据业务接口的 P99 延迟定的，超过这个值的操作会被记进慢查询日志，方便后续分析。mode: slowOp只记录慢操作，不会全量记录，避免日志爆炸。
3. WiredTiger 存储引擎与内存管理机制
3.1 为什么默认引擎是 WiredTiger
MongoDB 早期用的是 MMAPv1 引擎，后来全面转向 WiredTiger。核心原因有三个：并发控制更细、压缩能力更强、内存管理更可控。MMAPv1 是集合级锁，写并发一高就互相阻塞；WiredTiger 是文档级并发控制，多个写操作只要不碰同一文档就能并行。压缩方面，WiredTiger 默认对集合使用块压缩，对索引使用前缀压缩，磁盘占用能降一半以上。内存管理上，WiredTiger 有自己的缓存池，不再完全依赖操作系统的页缓存策略。
理解 WiredTiger 的内存模型，是调优mongod的关键。它的内存大致分三块：缓存池（Cache）、索引与元数据、连接与会话开销。缓存池是最大头，存放最近访问的数据页，读写都先经过它。当缓存池使用率达到一定阈值，后台的 eviction 线程开始把脏页刷到磁盘。如果写入速度长期超过刷盘速度，缓存池会被填满，新的写操作就得等待，这就是所谓的“cache full”导致的写延迟飙升。
3.2 缓存池与 eviction 的博弈
我遇到过最典型的性能问题，就是 eviction 跟不上写入。表现是写入延迟周期性抖动，日志里出现Eviction encountered a dirty page之类的记录。根因通常是缓存池太小，或者磁盘写入能力不足。排查思路是这样的：
- 先看
db.serverStatus().wiredTiger.cache里的bytes currently in the cache和maximum bytes configured，算一下使用率。 - 再看
pages evicted和pages written的增长速率，判断刷盘是否跟得上。 - 如果使用率长期在 90% 以上，优先考虑加缓存或加磁盘 IO 能力。
这里有个经验值：缓存池使用率长期超过 80% 就该警惕，超过 95% 基本就是瓶颈了。但也不是越大越好，缓存给太多，操作系统页缓存被挤压，反而影响读取压缩数据时的解压效率。
注意：调整
wiredTigerCacheSizeGB需要重启mongod，不能在线改。所以上线前就要规划好，别等出问题才临时加。
3.3 检查点与 journal 的配合
WiredTiger 用检查点（checkpoint）机制来保证数据一致性。每隔一段时间（默认 60 秒），它会把缓存里的脏页刷成一个一致的快照。而 journal 则是更细粒度的操作日志，用于崩溃恢复。两者配合的逻辑是：journal 保证最近的操作不丢，checkpoint 保证整体数据文件一致。
如果journal关闭，mongod崩溃后可能丢失最近 60 秒的数据，而且恢复时要做全量校验，非常慢。所以生产环境我强烈建议开启 journal，哪怕有一点性能损耗也值得。实测下来，开启 journal 对写入性能的影响在 5% 以内，但换来的是数据安全和快速恢复能力。
4. 副本集场景下 mongod 的协作与选举
4.1 心跳机制与节点状态
副本集里每个mongod都会定期向其他节点发送心跳（默认每 2 秒一次）。心跳不只是探活，还携带了节点的状态信息、oplog 进度等。节点根据心跳结果维护一个状态视图，决定谁是主、谁是从、谁不可达。
节点状态主要有几种：PRIMARY（主，可读写）、SECONDARY（从，可读，默认不可写）、ARBITER（仲裁，只投票不存数据）、RECOVERING（恢复中）、DOWN（不可达）。我见过有人把仲裁节点当数据节点用，结果发现它根本不存数据，白白浪费一台机器。
4.2 选举是怎么发生的
当主节点不可达，从节点会发起选举。选举的核心是多数派投票：一个节点要成为主，必须获得超过半数节点的投票。这也是为什么副本集节点数建议是奇数，3 节点、5 节点最常见。2 节点副本集加一个仲裁，本质上也是 3 个投票成员。
选举过程中，mongod会比较各节点的 oplog 进度，进度最新的节点优先当选，避免数据回滚。如果网络分区导致两边都以为自己是多数派，就会出现“双主”风险，但 MongoDB 的多数派机制能避免这种情况，代价是少数派那边会降级为只读。
我踩过的一个坑是：副本集选举一直卡住，日志里反复出现心跳超时。排查后发现是节点之间的心跳端口没放通，虽然客户端端口是通的，但节点间通信走的是同一个端口的不同连接。所以部署副本集时，防火墙规则要确保所有节点之间端口互通，不能只开客户端到节点的方向。
4.3 oplog 与数据同步
从节点通过拉取主节点的 oplog 来同步数据。oplog 是一个固定大小的集合（capped collection），存在local数据库里。它的大小决定了从节点最多能落后主节点多久。如果从节点落后太多，超过了 oplog 覆盖的范围，就需要做全量同步（initial sync），这个过程非常耗资源。
oplog 大小怎么定？我的经验是：按业务写入量估算，保证 oplog 能覆盖至少 24 到 48 小时的写入。比如每秒写入 1000 条、每条 1KB，那一天就是约 86GB，oplog 至少要给到 100GB 以上。默认 oplog 大小往往偏小，生产环境一定要手动调大。
// 查看当前 oplog 大小和覆盖时间 rs.printReplicationInfo() // 查看从节点同步延迟 rs.printSlaveReplicationInfo()这两个命令是我排查副本集问题的第一步，能快速判断是同步延迟还是选举异常。
5. 常见故障排查与性能调优实录
5.1 连接数暴涨怎么处理
mongod默认最大连接数是 65536，但真正的问题往往不是上限，而是每个连接都会消耗内存和文件描述符。连接数一多，mongod的内存占用会明显上升，因为每个连接都有自己的会话上下文。
排查连接来源，我一般用db.currentOp()看当前操作，用db.serverStatus().connections看连接总数和活跃数。如果发现大量空闲连接，多半是客户端连接池配置过大，或者应用没有正确释放连接。解决办法是从客户端侧调小连接池，同时给mongod设置合理的maxIncomingConnections。
提示：连接池不是越大越好。经验公式是：连接数 ≈ 应用实例数 × 每实例并发请求数 × 1.2。盲目调大只会让
mongod更累。
5.2 慢查询定位与索引优化
慢查询是mongod最常见的性能问题来源。开启慢查询日志后，可以用db.setProfilingLevel()配合system.profile集合来分析。我通常关注几个指标：millis（耗时）、docsExamined（扫描文档数）、keysExamined（扫描索引数）。如果docsExamined远大于返回文档数，说明索引没用好，需要补索引或调整查询。
一个真实案例：某集合有 500 万文档，一个查询扫了 480 万文档才返回 10 条。加了复合索引后，docsExamined降到 10，耗时从 800ms 降到 2ms。索引的字段顺序很关键，等值查询字段放前面，范围查询字段放后面，这是基本原则。
5.3 磁盘 IO 瓶颈的识别
mongod对磁盘 IO 很敏感，尤其是写入密集场景。判断 IO 是否是瓶颈，可以看db.serverStatus().wiredTiger里的读写页统计，结合系统层面的iostat。如果磁盘利用率长期接近 100%，且 await 值很高，基本可以确定是 IO 瓶颈。
缓解手段有几个：一是加缓存，减少物理读；二是用更快的盘，比如从机械盘换到 SSD；三是优化写入模式，比如批量写入代替逐条写入。批量写入能显著减少mongod的刷盘次数，我实测过，批量大小在 1000 左右时，写入吞吐能提升 3 到 5 倍。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方向 | 解决手段 |
|---|---|---|---|
| 写入延迟飙升 | 缓存池满、eviction 跟不上 | 看 WT cache 使用率 | 加缓存、加 IO、批量写 |
| 选举卡住 | 心跳不通、多数派不足 | 看节点状态和日志 | 检查网络、补足节点 |
| 内存被吃光 | 缓存未限制、连接过多 | 看进程内存和连接数 | 设缓存上限、调连接池 |
| 启动失败 | 权限、磁盘满、配置错 | 看启动日志 | 修权限、清磁盘、改配置 |
| 同步延迟大 | oplog 太小、网络差 | 看复制延迟 | 调大 oplog、优化网络 |
这张表是我这些年排查问题的经验沉淀，基本覆盖了mongod八成以上的常见故障。遇到问题先对照，能省不少时间。
6. 生产部署的实操建议与个人体会
6.1 部署前的规划清单
上线前我习惯过一遍清单：数据盘是否独立、内存是否够用、缓存是否显式设置、journal 是否开启、oplog 是否调大、慢查询是否开启、日志是否独立存放、副本集节点是否奇数、防火墙是否放通节点间通信。这些看起来琐碎，但每一条都对应过真实的故障。
尤其是数据盘独立这一条，我见过太多把数据目录放系统盘的案例，结果系统日志一写满，mongod直接挂掉。数据盘和日志盘分开，能避免日志写入影响数据 IO，这个细节在高写入场景下差别很明显。
6.2 监控指标该盯哪些
mongod的监控不需要面面俱到，盯住几个核心指标就够：连接数、缓存使用率、oplog 延迟、慢查询数量、磁盘 IO 利用率、复制延迟。这些指标能覆盖绝大多数问题。我一般会设置阈值告警，比如缓存使用率超过 85%、复制延迟超过 10 秒就触发通知。
监控工具的选择上，MongoDB 自带的serverStatus已经能提供大部分数据，配合采集脚本就能用。关键是坚持看，而不是等出问题才看。我养成的习惯是每天早上扫一眼核心指标曲线，异常往往在爆发前就有苗头。
6.3 我个人的几条经验
第一，不要迷信默认配置。MongoDB 的默认值是为通用场景设计的，生产环境几乎都需要调整，尤其是缓存和 oplog。
第二，副本集节点数用奇数，这是投票机制决定的，不是玄学。3 节点是最小可用配置，5 节点能容忍更多故障。
第三，慢查询日志一定要开，它是性能问题的第一手线索。不开慢查询，排查问题就像蒙眼开车。
第四，定期做故障演练。手动下线一个从节点，看看副本集是否正常切换；模拟磁盘满，看看mongod的报错是否清晰。演练过的团队，真出问题时反应速度完全不一样。
第五，升级mongod版本前先在测试环境跑一遍，重点验证存储引擎和副本集行为。大版本升级有时会改变默认行为，不看 release notes 容易踩坑。
这些经验没有一条是书本上直接写的，都是实际运维里一点点攒出来的。mongod这个进程看似简单，背后涉及的机制却相当深，理解得越透，线上就越从容。希望这些内容能帮到正在和 MongoDB 打交道的你，少走一些我走过的弯路。
