如何快速定位MongoDB分片集群瓶颈节点？

mongostat 是最快暴露 MongoDB 瓶颈节点的工具，重点关注 conn（连接数）、qr/qw（读写队列）和 faults/s（页错误率）；conn 持续偏高说明流量不均或直连单点，qr/qw 持续增长表明请求堆积，faults/s > 50 提示内存不足。

直接看 mongostat 的 conn 和 qr/qw 指标

mongostat 是最快暴露瓶颈节点的工具，不需要登录每台机器查日志。在任意能连到 mongos 的终端执行 mongostat --host <mongos_host>:27017 1，重点关注三列：

• conn：当前连接数。如果某台 mongos 的 conn 持续高于其他实例（比如 800+ 而其他是 200），说明流量没打散，或者客户端直连了单点 mongos
• qr（read queue）和 qw（write queue）：非零且持续增长，代表请求堆积。若只有一台 shard 的 qr/qw 明显偏高，大概率是它对应的 primary 节点磁盘 IO 或 CPU 卡住，不是 mongos 层问题
• faults/s > 50：说明该节点内存不足，WiredTiger 缓存撑不住工作集，开始频繁换页

用 db.serverStatus() 查分片节点的锁与内存细节

对 mongostat 中异常的节点，直接连上去跑 db.serverStatus()，重点盯这几个字段：

• globalLock.ratio > 0.3：读锁争用严重，常见于大量并发 find + $lookup 跨分片聚合
• mem.resident 接近服务器总内存：物理内存快耗尽，WiredTiger cache 被 OS 回收，性能断崖下跌
• metrics.document.deleted 和 inserted 比值异常高：说明有大量删除操作，可能触发 WiredTiger 的 page split 或 compaction 压力
• sharding.enabled 为 true 但 sharding.version 过旧：配置同步延迟，会导致 chunk 迁移卡住，让部分 shard 承载远超均值的数据量

netstat + mongostat 交叉验证连接层瓶颈

连接数高不等于 mongos 真的扛不住，90% 是客户端在狂建连接。先执行 netstat -an | grep :27017 | wc -l 查操作系统级 TCP 连接总数，再对比 mongostat 里显示的 conn 值：

• 如果 netstat 结果比 mongostat 的 conn 大出 2 倍以上：存在大量 TIME_WAIT 连接没回收，或应用侧没复用连接池（比如 Java 驱动 connectionsPerHost 设太高）
• 如果两者接近但 conn 持续高位：检查是否开了 releaseConnectionsAfterResponse 参数，它只影响 mongos → mongod 连接，不影响客户端连接数
• 注意：mongos 本身不维护持久连接池，所有连接都是透传的，所以连接压力最终反映在后端 shard 上

别跳过 mongotop 定位热点集合

mongostat 只告诉你“哪台机器忙”，mongotop 才告诉你“忙在哪张表”。在疑似瓶颈的 shard primary 上执行 mongotop 1：

• 如果某个集合的 total 时间占整机 70% 以上，且 read 或 write 单项极高：立刻查该集合的索引和查询模式
• 看到 system.keys 或 system.profile 耗时异常：说明 profiling 开太猛，或者密钥轮换/审计日志写入失控
• 注意：mongotop 统计的是“最近 1 秒内各集合的读写毫秒数”，不是 QPS，数值高低直接对应 I/O 压力，比 mongostat 更早暴露 IO 瓶颈

真正卡住的往往不是 mongos，而是某台 shard 的磁盘队列或内存换页；而连接数爆满，八成是 Java 应用没调 connectionsPerHost，或者 Node.js 驱动把 poolSize 写成了 100 而不是 10。定位时别被“分片集群”四个字带偏——先当单机查，再确认是不是分片逻辑本身出了问题。