分析の概要

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% を超える場合。

典型的な原因:

• プログラムは、ループ内のクロージャなど、短命のオブジェクトを多数作成します。

• プログラムはメモリ不足に近いです。

考えられる解決策は、頻繁な割り当てを防ぐためにコードを修正することです。この一連のブログ投稿で、このような問題の例をさらに見つけることができます。

• アプリのパフォーマンスを向上させる珍しい方法: ボクシングとコレクション (英語)

• アプリのパフォーマンスを向上させる珍しい方法: ストリング (英語)

• アプリのパフォーマンスを向上させる珍しい方法: ラムダと LINQ(英語)

• dotMemory による無効なメモリ使用量の分析 (英語)

• 文字列インターン: dotMemory による効果的なメモリ管理 (英語)

速い LOH 成長率

ラージオブジェクトヒープ（LOH）は、ラージオブジェクト（> 84 KB）を格納するマネージヒープの特別なセグメントです。dotMemory は、LOH の成長をリアルタイムで追跡します。LOH の成長が速すぎると、LOH が大幅に断片化され、OutOfMemory 例外がスローされる可能性があります。

典型的な原因:

Dictionary、List、HashSet、StringBuilder などの動的サイズのコレクションには、次の詳細があります。コレクションサイズが現在の境界を超えると、.NET はコレクションのサイズを変更し、メモリ内のコレクション全体を再定義します。

考えられる解決策は、サイズ変更が必要な場合の数を減らすことです。必要なサイズを予測し、このサイズ以上でコレクションを初期化してください。