w3wp зависает - возможно заблокированные потоки? Попытка отладки с помощью WinDbg

w3wp зависает - возможно заблокированные потоки? Попытка отладки с помощью WinDbg

У меня были проблемы на прошлой неделе, когда одно из моих веб-приложений, работающих на IIS, зависало в случайные моменты времени по крайней мере раз в день, мне приходилось перезапускать пул приложений, чтобы вернуть его к жизни. Процессор и память кажутся нормальными.

Когда я смотрю на активные потоки в разделе рабочих процессов в диспетчере IIS, я вижу, что потоки накапливаются, как будто они застряли. Когда процесс зависает, там находится около 25+ потоков, а когда все работает нормально, в любой момент времени их может быть от 3 до 6.

Я предполагаю, что это могло быть связано с изменением кода в моем веб-приложении C#, но я не могу понять, где и что это. Насколько я помню, было внесено всего несколько незначительных изменений.

На прошлой неделе я действительно усердно пытался провести диагностику с помощью нескольких инструментов, таких как WinDbg и dotTrace, чтобы посмотреть, смогу ли я отследить что-то очевидное, но на данном этапе я немного запутался.

Я вижу, что есть много потоков с ошибками тайм-аута, подключающихся к моей базе данных NoSql (RavenDb), однако я думаю, что это отвлекающий маневр и что это связано с тем, что потоки заблокированы в IIS, поскольку я могу без проблем подключиться к той же базе данных из другого приложения IIS, а также использовать инструменты управления базами данных для управления базой данных/запроса к ней.

У меня есть мини-дампы и снимки dotTrace, с которыми можно поиграться.

Вот результаты "~*e !clrstack" в WinDbg: https://gist.github.com/phinett/7901d82fa526696d3c92

Есть ли помощь/идеи о том, на что мне следует обратить внимание, чтобы отследить виновника? Я с радостью предоставлю доступ к минидампам, если это необходимо.

Спасибо!

решение1

Вероятно, гораздо проще и быстрее начать с DebugDiag v2 update 1 и принудительно создать дамп процесса, а затем запустить анализ зависания.

Связанный контент