MongoDB 4.2.8报TooManyLogicalSessions错误 会话数异常问题排查

数值差异的核心成因 #

你观察到的会话数和当前操作数的巨大差值，本质是对MongoDB逻辑会话机制的误解：

• config.system.sessions 集合存储的是所有未达到TTL过期阈值的会话元数据，和当前正在执行的操作没有绑定关系。只要驱动创建了会话、没有主动释放、且没到默认15分钟的过期TTL，这条记录就会一直留在磁盘上
• 内存里的activeSessionsCount才是当前节点实际加载的活跃会话数，你看到的2244和db.currentOp(true).inprog.length统计的2911属于同一量级，不存在数值倒挂
• 报错里提到的maxSession默认100万的限制，是节点内存会话缓存的上限，不是config.system.sessions集合的存储上限，因此哪怕磁盘上存了几十万条历史记录，只要内存缓存没达到阈值，本来就不该触发拒绝新建会话的报错。

本次报错的核心异常定位 #

对照你提供的logicalSessionRecordCache统计值，两个关键指标完全不符合正常运行特征：

• lastSessionsCollectionJobEntriesRefreshed 为0
• lastSessionsCollectionJobEntriesEnded 为0
  这是定位问题的核心线索。正常状态下，MongoDB后台会每5分钟执行一轮会话清理任务：把内存中过期的会话状态同步到磁盘、删除config.system.sessions里过期的历史记录。如果连续多轮清理任务的刷新、结束条目数都是0，只有两种可能：

1. 会话清理的后台任务出现阻塞、完全卡死
2. 所有驱动新建的会话都被标记为长期活跃，没有正常触发过期逻辑

这种情况下哪怕表面看到的活跃会话数只有2000多，实际缓存里的待处理会话条目已经在任务卡死后持续累积到了配置的上限。当新的查询尝试触发新建会话逻辑时就会被拒绝，也就出现了30%-40%概率随机触发报错的现象——已有会话的查询正常执行，只有走到新建会话分支的请求会被拦截。
你观察到的config.system.sessions记录数在1.1万到56万之间大幅波动，本质就是后台清理时删一批、驱动新建连接写一批，因为清理任务效率极低，所以波动幅度过大。

分步排查与解决操作 #

• 临时救急：立即触发全量会话清理
  在副本集主节点执行如下命令，强制清空内存中的会话缓存，同时触发一轮全量的config.system.sessions清理，删除所有超过TTL阈值的历史会话：

  db.adminCommand({ refreshSessions: [] })
  

  执行完成后通常能快速降低报错的触发率。
• 验证后台任务恢复状态
  间隔5分钟连续3次拉取serverStatus返回的logicalSessionRecordCache字段，跟踪指标变化：
  • 如果sessionsCollectionJobCount持续增长，且lastSessionsCollectionJobEntriesRefreshed、lastSessionsCollectionJobEntriesEnded从0变为非0值，说明之前只是清理任务临时卡死，等后台跑2-3轮全量清理后就会完全恢复
  • 如果任务计数一直不增长、对应指标始终为0，说明清理任务已经彻底阻塞，需要滚动重启副本集节点（先将主节点降为从节点，重启完成后重新触发选主完成切换，再处理剩余节点）释放后台任务的阻塞。
• 排查驱动侧的会话泄漏根源
  全量清理后如果还是快速攒起大量会话，说明驱动侧的会话复用机制存在失效问题：
  • 检查所有接入服务的连接池配置，是否存在连接超时时间设置过长、连接回收逻辑缺失的问题，导致连接不释放时对应的会话也无法被回收
  • 排查是否存在应用层批量创建无连接池的临时MongoClient的行为，这类临时连接每次都会新建独立会话、用完不关闭，会快速累积会话记录
  • 你当前使用的pymongo 3.6版本存在已知的会话泄漏问题，即使部分客户端升到3.11，如果存在版本混用也会持续出现会话不回收的问题，建议将所有pymongo客户端统一升级到3.12以上的稳定版本。
• 临时降低会话累积速度
  如果短期内无法定位泄漏源，可以动态调整maxSessions参数，从默认的100万降到10000，给后台清理任务留够处理缓冲，避免快速攒到上限导致大规模拒绝请求。这个参数不需要重启节点，直接动态调整即可：

  db.adminCommand({ setParameter: 1, maxSessions: 10000 })
  

  等后台清理把历史攒的会话消化完，再根据实际会话量逐步把参数调整到合理区间。

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