排查ASP.NET Core连接SQL Azure时的间歇性性能卡顿问题

遇到这种间歇性的卡顿确实头疼，尤其是已经排除了CPU飙升、数据库阻塞这些常见问题之后。结合你描述的现象——只有涉及数据库调用的接口变慢，本地直连生产DB却完全正常，大概率是Web应用侧和数据库连接相关的环节出了问题，给你几个具体的排查方向：

• 监控数据库连接池状态
  EF Core默认依赖ADO.NET的连接池，一旦连接池耗尽或者出现连接泄漏，就会导致请求等待获取数据库连接而卡顿。你可以在应用里添加连接池状态的监控：

  • 用Microsoft.Extensions.Diagnostics.HealthChecks注册SQL连接池的健康检查，实时监控连接池的活跃连接数、空闲连接数；
  • 或者在关键接口中通过性能计数器获取连接池数据，记录到SEQ中，比如：

    using System.Diagnostics;
    
    var connectionPoolCounter = new PerformanceCounter(
        ".NET Data Provider for SqlServer",
        "NumberOfActiveConnections",
        "YourConnectionStringAlias" // 对应配置文件里的连接字符串名称
    );
    var activeConnections = connectionPoolCounter.NextValue();
    // 将activeConnections记录到SEQ日志
    

  卡顿发生时重点看连接池是不是被占满，有没有连接无法及时归还的情况。

• 检查EF Core的DbContext使用方式
  不正确的DbContext生命周期管理很容易导致连接泄漏：

  • 先确认Program.cs里DbContext的注册方式，确保是默认的Scoped生命周期（AddDbContext<YourDbContext>(...)），如果误注册成Singleton，会导致单个连接被长期占用，甚至引发线程安全问题；
  • 检查所有手动创建DbContext的地方，必须用using语句包裹，确保连接能及时归还到池里，比如：

    // 错误示例：未释放DbContext，连接无法及时归还
    var db = new YourDbContext();
    var data = db.Entities.ToList();
    
    // 正确做法
    using var db = new YourDbContext();
    var data = db.Entities.ToList();
    

• 排查Azure Web App的网络层面问题
  虽然本地直连生产DB正常，但Web App所在的Azure环境可能存在临时网络波动或DNS解析异常：

  • 去Azure Portal的Web App控制台，查看“网络”模块的日志，或者启用Application Insights的依赖跟踪，重点看卡顿期间SQL依赖的响应时间、连接成功率；
  • 确认Web App和SQL Azure是否在同一区域，跨区域部署可能带来更高的网络延迟波动。

• 查看SQL Azure的连接相关指标
  登录Azure Portal的SQL Database面板，重点查看这些指标：

  • 筛选“连接数”“连接等待时间”“登录数”，看卡顿时间段有没有异常峰值；
  • 检查“活动日志”，确认卡顿期间有没有后台维护操作（比如副本同步、索引重建），Business Critical tier虽然高可用，但偶尔的后台操作也可能影响连接性能。

• 细化EF Core的数据库操作日志
  现在你知道是DB调用卡顿，但需要明确是连接建立慢还是查询执行慢：
  在Program.cs中开启EF Core的数据库命令日志，记录每个操作的详细耗时：

  builder.Logging.AddFilter("Microsoft.EntityFrameworkCore.Database.Command", LogLevel.Information);
  

  这样SEQ里会输出每个SQL命令的执行时间，如果是连接建立阶段耗时过长，那问题大概率在连接池或网络；如果是查询执行慢，但本地执行正常，那可能是Azure环境的查询计划异常（可以尝试强制重新生成查询计划）。

• 检查Web App的进程内资源瓶颈
  虽然CPU没跑满，但内存不足或线程池耗尽也可能导致DB请求卡顿：

  • 启用Web App的“诊断日志”，查看卡顿期间的GC日志、线程池状态；
  • 用Application Insights的“性能”面板，监控卡顿时间段的内存使用率、线程数变化，确认有没有资源耗尽的情况。

按照这些方向排查，应该能定位到问题所在。尤其是连接池和DbContext的生命周期管理，是这类间歇性卡顿的常见诱因。

备注：内容来源于stack exchange，提问作者Chris Kooken