Приложение ASP.NET - внезапные проблемы с процессором и памятью - PullRequest
Новая
       109

Приложение ASP.NET - внезапные проблемы с процессором и памятью

0 голосов
/ 21 декабря 2018

У меня есть приложение .NET Framework 4 ASP.NET (в сочетании WebForms и MVC), которое существует уже несколько лет.За последние несколько месяцев приложение внезапно перестало отвечать, и пул приложений начал использовать 99% ЦП и 3 ГБ (!) ОЗУ.Это происходит примерно раз в 2 недели, хотя сегодня это происходит дважды.

Обычно мы убиваем процесс и перезапускаем работающий пул приложений, однако теперь мы взяли дампы, используя DebugDiag, чтобы попытаться добраться до сутиэтот.Однако я не могу понять, в чем проблема - главная причина в том, что кажется, что сборщик мусора либо работает, либо находится в необычном состоянии - '! Dumpheap' дает мне следующее 

The garbage collector data structures are not in a valid state for traversal.
It is either in the "plan phase," where objects are being moved around, 
or we are at the initialization or shutdown of the gc heap. Commands related 
to displaying, finding or traversing objects as well as gc heap segments may 
not work properly. !dumpheap and !verifyheap may incorrectly complain of 
heap consistency errors.

Address       MT     Size Object <exec cmd="!ListNearObj /d
01ef1000">01ef1000</exec> has an invalid method table.

Iя запустил ~ * e! clrstack и получил много выходных данных, причем почти в каждом потоке было показано «System.Threading.Monitor.ReliableEnter» ... это нормально?

Мне просто интересно, знает ли кто-нибудьчто-нибудь на основании вышеизложенного, или есть какие-либо советы по анализу этого файла дампа?Дамп является полным дампом, поэтому он занимает около 3 ГБ

. Я вставил свой вывод clrstack ниже, только если кто-нибудь захочет посмотреть!

https://pastebin.com/dBE5VAYJ

1 Ответ

0 голосов
/ 21 декабря 2018

Я бы сказал: в состоянии, когда вы захватили дамп, процесс находится в середине сборки мусора.Структуры объектов повреждены, и вы не сможете анализировать объекты, поэтому будет сложно увидеть, что использует память.

Использовать Procdump и настроить его на аварийное завершение.дамп на основе размера виртуальной памяти, например, 2 ГБ, если ваше приложение обычно использует только 1 ГБ.Это должен быть ключ командной строки -m.

Надеемся, что длительный процесс сборки мусора еще не начался, и вы сможете просматривать объекты в памяти с помощью !dumpheap -stat или импортировать аварийную выгрузкув Jetbrains dotMemory для анализа.

Еще одно наблюдение в ваших стеках вызовов.Есть 26 GetBuildResultFromCacheInternal().Я думаю, что это свидетельствует о том, что приложение находится в процессе переработки.

...