SQL连接突增致超时：.NET EF6+Azure SQL间歇性故障排查求助

这种间歇性的连接池耗尽问题真的让人头疼——尤其是之前稳定运行多年、流量还完全正常的情况下，排查起来特别挠头。结合你描述的细节（大量sleeping连接、跨多台VM、自动恢复），我整理了几个方向，你可以逐一排查：

你提到用StructureMap的Nested Containers注入DbContext，理论上嵌套容器应该在请求结束时自动释放资源，但某些场景下可能出现容器未正确Dispose的情况：

• 排查方向：
  • 检查StructureMap的配置，确保Nested Container是严格绑定到每个请求生命周期的，并且在请求结束时（比如通过ActionFilter的OnActionExecuted或者Global.asax的EndRequest事件）明确调用容器的Dispose()方法。异步请求场景下更要注意，嵌套容器的生命周期是否和异步上下文同步。
  • 用SQL查询统计各应用账户的连接数：

    SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NumberOfConnections, loginame as LoginName 
    FROM sys.sysprocesses 
    WHERE dbid > 0 
    GROUP BY dbid, loginame
    

    结合各VM的应用日志，确认是不是某类特定请求的DbContext没被及时释放。
  • 可以临时做个测试：把嵌套容器的DbContext替换为PerRequest模式，看看故障是否消失（这是临时验证手段，不是长期解决方案）。

EF6默认会在DbContext Dispose时释放连接，但如果存在未正确处理的异步操作或事务，可能导致连接占用时间变长，甚至无法回到池里：

• 排查方向：
  • 核对连接字符串的配置：有没有最近修改过Max Pool Size（默认100）、Connection Timeout参数？如果流量稳定但连接持有时间突然变长，哪怕池大小不变也可能耗尽。可以临时调大Max Pool Size到200测试，但这只是缓解手段，要找到根本原因。
  • 跟踪EF6的DbContext创建/Dispose时机：开启EF6的日志功能，或者用SQL Server的Extended Events，排查是否存在Dispose不及时的情况。尤其是异步方法，必须确保所有EF操作都被正确await，避免出现“提前Dispose DbContext但异步查询还在运行”的情况。
  • 检查TransactionScope的使用：如果有嵌套事务或者未正确Complete()/Dispose()的TransactionScope，会导致连接被长期占用。

你提到Azure指标的峰值和故障时间不匹配，但有些后端问题不会直接体现在“成功连接数”上，反而会间接导致应用端连接池耗尽：

• 排查方向：
  • 检查所有VM的连接字符串是否完全一致：哪怕是细微差异（比如参数大小写、额外的冗余参数）都会创建独立的连接池，导致每个池的可用连接数被分散，最终出现“总连接数够但单个池耗尽”的情况。
  • 查看Azure SQL的等待统计：在Azure Portal的SQL数据库→性能→查询存储→等待统计中，检查故障时间段是否有LCK_M_*（锁等待）、PAGEIOLATCH_*（IO等待）或RESOURCE_SEMAPHORE（内存等待）的突增——这些会导致连接持有时间变长，进而占满连接池。
  • 测试修改连接字符串参数：比如添加MultipleActiveResultSets=False（默认是False，但如果被误改会有影响），或者把Connect Timeout调整为30，观察是否有改善。

你排查了代码变更，但基础设施或第三方工具的变更也可能触发这类问题：

• 排查方向：
  • 检查Azure VM的最近更新记录：故障开始前几天有没有.NET Framework补丁、OS系统更新？某些补丁可能影响连接池的行为。
  • 暂停新增的监控/APM工具：如果最近10天部署了New Relic、Application Insights这类工具，它们的 instrumentation 可能拦截DbContext或SQL连接，导致释放延迟。暂停后观察故障是否消失。
  • 检查后台定时任务：有没有新增或修改的定时任务在故障时间段运行？比如批量数据处理任务突然占用大量连接。

你看到的大量status=sleeping, cmd=AWAITING COMMAND连接，很大概率是连接上挂着未提交的事务，导致连接无法回到池里：

• 排查方向：
  • 用SQL查询关联的未提交事务：

    SELECT * FROM sys.dm_tran_session_transactions
    

    找到对应sleeping连接的session id，再用DBCC INPUTBUFFER(session_id)查看最后执行的SQL，定位到代码中的对应逻辑。
  • 检查事务处理代码：有没有地方用了BeginTransaction但没在try-catch中确保回滚？比如：

    using (var ctx = new MyDbContext())
    {
        var tran = ctx.Database.BeginTransaction();
        try
        {
            // 业务操作
            tran.Commit();
        }
        catch
        {
            // 这里如果遗漏Rollback，事务会一直挂着
            tran.Rollback();
            throw;
        }
    }
    

  • 排查Database.UseTransaction的使用：如果手动绑定外部事务到DbContext，却没正确管理事务生命周期，也会导致连接被占用。

• 用Windows的perfmon监控应用端的计数器：SQL Server: General Statistics -> User Connections、.NET Data Provider for SQL Server -> Connection Pool Hit Ratio、Connection Pool Wait Time，故障时观察这些指标的变化。
• 用Azure Application Insights跟踪每个请求的DbContext创建/Dispose次数，以及连接池等待时间，定位异常请求。

内容的提问来源于stack exchange，提问作者Jarrich Van de Voorde