メモリリークをチェックするPerfmonカウンター
サービスのメモリリークの問題を確認したい。次の一連のperfmonカウンターを試しました。
- .NET CLRメモリ\＃すべてのヒープのバイト数
- .NET CLR Memory\Gen 2ヒープサイズ
- .NET CLR Memory \＃GCハンドル
- .NET CLRメモリ\固定されたオブジェクトの数
- .NET CLR Memory \＃コミットされた合計バイト数
- .NET CLR Memory \＃予約済み合計バイト
- .NET CLR Memory\Large Object Heap size
上記のセットを here から参照しました
以下のセットも参照：
- メモリ/利用可能なバイト
- メモリ/コミットされたバイト
- プロセス/プライベートバイト
- プロセス/ページファイルバイト
- プロセス/ハンドル数
上記のセットを here から参照しました
メモリリークのperfmonカウンタを識別するためのパラメータ/基準、または他の最良の方法はありますか？
メモリリークをチェックするための一連のカウンタを提案できますか？または上記のセットはメモリリークをカバーしますか？
パフォーマンスモニターを使用してメモリリークを検出するには、次のカウンターを監視します。
- Memory/Available Bytesカウンターを使用すると、使用可能なメモリの合計バイト数を表示できます。通常、この値は変動しますが、メモリリークのあるアプリケーションがある場合、時間とともに減少します。
- メモリリークが発生している場合、Memory/Committed Bytesカウンタは着実に増加します。これは、使用可能なメモリのバイト数が減少するにつれて、コミットされたバイト数が増加するためです。
- Process/Private Bytesカウンターには、特定のプロセス専用に予約されているバイト数が表示されます。メモリリークが発生している場合、この値は着実に増加する傾向があります。
- Process/Page File Bytesカウンターは、ページファイルのサイズを表示します。 Windowsは、仮想メモリ（ページファイル）を使用して、マシンの物理メモリを補完します。マシンの物理メモリがいっぱいになり始めると、メモリのページがページファイルに移動します。メモリが十分にあるマシンでもページファイルが使用されるのは正常です。しかし、ページファイルのサイズが着実に増加する場合、それはメモリリークが発生している良い兆候です。
- また、Process/Handle Countカウンターについても言及します。アプリケーションは、ハンドルを使用して、アクセスする必要のあるリソースを識別します。メモリリークが発生している場合、アプリケーションは多くの場合、メモリリソースを識別するための追加のハンドルを作成します。したがって、ハンドル数の増加は、メモリリークを示している可能性があります。ただし、すべてのメモリリークがハンドルカウントの増加につながるわけではありません。
私の経験では、これは正確です。
また、Microsoftの従業員であるTessによるこのMicrosoft Advanced Debuggingブログも参照してください。誰が次のカウンターを提案します。上記は、メモリリークが存在することを示すのに十分であることがわかりましたが、テスの指示がこの問題についてより詳細な洞察を提供できると信じています。
- すべてのヒープの.NET CLRメモリ/＃バイト
- .NET CLRメモリ/ラージオブジェクトヒープサイズ
- .NET CLRメモリ/ Gen 2ヒープサイズ
- .NET CLRメモリ/ Gen 1ヒープサイズ
- .NET CLRメモリ/ Gen 0ヒープサイズ
- プロセス/プライベートバイト
- プロセス/仮想バイト
RedGate ANTS Memory Profiler や JetBrains dotMemory Profiler など、メモリリークテストを簡単にするための優れたツールがあります。
ただし、パフォーマンスカウンターを使用する場合は、パフォーマンスカウンターを使用してメモリリークをテストする方法を この記事 で説明します。
ガベージコレクションは、インスタンスが破棄された直後にメモリを解放しないことに注意してください。メモリストレスがある場合にのみメモリをトリガーおよびリリースするように最適化されています。そのため、メモリリークをテストする場合は、カウンター読み取りを行う前にガベージコレクションを手動で実行する必要があります。
GC.Collect();
GC.WaitForPendingFinalizers();
