MongoDB Node驱动3.6.10超出maxPoolSize问题咨询

一、连接配置的正确性 #

在MongoDB Node驱动3.6.x版本中：

• maxPoolSize是官方推荐的连接池大小配置项，替代了旧版本的poolSize参数。
• 若同时设置poolSize和maxPoolSize，驱动会优先使用maxPoolSize，因此你设置的maxPoolSize:6是有效的，无需重复配置poolSize。

二、会话池与连接池的核心区别 #

你观察到的client.topology.s.sessionPool.sessions.length是会话池的会话数量，它和连接池（由maxPoolSize控制）不是同一概念：

• 连接池管理的是到MongoDB服务器的TCP物理连接，maxPoolSize限制的是同时存在的最大物理连接数。
• 会话池管理的是逻辑会话（用于事务、因果一致性、读偏好绑定等），会话是建立在物理连接之上的，一个物理连接可以承载多个逻辑会话（同一时间仅处理一个会话请求，请求完成后会话可被复用）。因此会话池的数量本身就可能超过maxPoolSize的数值，这并非异常。

三、会话数超出预期的常见场景 #

1. 未正确释放手动创建的会话
   若代码中手动调用client.startSession()创建会话，但未在操作完成后调用session.endSession()释放，这些会话会一直驻留在会话池中，导致数量累积。务必确保会话被正确释放，推荐用try/finally包裹：

   const session = client.startSession();
   try {
     // 执行数据库操作
   } finally {
     await session.endSession();
   }
   

2. 事务场景下的会话绑定
   当使用事务时，会话会被绑定到事务流程中，直到事务提交或中止。如果事务执行时间较长，期间新的业务请求可能创建新的会话，导致会话池数量临时增加。

3. 驱动的会话复用策略
   驱动会缓存会话以提升复用效率，在高并发场景下，为了避免等待可用会话，会临时创建更多会话，只要连接池有可用物理连接，就可以承载这些会话，这属于驱动的正常优化行为。

4. 会话未及时回收
   会话的回收存在一定延迟，当会话使用完成后，驱动不会立即从池移除，而是保留一段时间供后续请求复用，短时间内的会话数可能会高于连接池大小。

四、验证连接池是否符合配置 #

若要确认连接池是否遵守maxPoolSize限制，应查看连接池的相关指标：

• client.topology.s.pool.size：当前活跃的物理连接数
• client.topology.s.pool.maxSize：配置的最大物理连接数（应为你设置的6）

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