Утечка памяти в. NET приложении Core 3.0 при использовании NLog или Serilog - PullRequest
Новая
       5

Утечка памяти в. NET приложении Core 3.0 при использовании NLog или Serilog

2 голосов
/ 09 января 2020

У меня странная проблема с. NET Core 3.0 при использовании регистраторов.

Приложение работает нормально на Windows, но когда я запускаю его на Linux (Debian 10) в качестве демона, оно просто продолжает занимать все больше и больше памяти. Проблема впервые проявилась, когда я использовал NLog, затем я переключился на Serilog, но проблема все еще здесь. Проблема не возникает, когда я удаляю NLog / Serilog.

Используя снимки памяти и Jetbrains dotMemory, все, что я получаю, это набор массивов sbyte, которые (вероятно) создаются NLog / Serilog.

Когда я отключаю ведение журнала в файл и оставляю только консольное ведение журнала - проблема исчезает!

Я пытался добавить ручные вызовы в сборщик мусора, но это не помогло.

Нам удалось создать обходной путь добавив параметр MemoryMax в файл .service. Кажется, что сборщик мусора начинает убирать, когда он приближается к максимальному пределу. (ie ограничение составляет 150 МБ, и теперь приложение удерживает 145 МБ).

Кто-нибудь знает, что может быть не так? Или я должен просто решить эту проблему с разработчиками NLog и Serilog.

Ответы [ 2 ]

2 голосов
/ 09 января 2020

Я также заметил высокое потребление памяти. Было несколько разных вещей, в том числе:

  • с использованием .Destructure.ToMaximumCollectionCount (10) // По умолчанию int.MaxValue
  • с удалением .Enrich.WithExceptionDetails, чтобы увидеть, если проблема памяти волшебным образом исчезает
  • Проверка использования памяти файла подкачки контейнера Linux и, следовательно, установка значения Swapiness (хотя и позаботьтесь о непредвиденных последствиях)

Чтобы быть уверенным в том, где происходит утечка памяти, хотя вам нужно будет проанализировать кучу памяти, чтобы посмотреть, какие объекты используют память.

Утечка памяти SeriLog при использовании EF

0 голосов
/ 09 января 2020

NLog открывает / закрывает файл для каждой операции записи файла по умолчанию. Это обеспечивает наивысший уровень совместимости, но имеет свою стоимость.

Попробуйте настроить NLog следующим образом: 

<nlog>
   <targets>
      <target type="file" name="logfile" fileName="log.txt" keepFileOpen="true" concurrentWrites="false" />
   </targets>
   <rules>
      <logger name="*" minLevel="Debug" writeTo="logfile" />
   </rules>
</nlog>

Не используйте <targets async="true">, если проблема с выделением памяти.

NLog ver. 4.7 устраняет проблему с производительностью при использовании concurrentWrites="true" вместе с параметрами архивации NLog на не Windows -платформах. До NLog вер. 4.7 выпущен, тогда следует рассмотреть возможность настройки concurrentWrites="false", если это возможно.

См. Также: https://github.com/NLog/NLog/wiki/performance

...