回收IIS应用池为何能解决.NET SqlConnection超时问题？

核心判断：连接池嫌疑的验证 #

你的情况高度指向连接池异常——回收应用池会清空该服务器的连接池，问题立即消失，说明池内存在无效/阻塞的连接，导致新请求无法获取可用连接或使用了有问题的连接。

1. 实时排查连接状态 #

• 在SQL Server执行以下查询，查看来自Web集群的连接情况：

  SELECT 
      c.session_id,
      s.login_name,
      c.connect_time,
      s.status,
      s.last_request_end_time,
      c.client_net_address,
      s.program_name
  FROM sys.dm_exec_connections c
  JOIN sys.dm_exec_sessions s ON c.session_id = s.session_id
  WHERE s.program_name LIKE '%你的Web应用标识%' -- 替换为实际应用名
  ORDER BY c.connect_time DESC;
  

  重点看是否有大量sleeping状态的连接，且last_request_end_time停留在很久之前，这类连接可能未正确释放回池。

• 查看数据库阻塞情况：

  SELECT 
      blocking_session_id,
      session_id,
      wait_type,
      wait_time,
      command
  FROM sys.dm_exec_requests
  WHERE blocking_session_id <> 0;
  

  如果存在长期阻塞的会话，会导致后续请求排队超时。

2. 监控Web服务器连接池指标 #

用Windows性能计数器（PerfMon）跟踪以下.NET Data Provider for SQL Server指标：

• NumberOfPooledConnections：池内总连接数
• NumberOfActiveConnections：活跃连接数
• NumberOfFreeConnections：空闲连接数
  如果NumberOfFreeConnections持续为0，且NumberOfPooledConnections达到默认上限100，说明连接池耗尽，新请求会等待至超时。

可能的问题根源与修复建议 #

1. 隐性连接泄漏排查 #

虽然你的代码用using包裹了连接，但需检查其他代码路径：

• 是否有异步操作中未等待OpenAsync/ExecuteNonQueryAsync，导致连接未及时释放回池？
• 是否有SqlDataReader未正确关闭？若使用ExecuteReader未指定CommandBehavior.CloseConnection，即使连接在using块中，也可能延迟释放。

2. 连接池配置优化 #

• 调整连接字符串的Max Pool Size：如果并发请求超过默认100，可适当调高（如200），但需确保SQL Server的max_connections（默认32767）足够支撑。
• 添加Connection Lifetime=300：设置连接在池中的最长存活时间（单位秒），让池定期回收旧连接，避免无效连接积累。
• 确认Pooling=true（默认启用），确保连接池功能正常。

3. 存储过程执行异常修复 #

即使SP已优化，仍需排查参数嗅探问题：

• 某些参数可能导致SP生成低效执行计划，可在SP末尾添加OPTION (RECOMPILE)强制重新生成执行计划：

  CREATE PROCEDURE ActionsSP
      @pTimestamp DATETIME,
      @pDomain VARCHAR(50),
      @pOperationId INT,
      @pResultId INT,
      @sError VARCHAR(1024) OUTPUT
  AS
  BEGIN
      -- 原有业务逻辑
      OPTION (RECOMPILE);
  END
  

• 用SSMS的「包括实际执行计划」验证所有参数组合下的SP性能，确保无遗漏的性能瓶颈。

4. 临时缓解与长期监控 #

• 临时：捕获到超时异常时，可调用SqlConnection.ClearAllPools()清空连接池，但需谨慎使用——会中断所有当前连接，仅用于紧急情况。
• 长期：
  • 配置性能计数器告警：当NumberOfFreeConnections持续低于5或NumberOfPooledConnections接近上限时触发告警，提前发现问题。
  • 启用SQL Server扩展事件（Extended Events）跟踪连接超时事件，定位具体请求和会话。

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