我之前维护MongoDB 4.x集群时也碰到过一模一样的问题——明明已经调大了maxSessions参数，结果还是报会话数超限，节点照样崩溃。结合你的情况，咱们一步步拆解问题和解决方案：

核心问题：maxSessions的隐性限制 #

你可能不知道，MongoDB 4.0.x中maxSessions不是想设多大就多大的，它有一个硬性上限：maxSessions不能超过maxConns的10倍。默认情况下maxConns是100000，所以哪怕你把maxSessions设成2000000，实际生效的还是1000000（100000*10），这就是为什么你确认参数生效了，但节点还是会触发超限错误。

分步解决方案 #

1. 同步调整maxConns和maxSessions #

要让maxSessions真正生效到2000000，必须先把maxConns调到至少200000。修改每个数据节点的配置文件（注意是所有副本集的数据节点，包括主从）：

setParameter:
  maxConns: 200000
  maxSessions: 2000000

修改完成后，逐个重启数据节点（副本集可以滚动重启，避免服务中断）。重启后再用命令确认参数：

db.adminCommand( { getParameter: 1, "maxSessions": 1, "maxConns": 1 } )

这次应该能看到两个参数都符合你的配置了。

2. 加快过期会话的清理速度 #

默认的逻辑会话超时时间是30分钟，如果你的会话创建速度很快，过期会话堆积也会导致总数超限。可以把超时时间调短，让MongoDB更快回收无效会话：

setParameter:
  logicalSessionTimeoutMinutes: 10  # 改成10分钟，可根据业务情况调整

这个参数支持在线修改（无需重启节点）：

db.adminCommand( { setParameter: 1, logicalSessionTimeoutMinutes: 10 } )

3. 临时清理现有会话（应急操作） #

如果当前节点已经濒临崩溃，可以在低峰期手动清理所有会话（注意：这会中断所有当前连接，要提前通知业务方）：

db.adminCommand( { killAllSessions: [] } )

执行后再查询activeSessionsCount，数值应该会大幅下降。

4. 排查应用端的连接泄漏（根源修复） #

调大参数只是治标，真正的问题大概率在应用端：

• 检查MongoDB驱动的连接池配置：是不是连接池设置过大，或者没有正确复用连接？
• 排查是否有连接泄漏：比如代码中创建了连接但没有关闭，或者框架层面的连接管理有问题？
• 可以用db.serverStatus().connections查看当前的连接数，对比maxConns，如果接近上限，说明连接池配置有问题。

额外建议：升级MongoDB版本 #

MongoDB 4.0.x已经停止官方支持了，后续不会有任何bug修复和安全更新。更高版本（比如4.4、5.0）在逻辑会话管理上做了不少优化：

• 更高效的会话清理机制
• 取消了maxSessions和maxConns的10倍限制
• 新增了会话监控的更多指标
  如果业务允许，建议尽快升级到受支持的版本。

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