Mongo 4.0.3小结果集下SHARD_MERGE阶段耗时远高于其他环节问题排查

核心排查方向 #

• 首先确认查询是否包含全局运算逻辑
  如果查询带有sort、distinct、非分片键分组、非分片键精确计数这类需要全局运算的操作，即使单分片返回数据量极小，运算逻辑也无法下推到分片层，需要mongos统一处理：
  • 排序场景：检查排序字段是否为分片键前缀，非分片键排序需要mongos做全局排序，哪怕仅百级条数据，也会因为mongos资源不足、同实例其他高负载查询抢占资源导致耗时暴涨
  • 去重/分组场景：确认去重、分组字段是否为分片键，非分片键的去重、分组需要mongos对全量返回结果做二次运算，也会引发高耗时
• 排查mongos实例运行状态
  SHARD_MERGE阶段的所有运算都在mongos侧执行，高耗时首先排查mongos的资源占用：
  • 检查查询执行时刻mongos的CPU、内存、磁盘IO、网络带宽占用，确认是否有其他大查询、批量写入操作抢占资源
  • 拉取mongos对应时间点的日志，检查是否存在分片节点连接超时、心跳异常、慢请求告警，mongos和分片节点的通信异常会被统计到SHARD_MERGE耗时中，并非合并运算本身的耗时
• 验证分片到mongos的传输链路状态
  你观测到的250ms是分片本身的查询执行耗时，不包含结果从分片传输到mongos的耗时：
  • 用ping、mtr工具检测mongos到两个分片节点的网络延迟、丢包率，若存在100ms以上的持续延迟或丢包，TCP重传会大幅拉长结果接收总耗时
  • 确认返回的单条记录大小：如果每条记录包含大文本、二进制字段，即使仅返回59条，总数据量也可能达到数百MB，序列化、反序列化、传输都会消耗大量时间，需确认覆盖索引是否真的排除了所有大字段
• 排查版本已知问题
  部分旧版本MongoDB存在SHARD_MERGE阶段的性能缺陷：比如5.0.0~5.0.5版本的聚合查询合并阶段内存泄漏问题、4.4之前版本的跨分片排序性能bug，若你的集群版本属于问题版本区间，建议升级到对应大版本的最新稳定版复测

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