如何解决间歇性SQL超时错误

Question

我们每天都有一些实例,我们从多个应用程序中获得大量SQL Timeout错误(System.Data.SqlClient.SqlException:Timeout expired.在操作完成之前已经过了超时时间,或者服务器没有响应.)我们的网络上有超过100种不同的应用程序,包括Web和桌面应用程序.从VB6和经典ASP到.NET 4的所有内容.我可以找到显示副作用的各种数据,但无法确定导致这种情况的原因.我们的DBA表示SQL服务器没有任何问题,IT部门表示Web服务器或网络没有任何问题,所以我当然试图解决这个问题.

我真的只是在寻找有关我可以做的其他故障排除的建议,以尝试跟踪此问题.

我们在群集中运行SQL Server 2008 R2.有几个不同的服务器连接到它,从Windows服务器2003到2008不同的品种.

这是我到目前为止所做的:

• 运行长时间运行的查询和死锁的SQL跟踪. 这显示在问题出现时没有死锁,长时间运行的查询都与我们的超时错误一致,但看起来是副作用,而不是原因.通常立即返回的非常基本的查询最终会花费30,60或120秒来运行.这种情况发生了几分钟,然后一切都恢复并在此之后正常工作.
• 使用性能监视器来跟踪连接池连接. 这有时会显示超时时间附近的连接数量出现一些峰值,但仍然不会达到默认的100连接限制的一半.再说一遍,这里没有什么似乎指向一个原因.
• 将Web应用程序分隔到不同的应用程序池中. 我们试图缩小我们认为可能是主要问题的应用程序(最常见的等等)并将它们放在单独的应用程序池中,但这似乎不会影响任何事情或帮助我们缩小范围.
• 监视SQL Server上的磁盘使用情况.我们已经对SQL服务器进行了一些监控,并且在发生这些超时时看不到尖峰或任何问题迹象.
• 已验证的TempDB不是问题的原因.

如果我想到我们尝试了什么,我会回来再增加更多.请让我知道接下来要解决的问题.

Answer 1

运行长时间运行的查询和死锁的SQL跟踪.这显示在问题出现时没有死锁,长时间运行的查询都与我们的超时错误一致,但看起来是副作用,而不是原因.通常立即返回的非常基本的查询最终会花费30,60或120秒来运行.这种情况发生了几分钟,然后一切都恢复并在此之后正常工作.

看起来有些查询/事务会锁定您的数据库,直到完成为止.您必须找出阻止哪些查询并在其他时间重写/运行它们以避免阻止其他进程.此时等待查询暂停.

需要深入研究的是事务日志和数据库的自动增量大小.将它们设置为固定大小而不是当前文件的百分比.如果文件越来越高,分配足够空间所需的时间最终将随着事务超时而延长.你的数据库停止了.

Answer 2

性能问题归结为CPU,IO或Lock争用.听起来你已经排除了IO.我猜CPU不是问题,因为这是一个数据库,而不是一个数字计算器.因此,这会留下锁争用.

如果您可以在查询超时时执行sp_who2,则可以使用BlkBy列追溯到持有其他人正在等待的锁.由于这种情况每天只发生几次,如果您手动运行,可能无法捕获足够的数据,因此我建议您安装一个自动系统来定期转储此输出,或者可能由应用超时异常.您还可以使用活动监视器实时查看查询响应性的降级,如同行建议的那样.

一旦找到长时间运行的查询和执行它的应用程序,您可以通过将该单个应用程序的超时减少到所有其他应用程序之下立即解决超时的多米诺骨牌(现在,它必须更长).然后,您应该检查代码以确定更好的解决方案.您可以通过在sproc中更快地提交事务来减少锁定的时间,或者使用NOLOCK或UPDLOCK等提示减少读取查询所需的锁定.

以下是关于sp_who2的更多内容:http://sqlserverplanet.com/dba/using-sp_who2/

和查询提示:http : //msdn.microsoft.com/en-us/library/ms181714.aspx http://msdn.microsoft.com/en-us/library/ms187373.aspx

Answer 3

有点远,但在实验室前一段时间,我们遇到了一个SQL Server似乎没有响应的情况,不是因为我们已经加入了CPU或我们可以在SQL Server中跟踪的任何东西,它似乎对所有测试都可操作但连接失败在一些负荷下.

问题原因是由于针对服务器的流量大意味着我们在Windows中触发了内置的Windows Syn Attack Flood Protection.令人讨厌的是,当你点击这个时,Windows服务器或SQL中没有记录消息 - 你只能看到连接失败的symtpoms - 这是因为windows在接受消息时放慢速度并让我们建立一个队列.从连接的角度来看,服务器似乎没有响应(它甚至不会确认消息到达)

http://msdn.microsoft.com/en-us/library/ee377084(v=bts.10).aspx

向下滚动到SynAttackProtect,您将看到Windows Server 2003 sp1以后的默认设置是默认启用此功能.它实际上是一种DDOS保护机制,并且缺少它触发的日志记录使得在服务器执行此操作时非常难以检测到.

在它被弄清楚之前,在MS实验室中花了3天时间.

你提到了100个conenctions,我们有一个不断连接的应用程序,运行查询然后断开连接,它没有打开连接.这意味着我们在每台机器连接上有多个线程,10台机器,每台机器多个线程,并且认为足够不同的连接被一致地制作/删除以触发防御.

你是否处于那个水平(因为它不是MS明确定义的阈值)很难说.

Answer 4

就像其他海报所建议的那样，听起来您遇到了锁争用问题。几周前，我们面临着类似的问题。但是，我们的服务器比较断断续续，通常在将DBA放到服务器上以运行sp_who2来查找问题之前就已清除。

我们最终要做的是，如果锁超过某个阈值，则实施电子邮件通知。将其放在适当的位置后，我们便能够确定正在锁定的进程，并在适当的情况下将隔离级别更改为未提交，以解决此问题。

本文提供了有关如何配置此类通知的概述。

如果事实证明是锁定，而您还没有这样做，那么建议您考虑配置基于行版本控制的隔离级别。