Отладка утечки памяти в .NET Core

Эта статья относится к: ✔️ пакету SDK для .NET Core 3.1 и более поздних версий

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

В этом учебнике демонстрируются средства для анализа утечки памяти в приложении .NET Core с помощью средств CLI для диагностики .NET. Если вы используете Windows, для отладки утечек памяти можно использовать средства диагностики памяти Visual Studio.

Здесь используется пример приложения, в котором намеренно происходит утечка памяти. Пример предоставляется для выполнения упражнения. Вы можете проанализировать приложение, в котором также непреднамеренно происходит утечка памяти.

В этом руководстве рассмотрены следующие задачи:

  • Изучение использования управляемой памяти с помощью dotnet-counters.
  • Создание файла дампа.
  • Анализ использования памяти с помощью файла дампа.

Предварительные требования

В этом учебнике используется:

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

Изучение использования управляемой памяти

Перед началом сбора данных диагностики с целью поиска основной причины, которая привела к данному сценарию, необходимо убедиться в наличии утечки памяти (или ее увеличения). Для этого используйте dotnet-counters.

Откройте окно консоли и перейдите к каталогу, в который вы скачали и распаковали пример целевого объекта отладки. Запустите целевой объект:

dotnet run

В отдельном окне консоли найдите идентификатор процесса:

dotnet-counters ps

Результат должен выглядеть следующим образом:

4807 DiagnosticScena /home/user/git/samples/core/diagnostics/DiagnosticScenarios/bin/Debug/netcoreapp3.0/DiagnosticScenarios

Теперь проверьте использование управляемой памяти с помощью инструмента dotnet-counters. --refresh-interval задает время между обновлениями (в секундах):

dotnet-counters monitor --refresh-interval 1 -p 4807

Динамические выходные данные должны выглядеть следующим образом:

Press p to pause, r to resume, q to quit.
    Status: Running

[System.Runtime]
    # of Assemblies Loaded                           118
    % Time in GC (since last GC)                       0
    Allocation Rate (Bytes / sec)                 37,896
    CPU Usage (%)                                      0
    Exceptions / sec                                   0
    GC Heap Size (MB)                                  4
    Gen 0 GC / sec                                     0
    Gen 0 Size (B)                                     0
    Gen 1 GC / sec                                     0
    Gen 1 Size (B)                                     0
    Gen 2 GC / sec                                     0
    Gen 2 Size (B)                                     0
    LOH Size (B)                                       0
    Monitor Lock Contention Count / sec                0
    Number of Active Timers                            1
    ThreadPool Completed Work Items / sec             10
    ThreadPool Queue Length                            0
    ThreadPool Threads Count                           1
    Working Set (MB)                                  83

Рассмотрите подробнее эту строку:

    GC Heap Size (MB)                                  4

Как видите, сразу после запуска объем управляемой динамической памяти составляет 4 МБ.

Теперь перейдите по URL-адресу https://localhost:5001/api/diagscenario/memleak/20000.

Обратите внимание, что объем использования памяти увеличился до 30 МБ.

    GC Heap Size (MB)                                 30

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

Создание дампа памяти

При анализе возможных утечек памяти необходимо получить доступ к динамической памяти приложения. Затем можно анализировать содержимое памяти. Изучив связи между объектами, можно делать предположения о том, почему область памяти не освобождается. Общий источник диагностических данных — это дамп памяти в Windows или эквивалентный основной дамп в Linux. Чтобы создать дамп приложения .NET Core, воспользуйтесь инструментом dotnet-dump.

Выполните приведенную ниже команду, чтобы создать основной дамп в Linux для предварительно запущенного примера целевого объекта отладки:

dotnet-dump collect -p 4807

В результате в той же папке будет создан основной дамп.

Writing minidump with heap to ./core_20190430_185145
Complete

Перезапуск неисправного процесса

После сбора дампа у вас должно быть достаточно данных для диагностики неисправного процесса. Если неисправный процесс запущен на рабочем сервере, это удачный момент для выполнения краткосрочного исправления проблем путем перезапуска процесса.

Вы уже завершили работу с примером целевого объекта отладки в рамках этого учебника и можете закрыть этот объект. Перейдите к терминалу, с которого запущен сервер, и нажмите клавиши CTRL+C.

Анализ основного дампа

Теперь, когда у вас есть основной дамп, используйте инструмент dotnet-dump, чтобы проанализировать его:

dotnet-dump analyze core_20190430_185145

Где core_20190430_185145 — это имя основного дампа, который нужно проанализировать.

Примечание

Если отображается сообщение о том, что libdl.so не удалось найти, возможно, потребуется установить пакет libc6-dev. Дополнительные сведения см. в статье Необходимые компоненты для .NET Core в Linux.

Отобразится командная строка для ввода команд SOS. Как правило, в первую очередь нужно просмотреть общее состояние управляемой динамической памяти:

> dumpheap -stat

Statistics:
              MT    Count    TotalSize Class Name
...
00007f6c1eeefba8      576        59904 System.Reflection.RuntimeMethodInfo
00007f6c1dc021c8     1749        95696 System.SByte[]
00000000008c9db0     3847       116080      Free
00007f6c1e784a18      175       128640 System.Char[]
00007f6c1dbf5510      217       133504 System.Object[]
00007f6c1dc014c0      467       416464 System.Byte[]
00007f6c21625038        6      4063376 testwebapi.Controllers.Customer[]
00007f6c20a67498   200000      4800000 testwebapi.Controllers.Customer
00007f6c1dc00f90   206770     19494060 System.String
Total 428516 objects

В нашем примере видно, что большинство объектов принадлежат к типу String либо Customer.

Вы можете повторно выполнить команду dumpheap с помощью таблицы методов, чтобы получить список всех экземпляров String:

> dumpheap -mt 00007faddaa50f90

         Address               MT     Size
...
00007f6ad09421f8 00007faddaa50f90       94
...
00007f6ad0965b20 00007f6c1dc00f90       80
00007f6ad0965c10 00007f6c1dc00f90       80
00007f6ad0965d00 00007f6c1dc00f90       80
00007f6ad0965df0 00007f6c1dc00f90       80
00007f6ad0965ee0 00007f6c1dc00f90       80

Statistics:
              MT    Count    TotalSize Class Name
00007f6c1dc00f90   206770     19494060 System.String
Total 206770 objects

Теперь можно использовать команду gcroot в экземпляре System.String, чтобы узнать, как и зачем объект становится корневым. Подождите, так как выполнение этой команды для объема памяти в 30 МБ занимает несколько минут:

> gcroot -all 00007f6ad09421f8

Thread 3f68:
    00007F6795BB58A0 00007F6C1D7D0745 System.Diagnostics.Tracing.CounterGroup.PollForValues() [/_/src/System.Private.CoreLib/shared/System/Diagnostics/Tracing/CounterGroup.cs @ 260]
        rbx:  (interior)
            ->  00007F6BDFFFF038 System.Object[]
            ->  00007F69D0033570 testwebapi.Controllers.Processor
            ->  00007F69D0033588 testwebapi.Controllers.CustomerCache
            ->  00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]
            ->  00007F6C000148A0 testwebapi.Controllers.Customer[]
            ->  00007F6AD0942258 testwebapi.Controllers.Customer
            ->  00007F6AD09421F8 System.String

HandleTable:
    00007F6C98BB15F8 (pinned handle)
    -> 00007F6BDFFFF038 System.Object[]
    -> 00007F69D0033570 testwebapi.Controllers.Processor
    -> 00007F69D0033588 testwebapi.Controllers.CustomerCache
    -> 00007F69D00335A0 System.Collections.Generic.List`1[[testwebapi.Controllers.Customer, DiagnosticScenarios]]
    -> 00007F6C000148A0 testwebapi.Controllers.Customer[]
    -> 00007F6AD0942258 testwebapi.Controllers.Customer
    -> 00007F6AD09421F8 System.String

Found 2 roots.

Как видно, String непосредственно содержится в объекте Customer и косвенно в объекте CustomerCache.

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

Эта общая процедура позволяет определить источник основных утечек памяти.

Очистка ресурсов

В этом учебнике вы запустили пример веб-сервера. Работа этого сервера должна быть завершена, как описано в разделе Перезапуск неисправного процесса.

Вы также можете удалить созданный файл дампа.

См. также

Следующие шаги