(还在MSDN论坛http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/79058c06-d3c5-4073-8571-c29d1f43f7ae上发布)
大家好,
我们有一套5在线拍卖系统运行在Windows和SQL上。每个系统由一个网络工作者和一个或多个web角色组成。每个系统都使用ASP.NET MVC 3和实体框架、仓库模式和StructureMap。
工作人员角色负责家务管理,并运行两组流程。一组每十秒钟跑一次,另一组每秒钟跑一次。每个进程可能运行一个数据库查询或存储过程。这些都是由Quartz.net安排的
web角色为公共接口和后台办公室服务。除了其他基本的crud功能之外,这两种功能都提供屏幕,当打开时,这些屏幕将反复调用控制器方法,这将导致存储过程只读查询的执行。重复的频率约为2-3秒每个客户端.一个典型的用例是,5个后台窗口打开,25个终端用户窗口打开--所有这些都会反复击中系统。
很长一段时间以来,我们一直在经历间歇性SQL超时错误。其中最常见的三个是:
System.Data.SqlClient.SqlException:从服务器接收结果时发生了传输级错误.(provider: TCP Provider,error: 0-现有连接被远程主机强制关闭。)
System.Data.SqlClient.SqlException:从服务器接收结果时发生了传输级错误.(提供者: TCP提供程序,错误:0-信号量超时期已经过期。)
System.Data.SqlClient.SqlException:超时过期。在操作完成或服务器没有响应之前经过的超时时间。
唯一可预测的场景是在拍卖期间,一个特定的控制器-> sproc在事件期间开始超时(大概是由于负载)。所有其他时间,这些错误似乎是完全随机的,出现在单打、两次和三次等情况下,甚至在用户不活动期间也是如此。例如,系统将持续18个小时而没有错误,然后可能是来自不同内务管理方法的5-10个错误,或者可能是用户登录并查看了他们的帐户。
其他信息:
我尝试使用本地SSMS和基于Azure web的查询工具在SQL上运行受影响的查询/sprocs-所有这些看起来都执行得很快,最多1秒。虽然我不是SQL查询性能专家,也不是J方面的任何其他专家,但查询计划并没有显示出任何可疑之处。
我们已经将所有受影响的区域封装在Azure瞬态故障处理块中--但是正如这里所讨论的,http://social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/7a50985d-92c2-472f-9464-a6591efec4b3不会捕获超时,而且根据“Valery M”,这是有充分理由的。
虽然asp.net成员资格信息存储在数据库中,但我们不会在数据库中存储任何会话信息。
我们使用一个“SQL服务器实例”,它承载了所有5个数据库,两个用于暂存,三个用于生产。所有5个系统通常同时处于活动状态,尽管在任何给定时间都不太可能有超过一个系统处于动态负载使用状态。所有web角色、工作角色和SQL服务器都位于相同的Azure地理区域。
对我们应该去哪有什么想法吗?它能帮助每个系统都拥有自己的SQL服务器吗?自己找不到解决方案--能不能让微软打开一张支持票,看看我们的应用程序是怎么回事?
提前谢谢。
宜兰
发布于 2013-06-19 13:52:23
这种情况下,你的连接被迫关闭,通常是一个节流的迹象。我发现,节流的主要原因是数据库中有大量未处理的请求。不幸的是,没有硬性限制可以监测,以确定何时发生这种节流。好消息是,下限是记录在案,这意味着您可以跟踪何时接近上限。
为了给我们的科特加监测服务提供一个插件,这是我们跟踪允许人们在接近这些上限时得到通知的主要事情之一。当发生这种情况时,另一件有用的事情是执行深度数据库诊断,以查看数据库中发生了哪些昂贵的查询、连接等,就像在如何执行SQL性能& SQL的诊断分析上描述的那样。
https://dba.stackexchange.com/questions/19693
复制相似问题