ASP.NET Web应用程序死锁 - 认为它是由SQL Server锁定引起的

ila*_*sno 6 sql-server asp.net crash deadlock

我们客户的网络应用程序会以随机间隔突然重启.对于每次重启,我们在Windows事件日志中找到了这样的条目:

Event Type: Warning
Event Source: W3SVC-WP
Event Category: None
Event ID: 2262
Date: 2/21/2010
Time: 1:33:52 PM
User: N/A
Computer: LIQUID-NXCFZ9DJ
Description:
ISAPI 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.
Run Code Online (Sandbox Code Playgroud)

这种情况在3周内发生了10次,其中有几次在几个小时内发生了2到3次,并且在没有发生这种情况的情况下持续了一周.

在崩溃转储中,我们可能有70-80个客户端连接,如下所示:

GET request for   <path here>
Mapped To URL    <mapped path>
HTTP Version    HTTP/1.1
SSL Request    False
Time alive    00:55:24
QueryString    <query string here>
Request mapped to    
HTTP Request State    HTR_READING_CLIENT_REQUEST
Native Request State    NREQ_STATE_PROCESS
Run Code Online (Sandbox Code Playgroud)

(这是55分钟!!!没有理由客户端连接应该在那么久)

machine.config中的相关条目:

<system.net>
<connectionManagement>
<add address="*" maxconnection="200" />
</connectionManagement>
</system.net>
Run Code Online (Sandbox Code Playgroud)

和(内):

<deployment retail="true" />
<!--<customErrors mode="Off"/>-->

<processModel autoConfig="true"
memoryLimit="60"
maxIoThreads="200"
minIoThreads="30"
minWorkerThreads="40"
maxWorkerThreads="200"
clientConnectedCheck="00:00:05" />
<httpRuntime
minFreeThreads="20"
minLocalRequestFreeThreads="10"
enableKernelOutputCache="false"
maxRequestLength="10240" />
Run Code Online (Sandbox Code Playgroud)

最近一次,我们能够查看它发生的情况,并在Sql Server中看到大约20个查询都处于"挂起"状态.看起来它们可能都与一个表有关(Items表,一个非常重要的用于许多不同的操作).

我们不确定最好的办法是在问题的中间.崩溃发生时,Sql Server清除.

任何有关正在发生的事情的指导,或如何找出正在发生的事情,都将非常感激.

Rem*_*anu 4

如果是死锁,则意味着死锁有一个在 SQL 外部完成的循环。这意味着您试图在持有 SQL 资源(即事务)的同时获取进程资源(即 C#“锁”)。举例说明这种情况是如何发生的,请考虑以下场景:

  1. T1启动一个SQL事务并在SQL中更新表A
  2. T2 在 C# 中锁定一个对象
  3. T1 尝试在 C# 中锁定同一个对象,但阻塞了 T2 的锁
  4. T2 从 SQL 表 A 读取,阻止 T1 的更新
  5. T1 在进程内等待 T2,T2 在 SQL 内等待 T1,无法检测到的死锁

这种情况无法在 SQL 的死锁监控内部检测到,因为死锁循环是在 SQL 外部完成的。您如何诊断这样的问题?对于循环的 SQL Server 端,您可以使用许多强大的工具,主要是sys.dm_exec_requests,它可以告诉您哪些请求被哪些请求阻止。但不幸的是,在循环的应用程序大小方面,没有开箱即用的工具,因此您只能靠自己了。经验丰富的眼睛可以通过代码检查发现问题(在持有 C# 锁的同时执行 SQL 调用或在 SQL 事务中间获取 C# 锁是一个很大的缺陷),否则您必须使用一些熟练的WinDbg -fu,或者检测代码。

您还应该考虑到这根本不是僵局。您的 20 个 SQL 请求可能会因应用程序中的普通代码缺陷而被阻止,例如某些请求上的事务泄漏(即,请求等待阻止它们提交的事务,但该事务已在代码中泄漏,并且永远不会被阻止)。关闭)。再说一次,sys.dm_exec_requests 是你的朋友。