增加Web服务器核心后出现ASP.NET最大连接池大小错误

昨晚将Web服务器CPU从4核升级到8核，目的是加速某API的下载流程，该API确实提速明显，但同一服务器上的另一个API开始抛出错误：

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.

查看SQL Server的开放连接数，发现连接数缓慢攀升至100（期间仅少量连接被关闭），一旦达到100，该API就返回上述超时错误。

这两个API在4核服务器上稳定运行了3年（仅速度偏慢），为何升级到8核后出现此问题？

另外已定位到潜在问题：存在DataReader未关闭导致的连接泄漏（请求结束返回响应时，DataReader未被关闭），但为什么核数减半时没触发这个问题？

目前只有重启IIS应用池才能临时消除错误。

• 核心数提升放大了连接泄漏的影响
  IIS的线程池默认会根据CPU核数调整最大线程数（比如默认设置为每核100个工作线程），4核时线程池上限更低，并发处理的请求数有限，连接泄漏的速度慢，连接池的回收机制（如SQL Server端的连接超时回收）还能跟上消耗速度，不会很快耗尽默认100的连接池上限。升级到8核后，线程池上限提升，并发请求量大幅增加，连接泄漏的速度超过了回收速度，短时间内就占满了连接池，触发超时错误。

• DataReader未关闭的连接占用机制
  当DataReader未被正确关闭（未使用using块包裹，或未手动调用Close()/Dispose()），对应的数据库连接会被持续占用，无法回到连接池复用。4核时，服务器同时处理的请求少，同一时间被泄漏的连接数不多，连接池还有足够的空闲连接供新请求使用；8核后并发请求激增，被泄漏的连接数快速累积，很快达到连接池默认的100上限，新请求拿不到连接就会超时。

• 重启IIS应用池的作用
  重启应用池会销毁当前所有的应用线程，强制释放所有未关闭的DataReader和对应的数据库连接，SQL Server会回收这些占用的连接，连接池被重置为空，所以错误会暂时消失。但只要连接泄漏的代码问题没修复，随着请求处理，连接会再次被持续泄漏，很快又会触发相同的错误。

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