.NET多节点环境下SQL连接池如何扩容及解决耗尽问题

问题场景 #

我的.NET 6应用通过Dapper执行SQL调用，每个请求大概发起6次调用，单次调用耗时0-10ms，SQL Azure的使用率最高仅5%。但当机器人在300毫秒内发起50+并发请求时，会触发连接池耗尽错误。

现有代码示例 #

var connection = new SqlConnection("constring");

using (connection)
{
    await connection.OpenAsync();
    var command = new SqlCommand("sql");
    await command.ExecuteAsync();
    await connection.CloseAsync();
    connection.Dispose();
}

报错信息 #

InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached

当前环境配置 #

• 连接字符串设置最大池大小为250
• 部署在3节点Azure App Service上
• 所有调用均为async异步实现
• 因SignalR需求开启了ARR Affinity，但推测机器人请求无ARR Cookie，负载均衡会分散流量
• 流量高峰时，App Service和SQL Server均未达到负载上限

核心问题 #

需要理解SQL连接池的工作原理，解决连接池耗尽问题，同时消除日志噪音。虽然高峰后连接池会快速恢复，不影响人类用户，但频繁报错需要解决。

SQL连接池核心原理 #

SQL Server连接池是进程级资源，每个App Service节点作为独立进程，拥有自己的连接池，因此3个节点的总连接池上限是250*3=750。其核心逻辑：

• 调用OpenAsync时，优先从池内获取可用连接，无可用连接则新建，直到达到Max Pool Size
• 调用Close或Dispose时，连接不会真正关闭，而是放回连接池等待复用
• 若连接长时间被占用，或新建连接速度超过池内连接释放速度，就会触发连接获取超时

解决步骤 #

1. 修复代码中的连接管理错误 #

现有代码存在两处关键问题，是连接池耗尽的主要诱因：

• SqlCommand未关联到打开的SqlConnection，导致命令无法正常执行，同时连接被无意义占用
• 手动调用CloseAsync和Dispose属于冗余操作，using块会自动处理连接的释放与回收

修正后的代码（原生SqlClient）：

using var connection = new SqlConnection("constring");
await connection.OpenAsync();
// 必须将命令关联到当前连接
var command = new SqlCommand("sql", connection); 
await command.ExecuteAsync();
// 无需手动关闭/释放，using块会自动将连接放回池

如果使用Dapper（推荐），代码可进一步简化：

using var connection = new SqlConnection("constring");
// Dapper会自动处理连接的打开/释放
await connection.ExecuteAsync("sql");

2. 优化SQL调用逻辑 #

每个请求6次独立SQL调用会频繁占用连接池资源，可通过以下方式优化：

• 合并多SQL操作：使用Dapper的QueryMultiple或批量执行语句，用单个连接完成多个操作，减少连接池的请求次数
• 避免不必要的连接打开：确保只在需要执行SQL时打开连接，执行完成后立即释放

3. 调整连接池配置 #

• 确认连接字符串的Pooling=true（默认开启，无需额外配置）
• 若单节点并发请求确实较高，可适当提高Max Pool Size（比如调到300），但需注意SQL Azure的总连接上限（避免触发SQL端的连接限制）
• 调整Connection Timeout：默认15秒，若只是短暂高峰，可适当调小（比如3秒），让请求快速失败而不是长时间等待；若需要应对持续高峰，可调大到30秒

4. 监控连接池状态 #

通过Application Insights或Azure Monitor监控以下指标，定位连接池瓶颈：

• SqlClient:ConnectionsPooled：池内维护的连接数
• SqlClient:ConnectionsOpened：新建的连接数
• SqlClient:ConnectionsClosed：放回池的连接数
• SQL Azure端的Active Connections指标，确认是否真的达到了池上限

5. 优化负载均衡与扩容策略 #

• 临时关闭ARR Affinity测试：机器人请求无ARR Cookie，关闭后可让负载更均匀，避免单节点并发过高
• 配置App Service自动扩容：根据CPU或请求数阈值自动增加节点，分散每个节点的连接池压力
• 若机器人请求量持续较高，可考虑单独部署一套服务处理机器人流量，隔离连接池资源

6. 排查连接泄漏 #

若以上操作后问题仍存在，需排查是否存在连接泄漏：

• 检查所有SQL调用是否都使用using块包裹SqlConnection
• 确认异步操作都正确使用await，避免因未等待导致连接长时间占用
• 使用Visual Studio诊断工具或Application Insights快照，查看是否存在未释放的SqlConnection对象

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