mongostat 是分片集群负载分布的第一响应工具，通过 conn、qr/qw、faults/s 三列快速定位异常节点；使用 --discover 可批量监控但需注意遗漏离线节点；高 conn 多因客户端问题，需结合 netstat 验证；qr/qw 异常时应立即用 mongotop 定位热点集合。
mongostat 是分片集群负载分布的第一响应工具，不用登录每台机器，一条命令就能筛出异常节点。
直接执行 mongostat 并盯住三列关键指标
在任意能连通 mongos 的终端运行：
mongostat --host <mongos_host>:27017 1</mongos_host>
重点关注以下三列（不是全表）：
-
conn：当前活跃连接数。某台mongos的值长期比其他高 3 倍以上（比如 900 vs 200），说明流量没打散，或客户端直连了单点 -
qr（读队列）和qw（写队列）：非零且持续上升，代表请求堆积；若只有一台 shard 的qr/qw明显偏高，问题大概率在它的 primary 节点（磁盘 IO 或 CPU 卡住） -
faults/s：页错误率。> 50 表示 WiredTiger 缓存撑不住工作集，OS 开始频繁换页，内存已成瓶颈
用 --discover 自动覆盖所有节点时的注意事项
加 --discover 参数可一次性拉取整个分片集群的状态，但要注意：
- 它只发现当前在线且可连通的节点，config server 和 offline shard 不会出现在输出中
- 输出顺序不固定，建议配合
--noheaders+awk过滤，例如：mongostat --host快速抓出高连接数节点:27017 --discover 1 --noheaders | awk '$2 > 500 {print $1,$2}' - 如果某台 shard 的
qr/qw为 0，但整体延迟高，可能是网络抖动或 mongos 路由逻辑异常，不能仅依赖该值下结论
conn 高 ≠ mongos 真的扛不住，先查 netstat
连接数高八成是客户端问题，不是 mongos 本身性能差：
- 先在 mongos 所在机器跑：
netstat -an | grep :27017 | wc -l，得到操作系统级 TCP 连接总数 - 对比
mongostat输出的conn值：
— 若netstat结果比conn大 2 倍以上：存在大量未回收的TIME_WAIT，或应用没配连接池（如 Java 驱动connectionsPerHost设为 100）
— 若两者接近但conn持续高位：检查是否误开了releaseConnectionsAfterResponse，它只影响 mongos → mongod 连接，不影响客户端建连行为
别跳过 mongotop —— mongostat 只告诉你“哪台机器忙”，mongotop 告诉你“忙在哪张表”
定位到异常 shard 后，立刻在它的 primary 上执行：
mongotop --host <shard_primary_host>:27017 1</shard_primary_host>
观察输出中 total 列占比：
- 某个集合的
total时间占整机 70% 以上，且read或write单项极高：立即查该集合的索引使用情况（db.collection.aggregate([{$indexStats:{}}])）和查询模式（db.system.profile） - 多个集合均匀占用时间，但
faults/s也高：说明工作集远超内存，得调大wiredTigerCacheSizeGB或优化数据访问局部性
真正卡住的从来不是工具输出的数字，而是你看到 qr 上升后，有没有顺手去那台 shard 上跑一次 mongotop。
