Нужна помощь в анализе дампа памяти ASP.Net Core 3.1

Я готов заплатить за помощь в этом !!

Мое приложение ASP.Net Core 3.1 начинается с примерно 450 МБ и постепенно увеличивается до примерно 4,5 ГБ (и я подозреваю, что оно увеличилось бы еще больше, если бы ему было доступно больше памяти).

Я делал дампы памяти на разных этапах и анализировал их с помощью dotMemory, и, похоже, показал, что JsonSerialiserOptions - это главный подозреваемый:

наибольший сохраненный размер

При переходе к JsonSerializerOptions показаны 3 экземпляра. Два имеют незначительные числа, и если я продолжу углубляться в один из трех с наибольшим использованием памяти, его Путь хранения ключей показывает следующее: Пути хранения ключей

И вот здесь мне нужна помощь. Я действительно не знаю, что делать с этими путями удержания. Я ожидаю, что если проблема в моем коде, я должен найти какой-то класс своего приложения в нижней части пути хранения? Мне нужна помощь, пытаясь выяснить по этим путям хранения, где в моем коде может быть проблема.


c# memory-leaks asp.net-core memory-management dotmemory
person Shawn de Wet    schedule 29.06.2020    source источник
comment
ПРЕДЛОЖЕНИЕ. Ознакомьтесь с использованием памяти MSVS диагностический инструмент   -  person FoggyDay    schedule 29.06.2020
comment
Должен признать, что я немного сбит с толку, учитывая, что dotMemory - это коммерческий продукт с огромным количеством информации о поддержке, документации, видео на YouTube, инструкциями и командой поддержки компании, поддерживающей его, почему вам нужно задавать этот вопрос таким образом (или вообще). Есть ли у вас какая-либо нераскрытая принадлежность к Jetbrains? Если вы готовы заплатить кому-либо, возможно, покупка полного продукта у jb и получение их руководства о том, как его использовать, было бы наиболее эффективным.   -  person Caius Jard    schedule 29.06.2020
comment
Это не проблема поддержки продукта dotMemory. Это общий вопрос о понимании того, что мне говорит путь удержания. Я просмотрел онлайн-документацию и примеры dotMemory. И на основе этого я добавил в свой вопрос утверждение, что если проблема в моем коде, я ожидаю увидеть один из классов моего собственного проекта в пути сохранения. Но все, что я вижу, - это классы основной библиотеки. Могу ли я поверить, что проблема в системе DI .Net Core?   -  person Shawn de Wet    schedule 29.06.2020
comment
Включите сбор информации о выделениях в dotMemory и посмотрите, какие экземпляры трассировки стека JsonSerializerOptions созданы. Он подскажет, какие объекты следует освободить или выбросить, чтобы они не оставались в памяти.   -  person Ed Pavlov    schedule 29.06.2020

Ответы (2)


arrow_upward
0
arrow_downward

Я подозреваю, что ваша проблема связана с токеном изменения перезагрузки. Об утечке памяти сообщалось еще в .NET 2.1 - для получения более подробной информации см. https://github.com/dotnet/aspnetcore/issues/6102

но

если вы ориентируетесь на более новую версию .Net, я бы рекомендовал проверить ваш метод ConfigureServices() (Startup.cs) и исключить неправильно настроенное время жизни служб и / или зависимые зависимости.

person michal krzych    schedule 01.04.2021
comment
Спасибо за ваш отзыв; это напомнило мне добавить мои выводы в качестве решения. - person Shawn de Wet; 02.04.2021

arrow_upward
0
arrow_downward

Оказывается, проблема возникла из-за ошибки, при которой гибкий, определяемый во время выполнения запрос к базе данных перенастраивал экземпляры типа Object вместо экземпляров типа dynamic. JsonSerializer правильно НЕ кэширует dynamic типов, но ДЕЙСТВИТЕЛЬНО кеширует Object типы.

Таким образом, каждый раз при выполнении запроса JsonSerializer кэшировал структуру Object. Исправление заключалось в том, чтобы запрос к базе данных возвращал dynamic типов вместо Object типов.

person Shawn de Wet    schedule 02.04.2021
comment
Тип dynamic перестает быть dynamic после компиляции, и CLR рассматривает его, как если бы это был просто object, который, как мне кажется, не имеет ничего общего с утечкой вашей памяти. Я думаю, вы на правильном пути, но, может быть, вы сделали выводы слишком рано? :) - person michal krzych; 02.04.2021
comment
Нет, это изменение определенно устранило мою утечку памяти. - person Shawn de Wet; 06.04.2021