使用 SQL Server Profiler 识别超时原因

Question

我们在两个应用程序（一个 ASP.Net 和一个 WinForms）SQL Server 应用程序上遇到看似随机的超时。我让 SQL Profiler 在一个小时内运行，以查看可能导致问题的原因。然后我隔离了超时发生的时间。

有大量的读取，但发生超时错误时和不发生超时错误时的读取没有很大差异。在此期间几乎没有写入（主要是因为每个人都超时而无法写入）。

示例：超时发生在 11:37。平均每分钟有 1500 个事务导致超时，大约有 5709219 次读取。

这似乎很高，除了在超时之间的一段时间（超过十分钟），每分钟有同样多的事务，读取也一样高。读取在超时前会出现一点峰值（跃升至超过 6005708），但在非超时期间，它们高达 8251468。超时在两个应用程序中都发生。

这里更大的问题是，这只是在过去一周才开始发生，并且该应用程序已经启动并运行了几年。所以是的，Profiler 为我们提供了大量数据，但当前的问题是超时。

我应该在 Profiler 中寻找其他什么东西，还是应该移到服务器上的性能监视器（或其他工具）？

一个可能的罪魁祸首可能是数据库大小。数据库相当大 (>200 GB)，但 AutoGrow 设置设为 1MB。可能是 SQL Server 正在调整自己的大小并且该事务没有在探查器中显示自己？

非常感谢

Answer 1

感谢这里的帮助，我能够识别一些瓶颈，但我想概述我的流程，以帮助任何人解决这个问题。

1. 第一个问题是从 SQLDiag 和其他工具中发现大量 LOCK_MK_S 条目。

2. 在两个不同的时间段运行跟踪分析器。通过比较类似方法的持续时间，我发现某些 UPDATE 调用总是花费相同的时间，超过 10 秒。

进一步调查发现这些 UPDATE 存储过程正在使用触发器更新表，该触发器花费了太多时间。由于触发器可能会在完成时锁定表，因此它会影响所有其他查询。（请参阅评论部分 - 我错误地指出触发器将始终锁定表 - 在我们的例子中，触发器阻止了锁被释放）

观看使用触发器进行重大更新。