Утечка памяти, вызванная внедрением зависимостей. NET Core 2.2 - PullRequest
0 голосов
/ 11 июля 2020

Я разработал . NET Core (2.2) API в Visual Studio 2019 . Существует 2 настраиваемых пакета nuget, а именно Auth и Log, которые были созданы для аутентификации и ведения журнала соответственно.

Пакет Auth внутренне ссылается на пакет Log. Я использовал внедрение зависимостей в методе Configure services класса Startup.cs (services.AddScope (XXX)).

Когда служба была развернута на OpenShift, мы обнаруживаем обширную утечку памяти, при которой объем памяти продолжает расти экспоненциально и достигает предела, тем самым перезагружая модули.

Следующие подходы / решения были попытки до сих пор

  • Увеличение предела памяти в OpenShift

  • Отключение Server GarbageCollection путем установки false

  • Обновление до. NET framework3.1

  • ImplementingIDisposable и Disposing объектов, созданных в соответствующих вызовах контроллера

  • Принуждение GCCollect

  • AddSingleton вместо AddScoped

  • Используется профилировщик производительности Visual Studio для проверки, запускается ли G C. G C вызывается в локальной среде отладки.

* 1 046 * Но вместо использования пакетов, когда файлы классов Auth и Log включаются непосредственно в решение API и вызываются, утечки памяти не происходит. Цель создания их как пакетов и использования внедрения зависимостей оказывается побежденной.

Каков наилучший подход к потреблению пользовательских пакетов при внедрении зависимостей в вызывающий API и есть ли способ эффективно удалить объекты, созданные с помощью DI, без атрибуции к утечке памяти?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...