1. 从一次凌晨三点的告警说起mongod 到底在忙什么很多人第一次接触 MongoDB是从一条连接字符串开始的把数据塞进去、查出来任务就算完成了。直到某天凌晨监控面板上一条关于mongod进程 CPU 飙高的告警把你叫醒你才发现这个一直默默在后台跑的主守护进程其实才是整个数据库系统真正的心脏。mongod是 MongoDB 体系里最核心的进程它负责数据存储、查询执行、复制集同步、分片路由协调、日志写入、内存管理等等几乎所有脏活累活。你平时用的mongosh、各种语言的 Driver、备份工具本质上都是在跟mongod对话。这篇文章想聊的不是官方文档里那种“mongod是主守护进程”的一句话定义而是从一线运维和开发的角度把这个进程拆开来看它启动时到底做了哪些事参数怎么配才不容易翻车内存和存储引擎之间是什么关系出问题的时候怎么顺着它的行为去排查。适合已经用过 MongoDB、但对底层进程行为还比较模糊的开发者也适合需要自己维护一套数据库实例的运维同学。读完之后你至少能做到两件事一是能看懂mongod启动日志里每一行在说什么二是遇到性能或启动异常时知道该往哪个方向去查而不是盲目重启。我个人的习惯是把mongod当成一个“有脾气的员工”来对待。它启动慢、吃内存、对磁盘挑剔但只要你摸清它的脾气把参数喂对了它就能稳定干活好几年。下面就从它的启动流程开始一层层往下剥。2. mongod 启动时到底做了哪些事2.1 配置文件与命令行参数的优先级博弈mongod的启动方式有两种命令行直接带参数或者通过配置文件通常是mongod.confYAML 格式加载。实际生产环境里几乎没人会把一堆参数写在命令行里因为那样既难维护又容易出错。但这里有个很多人踩过的坑命令行参数和配置文件参数同时存在时命令行参数的优先级更高。这意味着如果你在配置文件里写了storage.dbPath又在启动命令里加了一个--dbpath最终生效的是命令行那个。我见过一个真实的排查案例某同学改了配置文件里的dbPath重启后数据“消失”了吓得以为数据被删。实际上是因为他的启动脚本里还残留着旧的--dbpath参数mongod老老实实按命令行参数启动指向了另一个空目录。所以我的建议是生产环境统一用配置文件启动脚本里只保留--config一个参数把优先级问题彻底消灭。一个典型的配置文件长这样storage: dbPath: /data/mongodb/data journal: enabled: true wiredTiger: engineConfig: cacheSizeGB: 4 systemLog: destination: file path: /data/mongodb/logs/mongod.log logAppend: true net: port: 27017 bindIp: 127.0.0.1 processManagement: fork: true pidFilePath: /data/mongodb/mongod.pid这里每一项都不是随便写的。dbPath是数据文件的家journal是预写日志开关cacheSizeGB是 WiredTiger 存储引擎能吃多少内存bindIp决定谁能连进来fork决定是否后台运行。下面挑几个关键的展开说。2.2 数据目录、日志与 PID 文件的三件套mongod启动时第一件正经事是去检查dbPath指向的目录。如果目录不存在它会直接报错退出不会帮你创建。这一点跟某些“贴心”的服务不一样MongoDB 的态度是目录你自己准备好权限你自己搞定我只负责往里写。所以部署时第一步永远是mkdir -p加上chown把目录和权限先安排明白。日志文件由systemLog控制。destination可以是file或syslog生产环境一般用file方便切割和检索。logAppend: true表示重启时追加而不是覆盖这个一定要开否则每次重启历史日志就没了排查问题时欲哭无泪。日志里会记录连接建立、查询慢操作、复制集状态变化、检查点等大量信息是排查问题的第一手资料。PID 文件则记录了mongod进程号配合fork: true使用。有了它停止服务时就能精确地kill掉对应进程而不是靠pkill mongod这种粗暴方式误伤其他实例。我习惯把 PID 文件和数据目录放在同一级方便统一管理。2.3 存储引擎初始化WiredTiger 的检查点与日志恢复mongod默认使用 WiredTiger 存储引擎。启动过程中WiredTiger 会做两件重要的事检查点恢复和日志重放。如果上次是正常关闭它会从最近的检查点直接加载如果上次是异常崩溃比如断电、被kill -9它就要读取 journal 日志把没来得及落盘的操作重新执行一遍。这个过程可能持续几秒到几分钟取决于崩溃前写入量的大小。这就是为什么千万不要用kill -9去停mongod。正常停止应该用mongosh里的db.shutdownServer()或者给进程发SIGTERM让它有机会把内存里的数据刷盘、写好检查点再退出。我见过有人图省事直接kill -9结果下次启动花了十几分钟做恢复期间服务完全不可用得不偿失。启动日志里如果看到类似Recovering from a previous unclean shutdown的字样就说明上次没正常关闭。这时候不用慌让它跑完恢复流程即可但要在事后复盘为什么会异常关闭。3. 内存、缓存与连接数mongod 最容易被误解的三个参数3.1 cacheSizeGB 不是越大越好WiredTiger 的cacheSizeGB控制的是存储引擎内部缓存的大小默认值是物理内存的一半如果内存大于 1GB。很多人一看“缓存”就觉得越大越好直接设成物理内存的 80%结果系统开始疯狂 swap性能反而暴跌。原因在于mongod除了 WiredTiger 缓存还需要内存来处理连接、维护游标、做排序和聚合操作。如果缓存把内存吃光了操作系统没有余量给文件系统缓存和进程本身就会触发换页。我的经验值是专用数据库服务器上cacheSizeGB设为物理内存的 50% 到 60%如果这台机器还跑着其他服务就要相应下调给别的进程留出空间。举个例子一台 32GB 内存的机器cacheSizeGB设 16GB 比较稳妥。剩下的 16GB 里一部分给操作系统做文件缓存一部分给连接和临时操作。这样即使并发上来也不至于因为内存争抢导致响应时间抖动。3.2 连接数上限与连接池的配合net.maxIncomingConnections控制mongod能接受的最大连接数默认是 65536。这个数字看起来很大但每个连接都会消耗内存大约 1MB 左右的栈空间加上其他开销连接数一多内存压力就上来了。真正的问题往往不在mongod这边而在客户端。很多应用使用连接池如果池子配置不当比如每个应用实例开 100 个连接10 个实例就是 1000 个连接再加上其他服务很容易把连接数推高。我的做法是先算清楚总连接需求再反推maxIncomingConnections同时给应用侧的连接池设一个合理上限。一般单个应用实例的连接池大小控制在 10 到 50 之间具体看并发量。另外mongod有个connPoolMaxShardedConnsPerHost之类的参数是给分片集群用的单实例部署不用管。别看到参数就往上堆用不到的参数保持默认最安全。3.3 内存不足时的典型症状与判断方法当mongod内存吃紧时症状通常不是直接报“内存不足”而是表现为查询变慢、出现大量慢日志、serverStatus里的pageFaults飙升、WiredTiger 的cache eviction频繁触发。这时候你可以用db.serverStatus().wiredTiger.cache去看缓存淘汰情况如果pages evicted增长很快说明缓存不够用数据频繁在内存和磁盘之间倒腾。判断是不是内存问题还有一个简单办法看操作系统的free -h和vmstat。如果si、soswap in/out持续不为零那基本可以确定内存不够了。这时候要么加内存要么调小cacheSizeGB给系统留余地要么优化查询减少内存占用。盲目重启是没用的问题会很快复现。4. 复制集与分片场景下 mongod 的角色差异4.1 单实例、副本集成员、分片节点同一个进程不同身份mongod这个进程本身是同一套程序但通过启动参数的不同它可以扮演三种角色单实例、副本集成员、分片集群中的分片节点或配置节点。单实例最好理解就是一个独立的数据库。副本集成员则通过replication.replSetName参数加入某个副本集参与选举和数据同步。分片节点通过sharding.clusterRole声明自己的角色配置节点还要额外设置configsvr: true。这三种身份下mongod的内部行为差异很大。副本集成员要维护 oplog操作日志要跟其他成员心跳通信要参与选举分片节点要跟mongos路由进程配合处理数据分片。所以不要拿单实例的经验去套副本集很多参数在副本集下含义完全不同。4.2 oplog 大小对副本集成员的影响副本集里每个成员都有一个local.oplog.rs集合记录所有写操作。从节点靠它来同步数据如果从节点落后太多而 oplog 又太小旧的操作被覆盖了从节点就再也追不上了只能全量重新同步。这个过程非常耗时所以oplog 大小要提前规划好。默认情况下oplog 大小是磁盘空间的 5%但有个下限和上限。对于写入量大的业务5% 可能只够存几个小时的操作。我的建议是根据业务写入峰值和能容忍的最长从节点离线时间来计算。比如业务每秒写入 1000 条操作每条平均 1KB一天就是约 86GB如果要保证从节点离线一天后还能追上oplog 至少要能存 86GB 以上。当然实际不会设这么大但至少要有几小时的缓冲。修改 oplog 大小需要重启成员并以副本集方式重新配置操作有一定风险所以最好在部署初期就规划好别等出问题了再改。4.3 分片集群中 mongod 与 mongos 的协作边界在分片集群里mongod负责实际的数据存储mongos负责路由查询。客户端连的是mongosmongos再根据分片键把请求转发给对应的mongod。这里有个容易混淆的点分片键的选择直接决定了mongod的负载是否均衡。如果分片键选得不好比如用了单调递增的字段所有新写入都会落到同一个分片那个分片的mongod就会成为瓶颈而其他分片闲着。所以分片场景下mongod的性能问题往往要回到分片键设计上去找原因。排查时可以先看db.stats()里各分片的数据量和操作数如果差异悬殊基本就是分片键的问题。这时候调mongod参数是治标不治本得从数据分布入手。5. 从启动日志和运行指标里读出 mongod 的真实状态5.1 启动日志逐段解读mongod的启动日志信息量很大但很多人只看最后一行“waiting for connections”前面全忽略了。其实前面每一段都在告诉你它做了什么。典型的启动日志顺序是解析配置、初始化存储引擎、恢复日志、建立索引、启动网络监听、加入副本集如果有。如果中间某一步卡住或报错日志里会有明确提示。比如看到WiredTiger recovery相关的行说明在做崩溃恢复看到Waiting for connections之前的Replica set member state changed说明副本集状态在变化。我习惯在部署新实例时把完整启动日志从头到尾读一遍确认没有 warning 和 error这样心里才有底。5.2 serverStatus 里最该盯的几个字段db.serverStatus()返回的文档非常大但日常运维只需要盯几个关键字段字段路径含义关注点connections.current当前连接数接近上限时要警惕connections.available剩余可用连接持续下降说明连接泄漏opcounters各类操作计数突增可能意味着异常流量wiredTiger.cache.bytes currently in the cache缓存使用量接近 cacheSizeGB 时注意淘汰wiredTiger.cache.pages evicted缓存淘汰页数增长过快说明缓存不足metrics.cursor.open.total打开的游标数过高可能是游标未关闭replSet副本集状态关注成员健康度和延迟这些指标配合监控系统做趋势图比单看某一时刻的值有用得多。比如连接数缓慢上升可能是应用没正确关闭连接opcounters 突然飙升可能是某个查询没走索引导致全表扫描。5.3 慢查询日志与 profiler 的开启姿势mongod支持慢查询日志通过operationProfiling配置。可以设置slowOpThresholdMs来定义多慢算慢默认是 100ms。开启 profiler 会带来一定性能开销所以生产环境一般只开慢日志不开全量 profiler。operationProfiling: slowOpThresholdMs: 100 mode: slowOpmode有三个值off、slowOp、all。all会记录所有操作开销很大只适合短期排查。我一般用slowOp阈值设 100ms然后定期分析慢日志找出需要加索引的查询。慢日志里会记录操作类型、命名空间、执行时间、扫描文档数等扫描文档数远大于返回文档数的基本就是缺索引。6. 那些年我踩过的 mongod 坑6.1 权限问题导致启动失败最常见的一个坑用 root 创建了数据目录然后用普通用户启动mongod结果因为目录权限不对启动直接失败。日志里会写Permission denied但如果你不看日志只看到进程没起来就会一头雾水。解决办法很简单确保数据目录、日志目录、PID 文件目录的属主和启动用户一致。部署脚本里加一行chown -R mongodb:mongodb /data/mongodb就能避免。6.2 磁盘写满引发的连锁反应mongod对磁盘空间很敏感。磁盘写满后它无法写 journal无法做检查点最终会拒绝写入甚至崩溃。更麻烦的是磁盘满的时候日志可能也写不进去导致你连报错都看不到。所以监控磁盘使用率是运维 MongoDB 的基本功建议在 80% 就告警留出处理时间。如果真遇到磁盘满先清理日志和不必要的文件腾出空间让mongod恢复写入然后再做数据迁移或扩容。不要直接删数据文件那会导致数据损坏。6.3 大事务与长连接带来的内存压力MongoDB 支持多文档事务但大事务会占用大量内存尤其是在事务未提交期间相关的锁和快照都要保留。如果应用里有长事务mongod的内存会被慢慢吃掉。同样长时间不关闭的游标也会占用内存。我的经验是事务尽量短小游标用完就关批量操作分批做。这些习惯能显著降低mongod的内存压力。排查这类问题可以看serverStatus里的transactions相关指标和metrics.cursor如果数字异常高就要去应用侧找原因了。7. 把 mongod 管好其实就这几件事绕了一大圈回到最朴素的几个动作配置文件写清楚目录权限给对内存参数留余量日志定期看指标持续盯。mongod不是一个需要天天折腾的进程它更像一个基础设施你把它启动时的环境准备好它就能安静地跑很久。真正出问题的时候往往不是它本身有多复杂而是我们忽略了某个基础环节——权限、磁盘、内存、连接数来来回回就是这些。我自己维护时间最长的一套实例跑了三年多没重启过中间只调整过一次cacheSizeGB。秘诀没什么特别的就是部署时把参数算清楚上线后把监控配好出小问题及时处理不让它演变成大故障。希望这些经验能帮你少走点弯路把精力留给业务本身而不是天天跟数据库进程较劲。