Веб-приложение нашего клиента перезапускает внезапно наугад интервалы. Для каждого перезапуска мы нашли запись как это в 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-сервер.
Любое руководство на том, что продолжается, или как узнать то, что продолжается, очень ценилось бы.
Если это тупик, это означает, что тупик имеет цикл, который завершается вне SQL. Это означает, что вы пытаетесь получить ресурсы процесса (т. Е. «Блокировку» C #), удерживая ресурсы SQL (т. Е. Транзакцию). В качестве примера, как это может произойти, рассмотрим следующий сценарий:
Подобные ситуации не могут быть обнаружены внутри тупика SQL мониторинг, поскольку цикл взаимоблокировки завершается вне SQL. Как бы вы диагностировали такую проблему? Что касается SQL-сервера, в вашем распоряжении имеется множество мощных инструментов, в первую очередь sys.dm_exec_requests , который может сказать вам, какие запросы блокируются чем. Но, к сожалению, для размера цикла приложения нет готовых инструментов, так что вы сами по себе. Опытный глаз может обнаружить проблему при проверке кода (выполнение вызовов SQL при удерживании блокировок C # или получение блокировок C # в середине транзакций SQL - большая скидка), в противном случае вам придется либо мастерски потренироваться WinDbg -fu, или инструментируйте код.
Вы также должны учитывать, что это вовсе не тупик. Вы можете заблокировать 20 запросов SQL из-за обычного дефекта кода в вашем приложении, например, из-за утечки транзакции по определенным запросам (т. Е. Запросы ждут транзакции, которая блокирует их фиксацию, но эта транзакция просочилась в код и никогда не будет закрыто). Опять же, sys.dm_exec_requests - ваш друг.
Проверьте запущенные процессы на сервере SQL с помощью монитора активности.
ОБНОВЛЕНИЕ: я видел, что эта конкретная ошибка, вероятно, не связана с SQL. Я нашел эту статью о том, как получить дополнительную информацию о тупике: http://support.microsoft.com/?ID=828222