ガベヌゞ コレクションずパフォヌマンス

この蚘事では、ガベヌゞ コレクションずメモリ䜿甚量に関連する問題に぀いお説明したす。 マネヌゞド ヒヌプに関連する問題に察凊し、アプリケヌションに察するガベヌゞ コレクションの圱響を最小限に抑える方法に぀いお説明したす。 各問題には、問題の調査に䜿甚できる手順ぞのリンクがありたす。

パフォヌマンス分析ツヌル

次のセクションでは、メモリ䜿甚量ずガベヌゞ コレクションの問題を調査するために䜿甚できるツヌルに぀いお説明したす。 この蚘事で埌述 する手順 は、これらのツヌルを参照したす。

メモリ パフォヌマンス カりンタヌ

パフォヌマンス カりンタヌを䜿甚しお、パフォヌマンス デヌタを収集できたす。 手順に぀いおは、「 ランタむム プロファむル」を参照しおください。 パフォヌマンス カりンタヌの .NET CLR メモリ カテゎリは、「 .NET のパフォヌマンス カりンタヌ」で説明されおいるように、ガベヌゞ コレクタヌに関する情報を提䟛したす。

SOS を䜿甚したデバッグ

Windows デバッガヌ (WinDbg) を䜿甚しお、マネヌゞド ヒヌプ䞊のオブゞェクトを怜査できたす。

WinDbg をむンストヌルするには、[Windows 甚デバッグ ツヌルのダりンロヌド] ペヌゞから Windows 甚デバッグ ツヌルをむンストヌル したす。

ガベヌゞ コレクション ETW むベント

Windows のむベント トレヌス (ETW) は、.NET によっお提䟛されるプロファむリングずデバッグのサポヌトを補完するトレヌス システムです。 ガベヌゞ コレクション ETW むベント は、統蚈的芳点からマネヌゞド ヒヌプを分析するのに圹立぀情報をキャプチャしたす。 たずえば、ガベヌゞ コレクションが発生しようずしたずきに発生する GCStart_V1 むベントは、次の情報を提䟛したす。

  • 収集されるオブゞェクトのゞェネレヌション
  • ガベヌゞ コレクションが発生した理由
  • ガベヌゞ コレクションの皮類 (同時実行たたは非同時実行)

ETW むベント ログは効率的であり、ガベヌゞ コレクションに関連するパフォヌマンスの問題がマスクされるこずはありたせん。 プロセスは、ETW むベントず組み合わせお独自のむベントを提䟛できたす。 ログに蚘録されたら、アプリケヌションのむベントずガベヌゞコレクションのむベントを関連付けお分析し、ヒヌプの問題がどのように発生するか、たたそのタむミングを把握できたす。 たずえば、サヌバヌ アプリケヌションは、クラむアント芁求の開始時ず終了時にむベントを提䟛できたす。

プロファむリング API

共通蚀語ランタむム (CLR) プロファむリング むンタヌフェむスは、ガベヌゞ コレクション䞭に圱響を受けたオブゞェクトに関する詳现情報を提䟛したす。 プロファむラヌは、ガベヌゞ コレクションの開始時ず終了時に通知を受け取るこずができたす。 各䞖代のオブゞェクトの識別など、マネヌゞド ヒヌプ䞊のオブゞェクトに関するレポヌトを提䟛できたす。 詳现に぀いおは、「 プロファむリングの抂芁」を参照しおください。

プロファむラヌは、包括的な情報を提䟛できたす。 ただし、耇雑なプロファむラヌは、アプリケヌションの動䜜を倉曎する可胜性がありたす。

アプリケヌション ドメむン リ゜ヌスの監芖

アプリケヌション ドメむン リ゜ヌス監芖 (ARM) を䜿甚するず、ホストはアプリケヌション ドメむン別に CPU ずメモリの䜿甚状況を監芖できたす。 詳现に぀いおは、「 アプリケヌション ドメむン リ゜ヌスの監芖」を参照しおください。

パフォヌマンスに関する問題のトラブルシュヌティング

最初の手順では、 問題が実際にガベヌゞ コレクションであるかどうかを刀断したす。 それが正しいず刀断した堎合は、次の䞀芧から遞択しお問題のトラブルシュヌティングを行いたす。

問題: メモリ䞍足䟋倖゚ラヌが発生する

OutOfMemoryException マネヌゞド䟋倖がスロヌされる正圓な状況ずしおは、次の 2 ぀がありたす。

  • 仮想メモリが䞍足しおいたす。

    ガベヌゞ コレクタヌは、事前に決定されたサむズのセグメントでシステムからメモリを割り圓おたす。 割り圓おに远加のセグメントが必芁であっおも、プロセスの仮想メモリ領域に連続する空きブロックが残っおいない堎合、マネヌゞド ヒヌプの割り圓おは倱敗したす。

  • 割り圓おるのに十分な物理メモリがありたせん。

パフォヌマンス チェック
メモリ䞍足䟋倖が管理されおいるかどうかを刀断したす。
予玄できる仮想メモリの量を決定したす。
十分な物理メモリがあるかどうかを刀断したす。

䟋倖が正圓でないず刀断した堎合は、次の情報を Microsoft カスタマヌ サヌビスおよびサポヌトにお問い合わせください。

  • メモリ䞍足のマネヌゞド䟋倖を含むスタック。
  • 完党なメモリ ダンプ
  • 仮想たたは物理メモリが問題ではないこずを瀺すデヌタを含め、それがメモリ䞍足の正圓な䟋倖ではないこずを蚌明するデヌタ。

問題: プロセスがメモリを䜿いすぎおいる

䞀般的な前提は、Windows タスク マネヌゞャヌの [ パフォヌマンス ] タブにメモリ䜿甚量が衚瀺され、䜿甚されおいるメモリの量が倚すぎるこずを瀺す可胜性があるずいうこずです。 ただし、この衚瀺はワヌキング セットに関連したす。仮想メモリ䜿甚量に関する情報は提䟛されたせん。

問題がマネヌゞド ヒヌプによっお発生しおいるず刀断した堎合は、時間の経過ず同時にマネヌゞド ヒヌプを枬定しお、パタヌンを特定する必芁がありたす。

問題がマネヌゞド ヒヌプによっお匕き起こされおいないず刀断した堎合は、ネむティブ デバッグを䜿甚する必芁がありたす。

パフォヌマンス チェック
予玄できる仮想メモリの量を決定したす。
マネヌゞド ヒヌプがコミットしおいるメモリの量を確認したす。
マネヌゞド ヒヌプが予玄するメモリの量を決定したす。
第 2 䞖代の倧きなオブゞェクトを特定したす。
オブゞェクトぞの参照を決定したす。

問題: ガベヌゞコレクタヌがオブゞェクトを十分に迅速に回収できない

オブゞェクトがガベヌゞ コレクションに察しお期埅どおりに再利甚されおいないかのように芋える堎合は、それらのオブゞェクトぞの匷力な参照があるかどうかを刀断する必芁がありたす。

たた、配信䞍胜オブゞェクトを含むゞェネレヌションのガベヌゞ コレクションが存圚しない堎合にも、この問題が発生する可胜性がありたす。これは、配信䞍胜オブゞェクトのファむナラむザヌが実行されおいないこずを瀺したす。 たずえば、シングル スレッド アパヌトメント (STA) アプリケヌションを実行しおいお、ファむナラむザヌ キュヌにサヌビスを提䟛するスレッドが呌び出せない堎合に、これが可胜です。

パフォヌマンス チェック
オブゞェクトぞの参照を確認したす。
ファむナラむザヌが実行されたかどうかを確認したす。
最終凊理を埅機しおいるオブゞェクトがあるかどうかを刀断したす。

問題: マネヌゞド ヒヌプが断片化しすぎおいる

断片化レベルは、䞖代に割り圓おられたメモリの合蚈に察する空き領域の比率ずしお蚈算されたす。 第 2 䞖代の堎合、蚱容できる断片化レベルは 20%以䞋です。 ゞェネレヌション 2 は非垞に倧きくなるため、断片化の比率は絶察倀よりも重芁です。

新しいオブゞェクトが割り圓おられる䞖代であるため、ゞェネレヌション 0 に倚くの空き領域を持぀こずは問題ではありたせん。

断片化は、圧瞮されおいないため、垞にラヌゞ オブゞェクト ヒヌプで発生したす。 隣接する空き領域は、倧きなオブゞェクトの割り圓お芁求を満たすために、単䞀の領域に自然に統合されたす。

第 1 䞖代ず第 2 䞖代では断片化が問題になる可胜性がありたす。 ガベヌゞ コレクションの埌にこれらの䞖代に倧量の空き領域がある堎合は、アプリケヌションのオブゞェクトの䜿甚に倉曎が必芁な堎合があり、長期的なオブゞェクトの有効期間の再評䟡を怜蚎する必芁がありたす。

オブゞェクトを過床にピン留めするず、断片化が増加する可胜性がありたす。 断片化が高い堎合は、ピン留めされたオブゞェクトが倚すぎる可胜性がありたす。

仮想メモリの断片化によっおガベヌゞ コレクタヌがセグメントを远加できない堎合、原因は次のいずれかである可胜性がありたす。

  • 倚数の小さなアセンブリの頻繁な読み蟌みずアンロヌド。

  • アンマネヌゞ コヌドずの盞互運甚時に COM オブゞェクトぞの参照が倚すぎたす。

  • 倧芏暡な䞀時的オブゞェクトを䜜成するず、倧きなオブゞェクト ヒヌプが頻繁にヒヌプ セグメントを割り圓おたり解攟したりしたす。

    CLR をホストする堎合、アプリケヌションはガベヌゞ コレクタヌにそのセグメントを保持するこずを芁求できたす。 これにより、セグメント割り圓おの頻床が枛少したす。 これを行うには、STARTUP_FLAGS 列挙で STARTUP_HOARD_GC_VM フラグを䜿甚したす。

パフォヌマンス チェック
マネヌゞド ヒヌプ内の空き領域の量を決定したす。
ピン留めされたオブゞェクトの数を決定したす。

断片化の正圓な原因がないず思われる堎合は、Microsoft カスタマヌ サヌビスずサポヌトにお問い合わせください。

問題: ガベヌゞ コレクションの䞀時停止が長すぎる

ガベヌゞ コレクションは゜フト リアルタむムで動䜜するため、アプリケヌションは䞀時停止を蚱容できる必芁がありたす。 ゜フト リアルタむムの基準では、95% の操䜜が時間どおりに完了する必芁がありたす。

同時実行ガベヌゞ コレクションでは、マネヌゞド スレッドはコレクション䞭に実行できたす。぀たり、䞀時停止は非垞に最小限です。

゚フェメラル ガベヌゞ コレクション (ゞェネレヌション 0 ずゞェネレヌション 1) は数ミリ秒しか持続しないため、通垞、䞀時停止を枛らすこずは䞍可胜です。 ただし、アプリケヌションによる割り圓お芁求のパタヌンを倉曎するこずで、第 2 䞖代コレクションの䞀時停止を枛らすこずができたす。

もう 1 ぀のより正確な方法は、 ガベヌゞ コレクション ETW むベントを䜿甚するこずです。 䞀連のむベントにタむム スタンプの違いを远加するこずで、コレクションのタむミングを確認できたす。 コレクションシヌケンス党䜓には、実行゚ンゞンの䞭断、ガベヌゞコレクション自䜓、そしお実行゚ンゞンの再開が含たれたす。

ガベヌゞ コレクション通知を䜿甚しお、サヌバヌがゞェネレヌション 2 のコレクションを䜿甚しようずしおいるかどうか、および別のサヌバヌに芁求を再ルヌティングするず、䞀時停止に関する問題が緩和される可胜性があるかどうかを刀断できたす。

パフォヌマンス チェック
ガベヌゞコレクションの所芁時間を決定したす。
ガベヌゞ コレクションが発生した原因を確認する。

問題: ゞェネレヌション 0 が倧きすぎる

ゞェネレヌション 0 では、特にワヌクステヌションのガベヌゞ コレクションではなくサヌバヌ ガベヌゞ コレクションを䜿甚する堎合に、64 ビット システム䞊のオブゞェクトの数が倚くなる可胜性がありたす。 これは、これらの環境ではゞェネレヌション 0 のガベヌゞ コレクションをトリガヌするしきい倀が高く、ゞェネレヌション 0 のコレクションがはるかに倧きくなる可胜性があるためです。 ガベヌゞ コレクションがトリガヌされる前に、アプリケヌションがより倚くのメモリを割り圓おるず、パフォヌマンスが向䞊したす。

問題: ガベヌゞ コレクション䞭の CPU 䜿甚率が高すぎたす

ガベヌゞ コレクション䞭は CPU 䜿甚率が高くなりたす。 ガベヌゞ コレクションに凊理時間が倧幅に費やされおいる堎合、収集の頻床が高すぎるか、時間がかかりすぎおいたす。 マネヌゞド ヒヌプ䞊のオブゞェクトの割り圓お率が高くなるず、ガベヌゞ コレクションの実行頻床が高くなりたす。 割り圓お率を䞋げるず、ガベヌゞ コレクションの頻床が枛少したす。

Allocated Bytes/second パフォヌマンス カりンタヌを䜿甚しお、割り圓お率を監芖できたす。 詳现に぀いおは、「 .NET のパフォヌマンス カりンタヌ」を参照しおください。

コレクションの期間は、䞻に割り圓お埌に存続するオブゞェクトの数の芁因です。 コレクションの察象ずなるオブゞェクトが数倚く残っおいるず、ガベヌゞ コレクタヌが倧量のメモリを凊理しなければならなくなりたす。 生存者を圧瞮する䜜業には時間がかかりたす。 コレクション䞭に凊理されたオブゞェクトの数を確認するには、指定した䞖代のガベヌゞ コレクションの最埌にデバッガヌにブレヌクポむントを蚭定したす。

パフォヌマンス チェック
CPU 䜿甚率が高い堎合、それがガベヌゞ コレクションによるものかどうかを刀断したす。
ガベヌゞ コレクションの終了時にブレヌクポむントを蚭定する。

トラブルシュヌティングのガむドラむン

このセクションでは、調査を開始するずきに考慮する必芁があるガむドラむンに぀いお説明したす。

ワヌクステヌションのガベヌゞ コレクションかサヌバヌのガベヌゞ コレクションか

䜿甚しおいるガベヌゞ コレクションの皮類が正しいかどうかを確認したす。 アプリケヌションで耇数のスレッドずオブゞェクト むンスタンスを䜿甚する堎合は、ワヌクステヌションのガベヌゞ コレクションではなくサヌバヌ ガベヌゞ コレクションを䜿甚したす。 サヌバヌ ガベヌゞ コレクションは耇数のスレッドで動䜜したすが、ワヌクステヌションのガベヌゞ コレクションでは、アプリケヌションの耇数のむンスタンスが独自のガベヌゞ コレクション スレッドを実行し、CPU 時間を競う必芁がありたす。

負荷が䜎く、バックグラりンドでたたにタスクを実行するサヌビスのようなアプリケヌションでは、同時実行ガベヌゞコレクションを無効にしたワヌクステヌション ガベヌゞコレクションを䜿甚できたす。

マネヌゞド ヒヌプ サむズを枬定するタむミング

プロファむラヌを䜿甚しおいる堎合を陀き、パフォヌマンスの問題を効果的に蚺断するには、䞀貫した枬定パタヌンを確立する必芁がありたす。 スケゞュヌルを確立するには、次の点を考慮しおください。

  • ゞェネレヌション 2 のガベヌゞ コレクションの埌に枬定する堎合は、マネヌゞド ヒヌプ党䜓からガベヌゞ (死んだ状態のオブゞェクト) がなくなっおいたす。
  • ゞェネレヌション 0 のガベヌゞ コレクションの盎埌に枬定した堎合、ゞェネレヌション 1 ずゞェネレヌション 2 のオブゞェクトはただ収集されたせん。
  • ガベヌゞ コレクションの盎前に枬定する堎合は、どのくらいの割り圓おが行われるずガベヌゞ コレクションが開始されるのかが枬定されたす。
  • ガベヌゞ コレクタヌのデヌタ構造がトラバヌサルに察しお有効な状態ではなく、完党な結果を埗られない可胜性があるため、ガベヌゞ コレクション䞭の枬定には問題がありたす。 これは仕様です。
  • 同時実行ガベヌゞ コレクションを有効にしおワヌクステヌションのガベヌゞ コレクションを䜿甚しおいる堎合は、解攟されたオブゞェクトが圧瞮されないため、ヒヌプ サむズが倉わらなかったり倧きくなっおいたりするこずがありたす (断片化のために倧きく芋えるこずがありたす)。
  • 物理メモリの負荷が高すぎるず、ゞェネレヌション 2 での同時実行ガベヌゞ コレクションが遅延したす。

次の手順では、マネヌゞド ヒヌプを枬定できるようにブレヌクポむントを蚭定する方法に぀いお説明したす。

ガベヌゞ コレクションの終了時にブレヌクポむントを蚭定するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg で、次のコマンドを入力したす。

    bp mscorwks!WKS::GCHeap::RestartEE "j (dwo(mscorwks!WKS::GCHeap::GcCondemnedGeneration)==2) 'kb';'g'"

    GcCondemnedGenerationを目的の䞖代に蚭定したす。 このコマンドにはプラむベヌト シンボルが必芁です。

    ゞェネレヌション 2 のオブゞェクトがガベヌゞ コレクション甚に再利甚された埌に RestartEE が実行された堎合、このコマンドは匷制的に䞭断したす。

    サヌバヌ ガベヌゞ コレクションでは、 RestartEE呌び出すスレッドは 1 ぀だけであるため、ブレヌクポむントはゞェネレヌション 2 のガベヌゞ コレクション䞭に 1 回だけ発生したす。

パフォヌマンス チェックの手順

このセクションでは、パフォヌマンスの問題の原因を特定するための次の手順に぀いお説明したす。

問題の原因がガベヌゞ コレクションにあるかどうかを確認するには

  • 次の 2 ぀のメモリ パフォヌマンス カりンタヌを確認したす。

    • GC 内での時間割合 最埌のガベヌゞ コレクション サむクル埌にガベヌゞ コレクションの実行に費やされた経過時間の割合を衚瀺したす。 このカりンタヌを䜿甚するず、ガベヌゞ コレクタヌがマネヌゞド ヒヌプの領域を確保するために費やしおいる時間が長すぎないかどうかを確認できたす。 ガベヌゞ コレクションに費やされる時間が比范的少ない堎合は、マネヌゞド ヒヌプの倖郚にあるリ゜ヌスの問題を瀺しおいる可胜性がありたす。 このカりンタヌは、同時実行ガベヌゞ コレクションやバックグラりンド ガベヌゞ コレクションでは正確な倀が埗られない可胜性がありたす。

    • # コミットされた合蚈バむト数。 ガベヌゞ コレクタヌによっお珟圚コミットされおいる仮想メモリの量を衚瀺したす。 このカりンタヌを䜿甚しお、ガベヌゞ コレクタヌによっお消費されるメモリが、アプリケヌションで䜿甚されるメモリの過剰な郚分であるかどうかを刀断したす。

    ほずんどのメモリ パフォヌマンス カりンタヌは、各ガベヌゞ コレクションの終了時に曎新されたす。 そのため、情報が必芁な珟圚の条件が反映されおいない可胜性がありたす。

メモリ䞍足䟋倖が管理されおいるかどうかを確認するには

  1. SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、印刷䟋倖 (pe) コマンドを入力したす。

    !pe

    䟋倖が管理されおいる堎合、次の䟋に瀺すように、 OutOfMemoryException は䟋倖の皮類ずしお衚瀺されたす。

    Exception object: 39594518
Exception type: System.OutOfMemoryException
Message: <none>
InnerException: <none>
StackTrace (generated):

  2. 出力で䟋倖が指定されおいない堎合は、メモリ䞍足䟋倖の元のスレッドを特定する必芁がありたす。 デバッガヌで次のコマンドを入力しお、すべおのスレッドずその呌び出し履歎を衚瀺したす。

    ~\*kb

    䟋倖呌び出しがあるスタックを持぀スレッドは、 RaiseTheException 匕数によっお瀺されたす。 これはマネヌゞド䟋倖オブゞェクトです。

    28adfb44 7923918f 5b61f2b4 00000000 5b61f2b4 mscorwks!RaiseTheException+0xa0

  3. 次のコマンドを䜿甚しお、入れ子になった䟋倖をダンプできたす。

    !pe -nested

    䟋倖が芋぀からない堎合、メモリ䞍足䟋倖はアンマネヌゞ コヌドから発生したす。

予玄できる仮想メモリの量を確認するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg で、次のコマンドを入力しお最倧の空き領域を取埗したす。

    !address -summary

    最倧の空き領域は、次の出力に瀺すように衚瀺されたす。

    Largest free region: Base 54000000 - Size 0003A980

    この䟋では、最倧の空き領域のサむズは玄 2,4000 KB (16 進数で 3A980) です。 この領域は、ガベヌゞ コレクタヌがセグメントに必芁ずする領域よりもはるかに小さくなりたす。

    - たたは -

  • vmstat コマンドを䜿甚したす。

    !vmstat

    最倧の空き領域は、次の出力に瀺すように、MAXIMUM 列の最倧倀です。

    TYPE        MINIMUM   MAXIMUM     AVERAGE   BLK COUNT   TOTAL
~~~~        ~~~~~~~   ~~~~~~~     ~~~~~~~   ~~~~~~~~~~  ~~~~
Free:
Small       8K        64K         46K       36          1,671K
Medium      80K       864K        349K      3           1,047K
Large       1,384K    1,278,848K  151,834K  12          1,822,015K
Summary     8K        1,278,848K  35,779K   51          1,824,735K

十分な物理メモリがあるかどうかを刀断するには

  1. Windows タスク マネヌゞャヌを起動したす。

  2. [ Performance ] タブで、コミットされた倀を確認したす。 (Windows 7 では、Commit (KB)のSystem groupを参照しおください)。

    TotalがLimitに近い堎合は、物理メモリが䞍足しおいたす。

マネヌゞド ヒヌプがコミットしおいるメモリの量を確認するには

  • # Total committed bytes メモリ パフォヌマンス カりンタヌを䜿甚しお、マネヌゞド ヒヌプがコミットしおいるバむト数を取埗したす。 ガベヌゞ コレクタヌは、セグメントのチャンクを必芁に応じおコミットしたす。すべおを同時にコミットするのではありたせん。

    泚

    # Bytes in all Heaps パフォヌマンス カりンタヌは、マネヌゞド ヒヌプによる実際のメモリ䜿甚量を衚しおいないため、䜿甚しないでください。 䞖代のサむズはこの倀に含たれおおり、実際にはしきい倀ずなるサむズ、぀たり、䞖代がオブゞェクトで満たされた堎合にガベヌゞコレクションを誘発するサむズです。 したがっお、この倀は通垞 0 です。

マネヌゞド ヒヌプが予玄するメモリの量を確認するには

  • # Total reserved bytes メモリ パフォヌマンス カりンタヌを䜿甚したす。

    ガベヌゞ コレクタヌはセグメント内のメモリを予玄し、 eeheap コマンドを䜿甚しおセグメントの開始䜍眮を決定できたす。

    Von Bedeutung

    ガベヌゞ コレクタヌが各セグメントに割り圓おるメモリの量を決定できたすが、セグメント サむズは実装固有であり、定期的な曎新を含め、い぀でも倉曎される可胜性がありたす。 アプリでは、セグメント サむズを掚枬するこずや、特定のセグメント サむズに䟝存するこずを絶察に避けおください。たた、セグメントの割り圓おに䜿甚可胜なメモリの量を構成しようずしおもなりたせん。

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力したす。

    !eeheap -gc

    結果は次のようになりたす。

    Number of GC Heaps: 2
------------------------------
Heap 0 (002db550)
generation 0 starts at 0x02abe29c
generation 1 starts at 0x02abdd08
generation 2 starts at 0x02ab0038
ephemeral segment allocation context: none
  segment    begin allocated     size
02ab0000 02ab0038  02aceff4 0x0001efbc(126908)
Large object heap starts at 0x0aab0038
  segment    begin allocated     size
0aab0000 0aab0038  0aab2278 0x00002240(8768)
Heap Size   0x211fc(135676)
------------------------------
Heap 1 (002dc958)
generation 0 starts at 0x06ab1bd8
generation 1 starts at 0x06ab1bcc
generation 2 starts at 0x06ab0038
ephemeral segment allocation context: none
  segment    begin allocated     size
06ab0000 06ab0038  06ab3be4 0x00003bac(15276)
Large object heap starts at 0x0cab0038
  segment    begin allocated     size
0cab0000 0cab0038  0cab0048 0x00000010(16)
Heap Size    0x3bbc(15292)
------------------------------
GC Heap Size   0x24db8(150968)

    "segment" で瀺されるアドレスは、セグメントの開始アドレスです。

第 2 䞖代のラヌゞ オブゞェクトを特定するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力したす。

    !dumpheap –stat

    マネヌゞド ヒヌプが倧きい堎合、 dumpheap が完了するたでに時間がかかる堎合がありたす。

    最も倚くのスペヌスを䜿甚するオブゞェクトが䞀芧衚瀺されるため、出力の最埌の数行から分析を開始できたす。 䟋えば次が挙げられたす。

    2c6108d4   173712     14591808 DevExpress.XtraGrid.Views.Grid.ViewInfo.GridCellInfo
00155f80      533     15216804      Free
7a747c78   791070     15821400 System.Collections.Specialized.ListDictionary+DictionaryNode
7a747bac   700930     19626040 System.Collections.Specialized.ListDictionary
2c64e36c    78644     20762016 DevExpress.XtraEditors.ViewInfo.TextEditViewInfo
79124228   121143     29064120 System.Object[]
035f0ee4    81626     35588936 Toolkit.TlkOrder
00fcae40     6193     44911636 WaveBasedStrategy.Tick_Snap[]
791242ec    40182     90664128 System.Collections.Hashtable+bucket[]
790fa3e0  3154024    137881448 System.String
Total 8454945 objects

    リストされおいる最埌のオブゞェクトは文字列であり、最も倚くの領域を占有したす。 アプリケヌションを調べお、文字列オブゞェクトを最適化する方法を確認できたす。 150 ~ 200 バむトの文字列を衚瀺するには、次のように入力したす。

    !dumpheap -type System.String -min 150 -max 200

    結果の䟋を次に瀺したす。

    Address  MT           Size  Gen
1875d2c0 790fa3e0      152    2 System.String HighlightNullStyle_Blotter_PendingOrder-11_Blotter_PendingOrder-11



    ID に文字列の代わりに敎数を䜿甚する方が効率的です。 同じ文字列が䜕千回も繰り返されおいる堎合は、文字列のむンタヌンを怜蚎しおください。 文字列のむンタヌニングの詳しくは、String.Intern メ゜ッドの参照情報をご芧ください。

オブゞェクトぞの参照を決定するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg で、次のコマンドを入力しおオブゞェクトぞの参照を䞀芧衚瀺したす。

    !gcroot

    - たたは -

  • 特定のオブゞェクトの参照を確認するには、アドレスを含めたす。

    !gcroot 1c37b2ac

    履歎で芋぀かるルヌトは誀怜出である可胜性がありたす。 詳现に぀いおは、コマンド !help gcroot を䜿甚しおください。

    ebx:Root:19011c5c(System.Windows.Forms.Application+ThreadContext)->
19010b78(DemoApp.FormDemoApp)->
19011158(System.Windows.Forms.PropertyStore)->

 [omitted]
1c3745ec(System.Data.DataTable)->
1c3747a8(System.Data.DataColumnCollection)->
1c3747f8(System.Collections.Hashtable)->
1c376590(System.Collections.Hashtable+bucket[])->
1c376c98(System.Data.DataColumn)->
1c37b270(System.Data.Common.DoubleStorage)->
1c37b2ac(System.Double[])
Scan Thread 0 OSTHread 99c
Scan Thread 6 OSTHread 484

    gcroot コマンドの完了には長い時間がかかる堎合がありたす。 ガベヌゞコレクションで回収されなかったオブゞェクトは、アクティブオブゞェクトです。 ぀たり、ルヌトが盎接たたは間接的にオブゞェクトを保持しおいるため、 gcroot はオブゞェクトにパス情報を返す必芁がありたす。 返されたグラフを調べお、これらのオブゞェクトがただ参照されおいる理由を確認する必芁がありたす。

ファむナラむザヌが実行されたかどうかを確認するには

  • 次のコヌドを含むテスト プログラムを実行したす。

    GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

    テストで問題が解決された堎合、ガベヌゞコレクタヌがオブゞェクトを回収しおいなかったこずを意味したす。これは、これらのオブゞェクトのファむナラむザヌが停止しおいたためです。 GC.WaitForPendingFinalizers メ゜ッドを䜿甚するず、ファむナラむザヌはタスクを完了し、問題を修正できたす。

最終凊理を埅機しおいるオブゞェクトがあるかどうかを刀断するには

  1. SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力したす。

    !finalizequeue

    最終凊理の準備ができおいるオブゞェクトの数を確認したす。 数倀が倧きい堎合は、これらのファむナラむザヌがたったく進行できないか、たたは十分な速さで進行できない理由を調べる必芁がありたす。

  2. スレッドの出力を取埗するには、次のコマンドを入力したす。

    !threads -special

    このコマンドは、次のような出力を提䟛したす。

       OSID     Special thread type
2    cd0    DbgHelper
3    c18    Finalizer
4    df0    GC SuspendEE

    ファむナラむザヌ スレッドは、珟圚実行されおいるファむナラむザヌ (ある堎合) を瀺したす。 ファむナラむザヌ スレッドがファむナラむザヌを実行しおいない堎合、むベントがその凊理を実行するように通知するのを埅機しおいたす。 ほずんどの堎合、ファむナラむザヌ スレッドはTHREAD_HIGHEST_PRIORITYで実行され、ファむナラむザヌがある堎合は非垞に迅速に実行が完了するため、この状態になりたす。

マネヌゞド ヒヌプ内の空き領域の量を確認するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力したす。

    !dumpheap -type Free -stat

    このコマンドは、次の䟋に瀺すように、マネヌゞド ヒヌプ䞊のすべおの空きオブゞェクトの合蚈サむズを衚瀺したす。

    total 230 objects
Statistics:
      MT    Count    TotalSize Class Name
00152b18      230     40958584      Free
Total 230 objects

  • ゞェネレヌション 0 の空き領域を確認するには、䞖代別のメモリ消費情報に察しお次のコマンドを入力したす。

    !eeheap -gc

    このコマンドは、次のような出力を衚瀺したす。 最埌の行には、゚フェメラル セグメントが衚瀺されたす。

    Heap 0 (0015ad08)
generation 0 starts at 0x49521f8c
generation 1 starts at 0x494d7f64
generation 2 starts at 0x007f0038
ephemeral segment allocation context: none
segment  begin     allocated  size
00178250 7a80d84c  7a82f1cc   0x00021980(137600)
00161918 78c50e40  78c7056c   0x0001f72c(128812)
007f0000 007f0038  047eed28   0x03ffecf0(67103984)
3a120000 3a120038  3a3e84f8   0x002c84c0(2917568)
46120000 46120038  49e05d04   0x03ce5ccc(63855820)

  • ゞェネレヌション 0 で䜿甚される領域を蚈算したす。

    ? 49e05d04-0x49521f8c

    結果は次のようになりたす。 ゞェネレヌション 0 は玄 9 MB です。

    Evaluate expression: 9321848 = 008e3d78

  • 次のコマンドは、ゞェネレヌション 0 の範囲内の空き領域をダンプしたす。

    !dumpheap -type Free -stat 0x49521f8c 49e05d04

    結果は次のようになりたす。

    ------------------------------
Heap 0
total 409 objects
------------------------------
Heap 1
total 0 objects
------------------------------
Heap 2
total 0 objects
------------------------------
Heap 3
total 0 objects
------------------------------
total 409 objects
Statistics:
      MT    Count TotalSize Class Name
0015a498      409   7296540      Free
Total 409 objects

    この出力は、ヒヌプの第 0 䞖代郚分がオブゞェクトに 9 MB の領域を䜿甚しおおり、7 MB の空き容量があるこずを瀺しおいたす。 この分析は、ゞェネレヌション 0 が断片化にどの皋床寄䞎するかを瀺しおいたす。 このヒヌプ䜿甚量は、長期存圚するオブゞェクトによる断片化の原因ずしお、合蚈量から差し匕く必芁がありたす。

ピン留めされたオブゞェクトの数を確認するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力したす。

    !gchandles

    次の䟋に瀺すように、衚瀺される統蚈情報には、ピン留めされたハンドルの数が含たれたす。

    GC Handle Statistics:
Strong Handles:      29
Pinned Handles:      10

ゎミ収集プロセスの期間を確認するには

  • % Time in GC メモリ パフォヌマンス カりンタヌを調べたす。

    この倀は、サンプル間隔時間を䜿甚しお蚈算されたす。 カりンタヌは各ガベヌゞ コレクションの最埌に曎新されるため、珟圚のサンプルは、間隔䞭にコレクションが発生しなかった堎合、前のサンプルず同じ倀になりたす。

    収集時間は、サンプル間隔の時間ずパヌセント倀を乗算するこずによっお取埗されたす。

    次のデヌタは、8 秒間の 2 秒の 4 ぀のサンプリング間隔を瀺しおいたす。 Gen0、Gen1、およびGen2の列には、その䞖代の間隔の終わりたでに完了したガベヌゞ コレクションの合蚈数が衚瀺されたす。

    Interval    Gen0    Gen1    Gen2    % Time in GC
        1       9       3       1              10
        2      10       3       1               1
        3      11       3       1               3
        4      11       3       1               3

    この情報はガベヌゞ コレクションがい぀発生したかを瀺したせんが、䞀定の間隔で発生したガベヌゞ コレクションの数を特定できたす。 最悪の堎合、第 10 䞖代 0 のガベヌゞ コレクションは 2 番目の間隔の開始時に終了し、第 11 䞖代 0 のガベヌゞ コレクションは 3 番目の間隔の最埌に終了したした。 10 番目のガベヌゞ コレクションの終了から 11 番目のガベヌゞ コレクションの終了たでの時間は玄 2 秒で、パフォヌマンス カりンタヌには 3%が衚瀺されるため、第 11 䞖代 0 のガベヌゞ コレクションの期間は (2 秒 * 3% = 60 ミリ秒) でした。

    次の䟋では、5 ぀の間隔がありたす。

    Interval    Gen0    Gen1    Gen2     % Time in GC
        1       9       3       1                3
        2      10       3       1                1
        3      11       4       1                1
        4      11       4       1                1
        5      11       4       2               20

    第 2 䞖代のガベヌゞ コレクションは、第 4 むンタヌバルで開始され、第 5 むンタヌバルで終了したした。 最悪のケヌスを想定するず、最埌のガベヌゞ コレクションは、3 番目の間隔の開始時に終了したゞェネレヌション 0 コレクション甚であり、ゞェネレヌション 2 のガベヌゞ コレクションは 5 番目の間隔の最埌に終了したした。 そのため、ゞェネレヌション 0 ガベヌゞ コレクションの終了からゞェネレヌション 2 ガベヌゞ コレクションの終了たでの時間は 4 秒です。 % Time in GC カりンタヌは 20%であるため、ゞェネレヌション 2 のガベヌゞ コレクションにかかる最倧時間は (4 秒 * 20% = 800 ミリ秒) です。

  • たたは、ガベヌゞ コレクション ETW むベントを䜿甚しおガベヌゞ コレクションの長さを刀断し、情報を分析しおガベヌゞ コレクションの期間を決定するこずもできたす。

    たずえば、次のデヌタは、非同時実行ガベヌゞ コレクション䞭に発生したむベント シヌケンスを瀺しおいたす。

    Timestamp    Event name
513052        GCSuspendEEBegin_V1
513078        GCSuspendEEEnd
513090        GCStart_V1
517890        GCEnd_V1
517894        GCHeapStats
517897        GCRestartEEBegin
517918        GCRestartEEEnd

    マネヌゞド スレッドの䞭断には 26マむクロ秒 (GCSuspendEEEnd – GCSuspendEEBegin_V1) かかりたした。

    実際のガベヌゞ コレクションに 4.8 ミリ秒かかっおいたす (GCEnd_V1 – GCStart_V1)。

    マネヌゞド スレッドの再開には 21us (GCRestartEEEnd – GCRestartEEBegin) かかりたした。

    次の出力は、バックグラりンド ガベヌゞ コレクションの䟋を瀺し、プロセス、スレッド、およびむベント フィヌルドを含みたす。 (すべおのデヌタが衚瀺されるわけではありたせん)。

    timestamp(us)    event name            process    thread    event field
42504385        GCSuspendEEBegin_V1    Test.exe    4372             1
42504648        GCSuspendEEEnd         Test.exe    4372
42504816        GCStart_V1             Test.exe    4372        102019
42504907        GCStart_V1             Test.exe    4372        102020
42514170        GCEnd_V1               Test.exe    4372
42514204        GCHeapStats            Test.exe    4372        102020
42832052        GCRestartEEBegin       Test.exe    4372
42832136        GCRestartEEEnd         Test.exe    4372
63685394        GCSuspendEEBegin_V1    Test.exe    4744             6
63686347        GCSuspendEEEnd         Test.exe    4744
63784294        GCRestartEEBegin       Test.exe    4744
63784407        GCRestartEEEnd         Test.exe    4744
89931423        GCEnd_V1               Test.exe    4372        102019
89931464        GCHeapStats            Test.exe    4372

    42504816の GCStart_V1 むベントは、最埌のフィヌルドが 1されおいるため、これがバックグラりンド ガベヌゞ コレクションであるこずを瀺したす。 これは、ガベヌゞ コレクション No. 102019 になりたす。

    GCStart むベントは、バックグラりンド ガベヌゞ コレクションを開始する前に゚フェメラル ガベヌゞ コレクションが必芁であるために発生したす。 これがゎミ収集番号 102020 です。

    42514170では、ガベヌゞコレクション番号102020が終了したした。 この時点で、マネヌゞド スレッドが再起動されたす。 これは、このバックグラりンド ガベヌゞ コレクションをトリガヌしたスレッド 4372 で完了したす。

    スレッド 4744 では、䞭断が発生したす。 これは、バックグラりンド ガベヌゞ コレクションがマネヌゞド スレッドを䞭断する必芁がある唯䞀の時間です。 この期間は玄 99 ミリ秒 ((63784407-63685394)/1000)。

    バックグラりンド ガベヌゞ コレクションの GCEnd むベントは、89931423で発生したす。 これは、バックグラりンド ガベヌゞ コレクションが玄 47 秒続いた ((89931423-42504816)/1000) こずを意味したす。

    マネヌゞド スレッドの実行䞭に、任意の数の゚フェメラル ガベヌゞ コレクションが発生しおいるこずがわかりたす。

ガベヌゞ コレクションが発生した原因を確認するには

  • SOS デバッガヌ拡匵機胜が読み蟌たれた WinDbg たたは Visual Studio デバッガヌで、次のコマンドを入力しお、すべおのスレッドずその呌び出し履歎を衚瀺したす。

    ~*kb

    このコマンドは、次のような出力を衚瀺したす。

    0012f3b0 79ff0bf8 mscorwks!WKS::GCHeap::GarbageCollect
0012f454 30002894 mscorwks!GCInterface::CollectGeneration+0xa4
0012f490 79fa22bd fragment_ni!request.Main(System.String[])+0x48

    ガベヌゞ コレクションがオペレヌティング システムからのメモリ䞍足の通知によっお発生した堎合、呌び出し履歎は䌌おいたすが、スレッドがファむナラむザヌ スレッドである点が異なりたす。 ファむナラむザヌ スレッドは非同期のメモリ䞍足通知を取埗し、ガベヌゞ コレクションを誘発したす。

    ガベヌゞ コレクションがメモリ割り圓おによっお発生した堎合、スタックは次のように衚瀺されたす。

    0012f230 7a07c551 mscorwks!WKS::GCHeap::GarbageCollectGeneration
0012f2b8 7a07cba8 mscorwks!WKS::gc_heap::try_allocate_more_space+0x1a1
0012f2d4 7a07cefb mscorwks!WKS::gc_heap::allocate_more_space+0x18
0012f2f4 7a02a51b mscorwks!WKS::GCHeap::Alloc+0x4b
0012f310 7a02ae4c mscorwks!Alloc+0x60
0012f364 7a030e46 mscorwks!FastAllocatePrimitiveArray+0xbd
0012f424 300027f4 mscorwks!JIT_NewArr1+0x148
000af70f 3000299f fragment_ni!request..ctor(Int32, Single)+0x20c
0000002a 79fa22bd fragment_ni!request.Main(System.String[])+0x153

    Just-In-Time ヘルパヌ (JIT_New*) は最終的に GCHeap::GarbageCollectGenerationを呌び出したす。 ゞェネレヌション 2 のガベヌゞ コレクションが割り圓おによっお発生しおいるず刀断した堎合は、ゞェネレヌション 2 ガベヌゞ コレクションによっお収集されるオブゞェクトずその回避方法を決定する必芁がありたす。 ぀たり、ゞェネレヌション 2 ガベヌゞ コレクションの開始ず終了、およびゞェネレヌション 2 コレクションの原因ずなったオブゞェクトの違いを確認する必芁がありたす。

    たずえば、デバッガヌで次のコマンドを入力しお、ゞェネレヌション 2 のコレクションの先頭を衚瀺したす。

    !dumpheap –stat

    出力䟋 (最も倚くのスペヌスを䜿甚するオブゞェクトを瀺すために簡略化):

    79124228    31857      9862328 System.Object[]
035f0384    25668     11601936 Toolkit.TlkPosition
00155f80    21248     12256296      Free
79103b6c   297003     13068132 System.Threading.ReaderWriterLock
7a747ad4   708732     14174640 System.Collections.Specialized.HybridDictionary
7a747c78   786498     15729960 System.Collections.Specialized.ListDictionary+DictionaryNode
7a747bac   700298     19608344 System.Collections.Specialized.ListDictionary
035f0ee4    89192     38887712 Toolkit.TlkOrder
00fcae40     6193     44911636 WaveBasedStrategy.Tick_Snap[]
7912c444    91616     71887080 System.Double[]
791242ec    32451     82462728 System.Collections.Hashtable+bucket[]
790fa3e0  2459154    112128436 System.String
Total 6471774 objects

    第 2 䞖代の最埌にコマンドを繰り返したす。

    !dumpheap –stat

    出力䟋 (最も倚くのスペヌスを䜿甚するオブゞェクトを瀺すために簡略化):

    79124228    26648      9314256 System.Object[]
035f0384    25668     11601936 Toolkit.TlkPosition
79103b6c   296770     13057880 System.Threading.ReaderWriterLock
7a747ad4   708730     14174600 System.Collections.Specialized.HybridDictionary
7a747c78   786497     15729940 System.Collections.Specialized.ListDictionary+DictionaryNode
7a747bac   700298     19608344 System.Collections.Specialized.ListDictionary
00155f80    13806     34007212      Free
035f0ee4    89187     38885532 Toolkit.TlkOrder
00fcae40     6193     44911636 WaveBasedStrategy.Tick_Snap[]
791242ec    32370     82359768 System.Collections.Hashtable+bucket[]
790fa3e0  2440020    111341808 System.String
Total 6417525 objects

    double[]オブゞェクトは出力の末尟から消えたした。぀たり、これらのオブゞェクトが回収されたこずを意味したす。 これらのオブゞェクトは玄 70 MB を占める。 残りのオブゞェクトはあたり倉曎されたせんでした。 そのため、これらの double[] オブゞェクトが、このゞェネレヌション 2 のガベヌゞ コレクションが発生した理由でした。 次の手順では、 double[] オブゞェクトが存圚する理由ず、そのオブゞェクトが死んだ理由を刀断したす。 これらのオブゞェクトの由来をコヌド開発者に問い合わせるこずもできたすし、 gcroot コマンドを䜿甚するこずもできたす。

CPU 䜿甚率が高いこずがガベヌゞ コレクションによるものかどうかを確認するために

  • % Time in GC メモリ パフォヌマンス カりンタヌの倀ず凊理時間を関連付けたす。

    % Time in GC倀が凊理時間ず同時に急増するず、ガベヌゞ コレクションによっお CPU 䜿甚率が高くなりたす。 それ以倖の堎合は、アプリケヌションをプロファむリングしお、䜿甚率が高い堎所を芋぀けたす。

こちらも参照ください

  • 最終曎新: