我有一个托管我的网站的服务器几乎没有流量.
一些人(<20)每天进入该网站,一些RSS阅读器订阅了我们推出的一些提要.
几乎每天晚上,一个RSS阅读器都会在半夜打电话给我们,并且由于连接中的超时而导致网站无法连接到SQL Server.细节非常奇怪,所以我正在寻找一些可能出现问题的帮助,因为我不知道从哪里开始寻找.
我们在Windows Server 2008上使用ASP.Net MVC,实体框架和SQL Server 2008.这台机器是我们从一个不完全顶级的提供商那里获得的专用盒子,所以事情可能是非最佳配置,或者谁知道什么其他.
盒子也很小,只有1Gb的RAM,但它应该承担我们现在的那种负载......
我正在复制下面的完整调用堆栈,但首先,我们知道的一些事情:
- 当iTunes查询我们的网站时,总会发生错误.我相信这应该与任何事情无关,但事实是我们只能从iTunes获得它.我最好的猜测是,这种情况发生是因为只有iTunes在当晚没有其他人打我们的时候询问我们.
- 我们的一个理论是,SQL Server和IIS正在为内存而战,其中一个是从未被使用中被分页到磁盘,当有人"唤醒它"时,从磁盘上读取所有内容需要很长时间进入记忆.这有可能发生吗？(我有点丢弃这个,因为如果可能的话,它听起来像SQL Server中的设计问题)
- 我还想到了我们泄漏连接的可能性,因为我们可能没有适当地处理EF实体(请参阅我的问题).这是我通过谷歌搜索问题找到的唯一一件事.鉴于我们的负载极低,我正在抛弃这一点.
- 这总是发生在整个晚上,所以这很可能与一段时间没有发生任何事情有关.例如,我很确定当这些请求命中时,Web服务器进程被回收并且它正在启动/重新监视所有内容.但是,重新JITting并没有解释SQL超时.
更新:我们按照建议添加了一个分析器,在我们遇到新的异常之前花了很长时间.这是我们所知道的新内容:
- 将探查器附加到极大地减少了我们得到的错误数量.事实上,通常在每天几次之后,我们不得不等待3或4天才能发生这种情况.一旦我们停止了探查器,它就会恢复到正常的错误频率(甚至更糟).因此,探查器有一定的效果可以在某种程度上隐藏这个问题,但并不完全.
- 查看IIS请求日志旁边的探查器跟踪,请求和查询之间存在预期的1-1对应关系.但是,我偶尔会看到很多正在执行的查询与IIS日志完全无关.实际上,就在记录实际错误之前,我在3分钟内得到了750个查询,所有查询都与IIS日志完全无关.查询文本看起来像EF生成的那种不可读的废话,并且它们并不完全相同,它们看起来就像来自网站的查询:相同的ApplicationName,User等.想一想这多么荒谬是的,该网站在2天的过程中获得了大约370个IIS请求
- 这些无法解释的查询并非来自与之前网站相同的ClientProcessID,尽管它们可能仍然来自网站,如果此过程在此期间被回收.在最后解释的查询与第一个无法解释的查询之间有近一个小时没有活动.
- 在我记录错误之前,我不知道它们来自哪里的长条查询之一就出现了,所以我相信这是我们应该遵循的线索.
- 正如我原先预期的那样,当执行抛出错误的查询时,它来自与前一个不同的ClientProcessID(比前一个无法解释的一个晚了8分钟,几乎比前一个IIS快一个小时).对我来说,这意味着工人流程确实得到了回收.
- 这是我绝对不明白的事情.IIS日志显示错误请求前一分钟,4完全服务,尽管这些查询根本没有显示在跟踪中.事实上,在那些顺利完成的4个之后,我有4个例外快速连续抛出,这4个也没有显示在跟踪中(这是有道理的,因为如果有连接超时,查询应该从未执行过,但我没有看到跟踪中的连接尝试)
所以,简而言之,我对这一点完全无能为力.我无法找到那些快速连续运行的数百个查询的原因,但我相信这些问题必须与问题有关.
我也不知道如何诊断连接问题...
或者如果Profiler跟踪可能会丢失一些根据IIS进行的查询...
有任何想法吗？
这是例外信息:
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
System.Data.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior …
Run Code Online (Sandbox Code Playgroud)