.NET Core 3.1 MobileApi连接池耗尽致崩溃问题排查求助

1. 连接池耗尽的核心：别先急着调池大小，先找连接泄漏 #

连接池超时本质是连接没被正确释放，不是池太小。默认Max Pool Size是100，除非你的并发请求远超这个数，否则先排查泄漏：

• 检查所有DbContext的使用是不是都用了using语句，确保用完就释放（EF Core的DbContext是轻量对象，每次请求应该新建实例并及时销毁）
• 别在单例服务里注入DbContext，这会导致连接被长期占着不放
• 可以执行SQL Server的sys.dm_exec_connections查询，查看当前活跃连接的状态，定位哪些连接长时间未释放

2. 现有连接检查逻辑要谨慎 #

你配置里复用现有连接的逻辑存在风险：

• 复用同一个DbConnection时，如果这个连接被未完成的事务、未关闭的DataReader占用，后续请求会一直等待，直接加剧池耗尽问题
• 而且你复用连接时只启用了1次重试，直接用连接字符串的配置却没加重试，配置不一致。除非是跨库事务必须共享连接，否则建议移除现有连接检查的逻辑，让EF Core自动管理连接池：
  修改后的配置可简化为：

  Configuration.Modules.AbpEfCore().AddDbContext<MobileDbContext>(options =>
  {
      DbContextConfigurer.Configure(options.DbContextOptions, options.ConnectionString);
  });
  

  同时统一重试配置，给两个Configure方法都加上重试：

  public static void Configure(DbContextOptionsBuilder<MobileDbContext> builder, string connectionString)
  {
      builder.UseSqlServer(connectionString, options => options.EnableRetryOnFailure(3));
  }
  
  public static void Configure(DbContextOptionsBuilder<MobileDbContext> builder, DbConnection connection)
  {
      builder.UseSqlServer(connection, options => options.EnableRetryOnFailure(3));
  }
  

3. 关于增大Max Pool Size #

只有确认没有连接泄漏，且并发请求确实超过默认100时，再考虑调大。但要注意：

• 池大小过大会加重SQL Server的负载，Azure VM上的SQL有资源上限，盲目调大可能导致数据库性能下降
• 真要调整的话，在连接字符串中添加Max Pool Size=200;（根据实际并发情况调整），但这只是临时缓解方案，不是根本解决办法

4. 网络异常的关联处理 #

“网络名称不可用”的COM异常说明两台Azure VM之间的网络存在不稳定情况，这会导致连接未被正确回收（比如客户端断开但连接池仍认为连接可用）：

• 检查两台VM的网络配置，确保处于同一个虚拟网络，或者网络连通性稳定
• 在连接字符串中添加Connect Timeout=15;（调整超时时间），配合前面的重试配置，让EF Core在网络波动时自动重试连接

额外建议 #

• 给MobileDb的批量操作添加事务，确保批量更新主库时的原子性，避免连接长时间被占用
• 用Application Insights或SQL Profiler监控连接池状态（比如NumberOfActiveConnections、NumberOfPooledConnections），实时掌握连接使用情况

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