MongoDB 4.4 CPU占用过高致查询超时及副本集主节点状态异常

迁移至MongoDB 4.4.18后出现以下异常：

• 客户端查询频繁超时
• mongod进程CPU占用间歇性飙升至999.9%，操作量未显著增加
• 副本集主节点状态在UNKNOWN与PRIMARY间反复切换，操作量在异常时段骤降后恢复

环境信息 #

• MongoDB版本：4.4.18
• Java客户端驱动版本：3.12.9
• 集群结构：4个数据节点 + 1个仲裁节点
• 存储引擎：WiredTiger
• mongod启动命令：

/usr/bin/mongod --ipv6 --slowms 500 --storageEngine wiredTiger --wiredTigerCacheSizeGB 22 --enableMajorityReadConcern false --bind_ip_all --keyFile /root/.dbkey --port 27717 --dbpath=/var/data/sessions.1/h --replSet set01h --fork --pidfilepath /var/run/sessionmgr-27717.pid --oplogSize 5120 --logpath /var/log/mongodb-27717.log --logappend --quiet

1. 定位主节点反复切换的根因 #

主节点状态波动通常和副本集心跳、选举机制相关：

• 检查主节点mongod日志（/var/log/mongodb-27717.log），搜索election、heartbeat、step down关键词，确认是否存在主动退选或被投票移除的情况，比如主节点长时间无法响应心跳导致从节点触发选举。
• 测试节点间网络连通性：在各节点执行ping、mtr命令，检查主从节点、主节点与仲裁节点的网络延迟和丢包情况，间歇性网络异常会直接干扰副本集心跳检测。
• 验证仲裁节点状态：登录仲裁节点执行rs.status()，确认其正常参与投票，未出现网络隔离。

2. 分析CPU飙高的具体原因 #

CPU满载需定位消耗来源：

• 结合慢查询日志（slowms=500）和MongoDB profiler，排查异常时段是否存在耗时极长的查询、聚合操作，或大量并发写操作引发锁竞争；执行db.currentOp()查看当前运行的操作，识别阻塞或长时间运行的任务。
• 检查WiredTiger指标：执行db.serverStatus().wiredTiger，查看缓存命中率、页面刷新状态。缓存命中率过低会导致大量磁盘IO引发CPU飙升，后台刷页线程异常也可能占用过多CPU。
• 查看线程级CPU消耗：使用top -H -p <mongod_pid>查看mongod进程内的线程CPU占比，判断是用户态（业务操作）还是内核态（IO、系统调用）消耗过高；若内核态占比高，用iostat、iotop排查磁盘IO性能。

3. 客户端驱动与连接配置检查 #

• Java驱动3.12.9与MongoDB 4.4.18兼容，但需确认客户端连接配置：heartbeatFrequencyMS是否合理（默认10秒，网络不稳定可适当调低），是否开启自动重连机制，避免主节点切换时出现大量连接超时。
• 检查连接池状态：通过db.serverStatus().connections查看连接数变化，确认是否存在连接池耗尽导致新请求排队等待的情况。

4. 配置参数合理性验证 #

• 确认wiredTigerCacheSizeGB=22符合服务器内存配置：WiredTiger缓存建议不超过物理内存的50%-60%，内存不足会引发缓存频繁换页，导致CPU和IO飙升。
• enableMajorityReadConcern=false已禁用多数读关注点，需同步确认副本集写关注配置，排查是否存在等待副本确认的超时情况。
• 验证oplogSize=5120（5TB）的合理性：过大的oplog可能增加主从同步开销，尤其是节点恢复阶段，需结合日志判断是否与当前问题相关。

内容的提问来源于stack exchange，提问作者Kiran Pamula