ADO.NET 为每个连接字符串维护单独的连接池组。因此,如果您有多个数据库,它们应该有自己的池,并且这些池不应相互干扰。
是否有可能某些请求需要很长时间?如果对单个数据库一次执行了足够多的请求,并且它们被延迟,那么可能只是因为打开的连接而真正到达了连接池。
要验证情况并非如此,您可以通过执行 sp_who 或运行 SQL Server Activity Monitor 来检查数据库上正在运行的内容。
您还可以查询数据库中的DMV,以查看数据库中各种程序打开了多少连接:
select
NULL as [Connections by Database],
[host_name] as [Client Machine],
DB.name as [Database],
[program_name] as [Client Program],
COUNT(*) as [Open Connections]
from sys.dm_exec_sessions s (nolock)
left join sys.dm_exec_requests r (nolock)
on r.session_id = s.session_id
left join sys.databases DB (nolock)
on DB.database_id = r.database_id
where s.session_id >= 50 -- Ignore SQL Server processes
group by [host_name], DB.name, [program_name]
order by [Client Machine], [Database], [Client Program]
如果您确实发现只需要更多连接,则可以通过将属性 Max Pool Size 设置为 100 以外的值来调整连接字符串中的限制。这里是 an example。
如果您想查看导致问题的池是什么,可以在调试堆中挖掘 .NET 对象。您必须捕获 w3wp.exe 进程的内存转储并使用 WinDbg(或可能是 Debug Diagnostics Tool)之类的工具对其进行分析。我过去曾这样做过。这不一定容易,但它可以帮助很多。
编辑
有一个perfmon counter for ADO.NET connection pooling 可用于监控泄漏连接。在性能监视器中,为 SqlServer 扩展 .NET 数据提供程序并添加计数器 NumberOfReclaimedConnections。根据文档,这个计数器意味着:
通过垃圾回收的连接数
应用程序未调用 Close 或 Dispose 的集合。
不明确关闭或处置连接会损害性能。
我们已使用此计数器来验证我们的应用程序是否正在泄漏连接。