sp_reset_connection花很长时间执行的可能原因是什么？

sp_reset_connection从SQL Server Profiler看，为什么系统存储过程要花几毫秒的时间来执行？

我从使用SQL Server Profiler的生产系统中进行了简单的跟踪，然后使用SqlNexus对其进行了分析。SqlNexus指示sp_reset_connection具有最高的累积持续时间-占总跟踪的33％。观察到的持续时间为0-7秒（12到6,833,270微秒），但平均为0.956s。

我了解到池连接被重用时会调用sp_reset_connection。我已经看到有人暗示这可能是由于无关的痕迹而发生的，但事实并非如此。

我读过了 了调用sproc时服务器在做什么，但是我不认为在这种情况下任何问题都会出现-代码不会留下未清除的开放式事务或庞大的临时表。

我也看着 /server/199974/sp-reset-connection-taking-a-long-time-to-run，但这没有帮助。

编辑（2013-12-23）： 在所有情况下，读和写均为0，CPU几乎始终为0（仅两个实例，两个非零CPU都在16ms处）。

终于有时间写出更详细的答案。

一个简单的过程通常sp_reset_connection需要花费很长时间才能运行，通常有三个主要原因。

1. 您正在等待CPU资源
2. 您被锁定在某个地方的锁上（可能是DML或竞争性交易的结果）
3. 您的网络速度很慢，需要很长时间才能将结果返回给客户端

广告1）如果您正在等待CPU资源，这应该显示为信号等待。请查看我对您的问题的评论，该问题如何诊断是否是问题所在

广告2）如果您正在等待锁，最好通过比较的两个快照来诊断sys.dm_os_wait_stats。请参阅此文章，了解如何执行此操作：

• http://www.sqlsoldier.com/wp/sqlserver/sqludbaweekbeanficientdba

如果看到长时间等待LCK_ [Something]，请查询 sys.dm_tran_locks以锁定哪些对象。对于您的情况，我希望看到某种形式的SCH- [Something]>锁会阻止您。

广告3）诊断网络问题的最简单方法是首先查找OLEDB和ASYNC_NETWORK_IO，然后在步骤2中等待（如果您等待很长的时间，则会显示其中之一）。如果等待xperf -on latency时间太长，请使用诸如netmon或wireshark的网络监视程序来检查您的延迟。如果网络看起来很慢，也可能是由于调用应用程序服务器对回收的连接没有足够快的响应所致。

我刚刚看到一个知识库文章，其中涉及一个可能与此问题有关的错误。在FIX：当SQL Server中的数据库锁定活动增加时，会出现性能问题（KB 2926217），所描述的症状之一是sp_reset_connection可能需要很长时间才能完成。该修补程序包含在以下更新中：

• SQL Server 2008 SP3的累积更新17
• SQL Server 2008 R2 SP2的累积更新13
• SQL Server 2012 SP1的累积更新9
• SQL Server 2014的累积更新1

我观察到此行为的服务器运行的是带有累积更新5的SQL Server 2008 SP3，因此很可能遇到了此错误。我还没有尝试过累积更新（问题不会一直出现），因此我无法验证它是否可以解决此问题。但是，我想提供信息以防任何人有相同的症状。