.NET でメモリリークをデバッグする

2025-07-25

この記事の対象: ✔️ .NET Core 3.1 SDK 以降のバージョン

目的のタスクを実行する必要がなくなったオブジェクトをアプリが参照すると、メモリがリークする可能性があります。これらのオブジェクトを参照すると、ガベージコレクターが使用したメモリを再利用できなくなります。その結果、パフォーマンスが低下し、OutOfMemoryException 例外がスローされる可能性があります。

このチュートリアルでは、.NET 診断 CLI ツールを使用して .NET アプリのメモリリークを分析するツールについて説明します。 Windows を使用している場合は、 Visual Studio のメモリ診断ツールを使用してメモリリークをデバッグできる場合があります。

このチュートリアルでは、演習として意図的にメモリをリークするサンプルアプリを使用します。意図せずにメモリがリークするアプリを分析することもできます。

このチュートリアルでは、次のことを行います。

dotnet-counters を使用してマネージドメモリの使用状況を調べます。
ダンプファイルを生成します。
ダンプファイルを使用してメモリ使用量を分析します。

[前提条件]

このチュートリアルでは、次の内容を使用します。

.NET Core 3.1 SDK 以降のバージョン。
マネージドメモリの使用状況を確認する dotnet-counters。
dotnet-dump を使用してダンプファイルを収集および分析します ( SOS デバッグ拡張機能が含まれます)。
診断するサンプルデバッグターゲットアプリ。

このチュートリアルでは、サンプルアプリとツールがインストールされ、使用できる状態であることを前提としています。

マネージドメモリの使用状況を調べる

このシナリオの根本原因に役立つ診断データの収集を開始する前に、メモリリーク (メモリ使用量の増加) が実際に発生していることを確認してください。 dotnet-counters ツールを使用して確認できます。

コンソールウィンドウを開き、サンプルデバッグターゲットをダウンロードして解凍したディレクトリに移動します。ターゲットを実行します。

dotnet run

別のコンソールから、プロセス ID を見つけます。

dotnet-counters ps

出力は次のようになります。

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

注

前のコマンドが機能しない場合、または見つからない場合は、まず dotnet-counters ツールをインストールする必要があります。次のコマンドを使用します。

dotnet tool install --global dotnet-counters

次に、 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 MB であることがわかります。

次に、URL https://localhost:5001/api/diagscenario/memleak/20000に移動します。

メモリ使用量が 30 MB に増加したことを確認します。

    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

注

時間の経過に伴う比較では、最初のダンプを収集した後も元のプロセスを実行し続け、同じ方法で 2 番目のダンプを収集します。その後、メモリ使用量が増加している場所を確認できるように、一定期間にわたって比較できる 2 つのダンプを取得します。

失敗したプロセスを再起動する

ダンプが収集されると、失敗したプロセスを診断するのに十分な情報が得られます。失敗したプロセスが運用サーバーで実行されている場合、プロセスを再起動して短期的な修復を行うのに最適なタイミングになりました。

このチュートリアルでは、サンプルデバッグターゲットを使い終えたので、閉じることができます。サーバーを起動したターミナルに移動し、 Ctrl キーを押しながら C キーを押します。

コアダンプを分析する

コアダンプが生成されたので、 dotnet-dump ツールを使用してダンプを分析します。

dotnet-dump analyze core_20190430_185145

ここで core_20190430_185145 は、分析するコアダンプの名前です。

注

libdl.so が見つからないというエラーが表示された場合は、libc6-dev パッケージをインストールする必要があります。詳細については、「 Linux 上の .NET の前提条件」を参照してください。

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 オブジェクトであることがわかります。

メソッドテーブル (MT) で 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

System.String インスタンスで gcroot コマンドを使用して、オブジェクトがルート化される方法と理由を確認できるようになりました。

> 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 オブジェクトが同様のパターンに従っていることを確認できます。この時点で、調査によって、コードの根本原因を特定するのに十分な情報が提供されました。

この一般的な手順では、主要なメモリリークの原因を特定できます。

リソースをクリーンアップする

このチュートリアルでは、サンプル Web サーバーを開始しました。このサーバーは、「失敗したプロセスの再起動」セクションの説明に従ってシャットダウンされている必要があります。

作成されたダンプファイルを削除することもできます。

こちらも参照ください

dotnet-trace を使用してプロセスを一覧表示する
dotnet-counters を使ってマネージドメモリ使用量を確認する
dotnet-dump を使用してダンプファイルを収集および分析する
dotnet/diagnostics
Visual Studio を使用してメモリリークをデバッグする

次のステップ

.NET Core での高 CPU のデバッグ

次の方法で共有

.NET でメモリ リークをデバッグする

[前提条件]

マネージド メモリの使用状況を調べる

メモリ ダンプの生成