У нас есть производственное приложение ASP.NET Core 2.1, которое иногда (от одного раза в день до каждых двух или трех дней) зависает и больше не обслуживает запрос.Это приводит к 502 ошибкам от IIS, который размещен впереди.Похоже, что только вариант заставить все работать снова, перезапускает приложение.
При проверке дампа памяти с помощью WinDbg мы заметили, что почти все наши потоки (мы выдвинули минимальное количество потоков Threadpool) имеют довольно маленький стектрассировки и застряли в WaitForSingleObject, а не где-то в нашем коде приложения.Вывод был сгенерирован с помощью команды WinDbg !mex.us.
16352 threads [stats]: 27 29 37 38 39 40 41 42 43 44 ...
00007ff898d85b84 ntdll!NtWaitForSingleObject+0x14
00007ff895e93eef KERNELBASE!WaitForSingleObjectEx+0x8f
00007ff885a1826a clr!CLRSemaphore::Wait+0x8a
00007ff885a190cf clr!ThreadpoolMgr::UnfairSemaphore::Wait+0x115
00007ff885a1927f clr!ThreadpoolMgr::WorkerThreadStart+0x28b
00007ff885ac5abf clr!Thread::intermediateThreadProc+0x86
00007ff8982f84d4 kernel32!BaseThreadInitThunk+0x14
00007ff898d4e851 ntdll!RtlUserThreadStart+0x21
. Эти потоки активно ждут, когда произойдут другие события, или они закончили свою работу и просто находятся в режиме ожидания, ожидая новых действий?
Если первое предположение верно (что объясняет зависание приложения), почему трассировка стека не указывает на исходный вызов, которого они ждут?