Nopcommerce报错Timeout expired：SQL Server迁移至虚拟机后连接池超时

报错翻译如下：

InvalidOperationException: 超时已过期。在从连接池获取连接之前已超出等待时限。该异常通常因所有池化连接都处于占用状态、且已达到连接池最大上限触发。

1. 连接泄露排查（占该类问题的90%以上，盲目调大max pool size无法解决） #

• 检查是否存在自定义业务代码未主动释放数据库连接的问题：所有SqlConnection、EF DbContext实例必须包裹在using代码块中，或在使用完成后主动调用Dispose()方法回收，遗漏释放会导致连接被长期占用直到GC被动回收
• 排查慢查询与SQL阻塞：在SQL Server实例中执行存储过程sp_who2查看所有活跃连接，确认是否存在BlkBy列非空的阻塞会话、CPUTime/DiskIO数值异常过高的慢查询，慢查询会导致连接长时间不释放，短时间内占满连接池
• 确认连接字符串配置是否合理：不要混淆Connect Timeout（连接建立超时，默认15秒）和Command Timeout（SQL执行超时，默认30秒），虚拟机跨节点访问SQL如果存在网络抖动，可将Connect Timeout适当调整为20~30秒

2. 虚拟机与SQL Server配置排查 #

• 在Nopcommerce所在虚拟机上直接用SSMS或telnet <SQL服务IP> 1433测试连通性，确认网络无丢包、端口无限制、访问延迟正常
• 检查SQL Server实例的最大并发连接数限制：默认配置为0（无上限），如果被手动修改为较小数值，即使应用侧连接池调得再大也会被实例侧限制，查看路径：SSMS右键数据库实例→属性→连接→最大并发连接数，确认配置为0
• 检查SQL Server侧的防火墙、TCP/IP协议配置，确认放通了虚拟机的访问IP，没有针对IP的限流、访问频率限制策略

3. 临时应急方案 #

• 线上业务受影响时，可先回收Nopcommerce站点对应的应用程序池，主动释放所有已占用的池化连接，先恢复业务再逐步排查根因
• 不建议无限制调大max pool size：连接池默认上限100，正常情况下足以支撑万级并发请求，若调整到200以上仍触发该报错，一定是存在连接泄露或底层配置问题，继续调大只会加剧SQL Server的性能负担

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