Заведение в тупик веб-приложения ASP.NET - думает, что вызывается блокировкой SQL Server

Веб-приложение нашего клиента перезапускает внезапно наугад интервалы. Для каждого перезапуска мы нашли запись как это в Windows Event Log:

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'.

Это произошло 10 раз за 3 недели, несколько из тех, которые 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

(это составляет 55 минут!!! нет никакой причины, которой соединение клиента должно быть вокруг этого долго),

Соответствующие записи в machine.config:

<system.net>
<connectionManagement>
<add address="*" maxconnection="200" />
</connectionManagement>
</system.net>

и (внутри):

<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" />

Это последнее время мы смогли посмотреть на него, как это происходило, и занялся 20 запросами все в 'приостановленном' состоянии в SQL-сервере. Было похоже, что они, возможно, были все связаны с одной таблицей (таблица Items, очень центральная для большого количества различных операций).

Мы не были уверены, чем лучшей вещью сделать был посреди проблемы. Когда катастрофический отказ произошел, убранный SQL-сервер.

Любое руководство на том, что продолжается, или как узнать то, что продолжается, очень ценилось бы.

6
задан Joel Coehoorn 6 March 2010 в 01:40
поделиться

2 ответа

Если это тупик, это означает, что тупик имеет цикл, который завершается вне SQL. Это означает, что вы пытаетесь получить ресурсы процесса (т. Е. «Блокировку» C #), удерживая ресурсы SQL (т. Е. Транзакцию). В качестве примера, как это может произойти, рассмотрим следующий сценарий:

  1. T1 запускает транзакцию SQL и обновляет таблицу A в SQL
  2. T2 блокирует объект в C #
  3. T1 пытается заблокировать тот же объект в C #, блоки на блокировке T2
  4. T2 читает из таблицы SQL A, блоки при обновлении T1
  5. T1 ожидает T2 внутри вашего процесса, T2 ожидает T1 внутри SQL, необнаруживаемая взаимоблокировка

Подобные ситуации не могут быть обнаружены внутри тупика SQL мониторинг, поскольку цикл взаимоблокировки завершается вне SQL. Как бы вы диагностировали такую ​​проблему? Что касается SQL-сервера, в вашем распоряжении имеется множество мощных инструментов, в первую очередь sys.dm_exec_requests , который может сказать вам, какие запросы блокируются чем. Но, к сожалению, для размера цикла приложения нет готовых инструментов, так что вы сами по себе. Опытный глаз может обнаружить проблему при проверке кода (выполнение вызовов SQL при удерживании блокировок C # или получение блокировок C # в середине транзакций SQL - большая скидка), в противном случае вам придется либо мастерски потренироваться WinDbg -fu, или инструментируйте код.

Вы также должны учитывать, что это вовсе не тупик. Вы можете заблокировать 20 запросов SQL из-за обычного дефекта кода в вашем приложении, например, из-за утечки транзакции по определенным запросам (т. Е. Запросы ждут транзакции, которая блокирует их фиксацию, но эта транзакция просочилась в код и никогда не будет закрыто). Опять же, sys.dm_exec_requests - ваш друг.

4
ответ дан 17 December 2019 в 04:45
поделиться

Проверьте запущенные процессы на сервере SQL с помощью монитора активности.

ОБНОВЛЕНИЕ: я видел, что эта конкретная ошибка, вероятно, не связана с SQL. Я нашел эту статью о том, как получить дополнительную информацию о тупике: http://support.microsoft.com/?ID=828222

1
ответ дан 17 December 2019 в 04:45
поделиться
Другие вопросы по тегам:

Похожие вопросы: