Мы получаем утечку памяти в службе приложений Azure, на которой работает интерфейсный веб-сайт DNN, содержащий преимущественно WebForm, но также и некоторые модули MVC.
Я выполнил дамп памяти через dotMemory и обнаружил, что наибольший сохраненный размер занимает объектный тип ViewEngineCollection.
Насколько я понимаю, он должен содержать механизм просмотра Razor, а также любые другие, используемые в веб-приложении.
Я обнаружил, что вместо этого каждый экземпляр каждого объекта MVC добавляется в коллекцию как механизмы просмотра и никогда не собираются сборщиком мусора, занимая гигабайты памяти. Во время дампа памяти> 90% находились в памяти второго поколения, поэтому они долговечны.
Рассмотрим модуль MVC MyMVCModule. Допустим, в .cshtml есть тег действия, который содержит динамически сгенерированный URL-адрес - кажется, что при создании экземпляра объекта MVC компаратор объектов определяет эквивалентность с другими объектами, уже находящимися в коллекции. Любая небольшая разница в версиях одного и того же модуля приведет к тому, что он будет добавлен в память как «новый» механизм. Я считаю, что это функция кэширования, но существует так много перестановок, что затраты на хранение на порядки перевешивают затраты на повторное создание наших объектов MVC. В памяти находятся тысячи копий модуля.
Словарь является дочерним по отношению к ModuleDelegatingViewEngine, который является специфическим для dnn компонентом, поэтому я не верю, что эта проблема связана с фреймворком MVC в целом.
Это обычное поведение? Если да, могу ли я заставить сборщик мусора очистить эти страницы раньше? Спасибо за помощь.
