.NET Core连接池达最大容量致服务中断，求排查与防泄漏建议

针对你遇到的连接池满导致服务中断的问题，除了搭建性能监控，以下是具体的防连接泄漏和优化建议：

• 确保异步操作全程await
  所有EF Core的异步方法（如ToListAsync()、SaveChangesAsync()）必须搭配await使用。如果遗漏await，或用.Result、.Wait()同步调用异步方法，会阻塞线程并长时间占用数据库连接，无法及时归还到连接池。检查所有数据访问代码，避免此类错误。

• 排查长查询与未及时结束的事务

  • 用SQL Server Profiler或Extended Events捕获耗时超过阈值的查询，通过添加索引、简化逻辑、分页处理大结果集等方式优化慢查询。
  • 确保所有事务都用using包裹，操作完成后及时调用CommitAsync()或RollbackAsync()。长时间运行的未提交事务会持续占用连接，无法释放回池。

• 验证DbContext工厂的正确使用
  虽然你用using包裹上下文工厂，仍需确认：

  • 始终通过IDbContextFactory<T>.CreateDbContext()创建上下文，而非手动实例化DbContext（手动实例化若未正确释放会导致泄漏）。
  • 上下文实例为短期使用，每个请求或独立操作结束后立即释放，不要复用上下文实例。

• 谨慎调整连接池参数
  在SQL Server连接字符串中调整以下参数，但优先排查泄漏根源，避免盲目调大：

  • Max Pool Size：默认100，可根据并发量适当调整（如200），但过大可能导致SQL Server资源耗尽。
  • Connection Timeout：默认15秒，可延长至30秒，给连接池更多分配时间，但这仅为缓解手段。
  • Min Pool Size：设置最小空闲连接数，避免高并发时频繁创建新连接，需结合实际负载调整。

• 检查AWS负载均衡的会话设置
  若AWS ALB开启了粘性会话，可能导致请求集中到部分后端实例，使这些实例的连接池先耗尽。检查粘性会话时长是否合理，若业务允许，可关闭粘性会话，让负载更均匀地分发到所有实例。

• 用EF Core诊断工具追踪连接使用
  开启EF Core的连接操作日志，定位未正确释放连接的操作：

  // Program.cs中配置日志筛选
  builder.Logging.AddFilter("Microsoft.EntityFrameworkCore.Database.Connection", LogLevel.Debug);
  

  同时可通过SQL Server的sys.dm_exec_connections视图查询活跃连接，查看连接的创建时间、所属进程，找出长期占用的连接。

• 排查第三方数据访问组件
  若项目中使用了EF Core之外的数据库访问组件（如Dapper、SqlConnection），必须确保这些连接也用using包裹，避免泄漏。示例：

  using var connection = new SqlConnection(connectionString);
  await connection.OpenAsync();
  // 执行数据库操作
  

• 临时缓解：设置应用池定期回收
  在IIS或AWS Beanstalk的应用池设置中，配置定期回收（如每2小时一次）。这能在泄漏未彻底解决前，避免连接池持续耗尽导致服务中断，但仅为治标手段，仍需定位泄漏根源。

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