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 瓶颈
connectionsPerHost，或者 Node.js 驱动把 poolSize 写成了 100 而不是 10。定位时别被“分片集群”四个字带偏——先当单机查，再确认是不是分片逻辑本身出了问题。 
