Приложение ASP.NET MVC из памяти - System.Web.dll загружается в appdomain для каждого запроса

Question

У меня есть приложение ASP.NET MVC (последнее), которое выходит из памяти после ок. 1000 звонков. Я использовал различные профайлеры памяти, как это:

1. сделать несколько звонков
2. собирать свалка 1
3. делают больше звонков
4. собирать самосвалы 2
5. сравнить отвалы для проверки наличия новых объектов

Странно, что в diff существует абсолютно 0 прикладных объектов. Единственными созданными объектами являются системные, например. System.Web.Hosting.AspNetHostExecutionContextManager, System.Web.Hosting.ApplicationManager + AspNetAppDomainManager + AspNetAppDomainManagerImpl`2 [[System.Web.Hosting.AspNetHostExecutionContextManager, System.Web], также содержит строки, байт [], междоменную поддержку и некоторые локализация, но два выше занимает много результатов в выводе DumpHeap в WinDbg.

Число пропущенных объектов для каждого разницы дампов явно связано с количеством вызовов, например. 50 объектов каждого типа, а также для некоторых типов его 100 (50x2) объектов.

Профилировщик памяти, который я использовал, делает GC перед взятием дампа, а также я попытался выполнить GC вручную для каждого вызова, без изменений.

В состоянии OOM обрабатываемый процесс занимает около 450 МБ памяти, поэтому он не такой большой.

Я подозреваю, что это как-то связано с асинхронными запросами, потому что я вижу утечки объектов, таких как CrossDomainAppSink.

Другая подсказка, что WinDbg (как и Fusion) показывает, что это

CLR:(C:\Windows\Microsoft.Net\assembly\GAC_32\System.Web 
\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.dll) 
Rejecting native image because it failed the security check. 
The assembly's permissions must have changed since the time 
it was ngenned, or it is running with a different security context. 

для каждого запроса, кажется. Поэтому я предполагаю, что у меня есть OOM, потому что в приложении есть целая система сборки System.Web. Контрольная точка настроек для AspNetHostExecutionContextManager устанавливает LOT точек останова внутри каждого из этих модулей. Этого не происходит для других сборок.

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

Answer 1

Наконец-то я обнаружил утечку - это было не разгружено AppDomain (оно было создано в конструкторе, а затем сразу же воссоздано). Случайно сборка, загруженная в AppDomain, содержала ссылку на System.Web.dll, и поэтому у меня были эти связанные с веб-объектами объекты в памяти.

Трассировка стека распределения была полезной в этом случае.