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