ADO.NET会为每个连接字符串维护单独的连接池组。所以,如果您有多个数据库,它们应该有自己的池,并且这些池不应相互干扰。
是否有可能某些请求花费了很长时间?如果针对单个数据库执行了足够多的请求,并且它们被延迟了,那么也许连接池确实因为打开的连接而被使用完了。
为了验证这一点,您可以通过执行sp_who
或运行SQL Server 活动监视器来检查数据库上正在运行的内容。
您还可以查询数据库中的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
group by [host_name], DB.name, [program_name]
order by [Client Machine], [Database], [Client Program]
如果您发现只需要更多的连接,可以通过将属性Max Pool Size设置为100以外的值来调整连接字符串中的限制。这里是
一个示例。
如果您想查看是哪个池导致了问题,可以在调试堆栈中深入挖掘.NET对象。您需要捕获w3wp.exe进程的内存转储,并使用WinDbg(或可能是
Debug Diagnostics Tool)等工具进行分析。我过去做过这个。这并不一定容易,但可以大有帮助。
编辑
有一个
用于监视ADO.NET连接池泄漏的perfmon计数器。在性能监视器中,展开.NET Data Provider for SqlServer并添加NumberOfReclaimedConnections计数器。根据文档,此计数器表示:
通过垃圾回收重新获取的连接数,由于应用程序未调用Close或Dispose而被回收。未显式关闭或处理连接会影响性能。
我们使用此计数器来验证我们的应用程序是否存在连接泄漏问题。