分析の概要
プロファイリングデータの収集が完了すると、dotMemory は 分析の概要 ページで新しいタブを開きます。
分析の概要 ページには、セッション中に収集されたデータに関する情報が表示されます。
タイムライン
タイムライングラフは、プロファイリングプロセス中にアプリがメモリをどのように消費したかを示しています。 タイムラインは、Gen0、Gen1、Gen2 ヒープ、ラージオブジェクトヒープ、ピン留めオブジェクトヒープのインスタントサイズを示す 4 つのグラフで構成されています。 管理されていないメモリを表示する パラメーターを選択して、アンマネージメモリのサイズを示すグラフを追加することもできます。
タイムライングラフは、分析の開始点として適しています。
特定の時点での正確なメモリヒープ値を表示するには、この時点のタイムライングラフをクリックします。
時間間隔で割り当てられたメモリの量を確認するには、グラフで目的の間隔を選択します。 この間隔で割り当てられたオブジェクトと、これらのオブジェクトを割り当てた関数の詳細を取得するには、 割り当て済み: ... MB リンクをクリックします。 これにより、 メモリ割り当てビューが開きます。
どこから始めればよいかわからない場合は、リアルタイムインスペクションで結果を確認してください。 詳細については、さらに参照してください。
リアルタイムインスペクション
プロファイリング中に、dotMemory はその場でメモリ割り当てデータを分析します。 データを使用して、潜在的なメモリ割り当ての問題を自動的に検出します。
問題が検出されると、dotMemory はタイムライングラフの上部のリストに問題を表示します。 問題が検出された特定の時間間隔を選択するには、リストから問題を選択します。
Gen0 で固定されたオブジェクト
場合によっては、例えばマネージドコードからアンマネージドコード（外部ライブラリなど）を操作する際に、いわゆる 固定オブジェクトをアプリケーションが割り当てることがあります。 このようなオブジェクトはスモールオブジェクトヒープに「固定」され、マネージドコードがその正確な位置に依存するため、ヒープ内で移動することができません。 その結果として、ガベージコレクターがスモールオブジェクトヒープを圧縮できなくなります。 これにより、GC がより頻繁かつ非効率的に発生し、アプリケーション全体のパフォーマンスが低下する可能性があります。
例えば、Gen0 には次のようなオブジェクト構成があります: [A][B][Pinned][C][D]。 [A] と [B] のオブジェクトは、 [Pinned] オブジェクトがヒープから削除されるまで回収できません。
dotMemory は、マネージヒープの Gen0 セグメントに固定されたオブジェクトの割り当てを自動的に検出できます。
固定されたオブジェクトの考えられる原因:
fixedブロックを使用して、ピン留めされたオブジェクトを意図的に作成できます。unsafe { var buffer = new byte[2000]; fixed (byte* ptr = buffer) { ... } }オブジェクトに
GCHandleを作成して、ガベージコレクションを防止します。var buffer = new byte[2000]; var gCBuffer = GCHandle.Alloc(buffer, GCHandleType.Pinned);
可能な解決策：
可能であれば、 stackalloc を使用してバッファをヒープではなくスタック上に割り当てることを検討してください：
var buffer = stackalloc byte[2000];バッファに固定されたオブジェクトが含まれている場合は、スモールオブジェクトヒープではなくラージオブジェクトヒープに割り当てる方が合理的です。 これを行うには、バッファーを 84KB より大きくします。
高い GC 圧力
高い GC 圧力は、ガベージコレクションが頻繁に実行され、かなりの時間がかかる状況です。 つまり、あるサンプルの特定の時間間隔で、ガベージコレクションに費やされた時間が全体の実行時間の 30% を超える場合。
典型的な原因:
プログラムは、ループ内のクロージャなど、短命のオブジェクトを多数作成します。
プログラムは メモリ不足に近いです。
考えられる解決策は、頻繁な割り当てを防ぐためにコードを修正することです。 この一連のブログ投稿で、このような問題の例をさらに見つけることができます。
速い LOH 成長率
ラージオブジェクトヒープ（LOH）は、ラージオブジェクト（> 84 KB）を格納するマネージヒープの特別なセグメントです。 dotMemory は、LOH の成長をリアルタイムで追跡します。 LOH の成長が速すぎると、LOH が大幅に断片化され、 OutOfMemory 例外がスローされる可能性があります。
典型的な原因:
Dictionary、 List、 HashSet、 StringBuilder などの動的サイズのコレクションには次の特徴があります。コレクションのサイズが現在の上限を超えると、.NET がコレクションのサイズを変更し、メモリ上でコレクション全体を再定義します。
考えられる解決策は、サイズ変更が必要な場合の数を減らすことです。 必要なサイズを予測し、このサイズ以上でコレクションを初期化してください。
収集されたスナップショット
この領域には、プロファイリング中に収集されたすべてのスナップショットに関する短いレポートが含まれています。 各レポートでは次のことが可能です。
* あなたのアプリによって要求されたメモリの 合計 についての詳細情報を取得します。 合計 値（灰色のバー）は以下から構成されています。
管理されていないメモリ: 管理されたヒープ外に割り当てられ、ガベージコレクターによって管理されていないメモリ。 通常、これは .NET CLR、動的ライブラリ、グラフィックスバッファーなどに必要なメモリです。 このメモリ部分はプロファイラーで分析できません。
管理されていないメモリを表示する チェックボックスをオフにすると、アンマネージメモリのサイズが 合計 値から差し引かれます。
.NET、合計 (アウトライン付きの灰色のバー): 割り当てられたオブジェクト間の空き領域を含む、アプリによって使用されるマネージドヒープ内のメモリの量。 詳細については、下のイメージを参照してください。
使用される .NET (濃い灰色のバー): 空き領域を除く、アプリによって使用されるマネージドヒープ内のメモリの量。 これは、.NET で操作できる唯一のメモリ部分です。
スナップショット名をクリックして スナップショットビューでスナップショットを開きます。
.png "名前の変更")
ボタンを使用してスナップショットの名前を変更します。解析のためにヒープ内のすべてのオブジェクトを開きます（[ オブジェクトのサイズ ] オブジェクト リンクを使用）。 この場合、「すべてのオブジェクト」オブジェクトセットが 型別にグループ化ビューで開かれます。
分析のためにマークされたオブジェクトを開きます（マークされたオブジェクト リンクを使用）。 「マークされたオブジェクト」オブジェクトセットが タイプ ビューで開かれます。 オブジェクトのマーキング方法については、セクション Marking an Instance で詳しく見ることができます。
プロファイリングセッションの開始からスナップショットを取得する瞬間までにアプリによって生成されたメモリ割り当てを表示します（メモリ割り当て リンクを使用）。 トラフィックの分析のセクションで、メモリ割り当ての分析について詳しく学びましょう。
スナップショット比較領域
2 つのスナップショットを比較するには、 比較領域 にドラッグするか、各スナップショットの 比較に追加 をクリックします。 スナップショットの比較方法については、セクション Comparing Snapshots で詳しく見ることができます。