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

存在大量读取但是在发生超时错误时和不发生超时错误时读取没有大的差异.在此期间几乎没有写入(主要是因为每个人都有时间超时且不能写).

例：
超时发生在11:37.在超时之前,平均每分钟有1500笔交易,大约有5709219条读数.

这似乎很高,除了在超时(超过十分钟的跨度)之间的时间段内,每分钟的事务数量和读数一样多.读取在超时前跳跃一点(跳到6005708以上),但在非超时期间,它们会高达8251468.两个应用程序都会发生超时.

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

在Profiler中我是否应该寻找其他东西,还是应该在服务器上移动到性能监视器(或其他工具)？

一个可能的罪魁祸首可能是数据库大小.数据库相当大(> 200 GB),但AutoGrow设置设置为1MB.可能是SQL Server正在调整自身大小并且该事务不会在探查器中显示出来吗？

非常感谢

最佳答案 感谢这里的帮助,我能够找出一些瓶颈,但我想概述我的过程,可能有助于任何人经历这个.

>发现#1问题是从SQLDiag和其他工具中找到的大量LOCK_MK_S条目.
>在两个不同的时间段内运行Trace Profiler.比较类似方法的持续时间使我发现某些UPDATE调用总是花费相同的时间,超过10秒.

进一步的调查发现,这些UPDATE存储过程正在用一个占用太多时间的触发器来更新表.由于触发器可能会在完成时锁定表,因此它会影响其他所有查询. (请参阅注释部分 – 我错误地指出触发器将始终锁定表 – 在我们的示例中,触发器阻止锁被释放)

观察使用触发器进行重大更新.