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

Статья
11/13/2023

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

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

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

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

При работе с этим руководством вы сделаете следующее:

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

Необходимые компоненты

В руководстве используются следующие ресурсы:

Пакет SDK для .NET Core 3.1 или более поздней версии.
dotnet-counters для проверки использования управляемой памяти.
dotnet-dump для сбора и анализа файла дампа (включает расширение отладки SOS).
Пример целевого приложения отладки для диагностики.

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

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

Прежде чем приступить к сбору диагностических данных, чтобы помочь в первопричине этого сценария, убедитесь, что вы на самом деле видите утечку памяти (рост использования памяти). Для этого используйте 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 можно использовать средство 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" в 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 00007f6c1dc00f90

         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 , чтобы узнать, как и почему объект коренится:

> gcroot 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 следуют той же модели. На этом этапе в результате исследования получено достаточно информации, чтобы найти основную причину утечки в коде.

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

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

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

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

См. также

dotnet-trace для отображения списка процессов
dotnet-counters для проверки использования управляемой памяти
dotnet-dump для сбора и анализа файла дампа
dotnet/diagnostics
Отладка утечек памяти с помощью Visual Studio

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

Отладка высокой загрузки ЦП в .NET Core