問題タブ [large-object-heap]

私は次のアプリケーションを持っています：

• ターゲット C# 6
• ターゲット .net 4.5.2
• Windows フォーム アプリケーションである
• AnyCPU モードでビルドします。
• 64 ビットの管理されていないメモリにアップグレードできない古い 32 ビット ライブラリを利用
• サードパーティの制御ベンダーである DevExpress を使用
• 毎日何ギガバイトものデータを処理してレポートを生成

多くのプロットを含むジョブで数時間使用した後、アプリケーションは最終的にメモリ不足になります。コードで見つかった多くのリークのクリーンアップにかなりの時間を費やし、パフォーマンス カウンターによると、最悪の場合、常に 400,000K を超えるメモリを使用する可能性がある状態にプロジェクトを取得しました。データはジャグ配列で処理され、Large Object Heap の問題が回避されるため、このデータを処理しても現時点では問題は発生していません。

前回これが発生したとき、ユーザーは最大 305,000K のメモリを使用していました。アプリケーションの「メモリ不足」が原因で、エラー ダイアログが表示される MessageBox にエラー アイコンを描画することさえできず、通常はアイコンが表示されるスペースがすべて黒くなります。

これまでのところ、これをクリーンアップするために次のことを行いました。

• Windows フォームは、Disposed イベントを利用して、リソースが確実にクリーンアップされるようにします。dispose は、必要に応じて手動で呼び出されます。
• ビジネス オブジェクトは IDisposable を使用して参照を削除します
• ANTS メモリ プロファイラと SciTech メモリ プロファイラを使用した検証済みのクリーンアップ。メモリ使用量が少ないということは、そうではないことを示唆していますが、何か役立つものがあるかどうかを確認したかったのですが、できませんでした。
• GCSettings.LargeObjectHeapCompactionMode プロパティを利用して、Large Object Heap (LoH) で断片化される可能性のあるデータの処理から断片化を取り除きました。

この点に到達するために私が使用したほぼすべての記事は、メモリ不足が実際には連続したアドレス空間の不足を意味することを示唆しており、使用中の量を考えると、私はこれに同意します. 私が理解していること（そしておそらく非常に間違っていること）から、プロセスが進むにつれてガベージコレクタがこれをクリアしてスペースを空けるということなので、この時点で何をすべきかわかりません.LoHを除いて. .net 4.5.1 で導入された新しい LargeObejctHeapCompactionMode プロパティを使用して手動でクリーンアップしました。

ここで何が欠けていますか？64 ビット バージョンを作成する夢さえも持っていない独自のアルゴリズムを含む古い 32 ビット ライブラリが原因で、64 ビットにビルドできません。ここで制御不能になっているものを正確に特定するために、これらのプロファイルに使用すべきモードはありますか?

このアドレス空間をクリアできない場合、これはすべての c# アプリケーションが最終的に「メモリ不足」で実行されることを意味しますか?

CLR プロファイラーを使用してプログラムのメモリ使用量をチェックしていますが、LOH の割り当てに関心があります。基本的に、1 MB サイズのファイルを 10 個ずつ Azure データ レイク サービス ファイルに並列に割り当てています (concurrentAppend API を使用)。理論的には、LOH のサイズは 10 MB ですよね？レポート プレビュー (画像 1) では、LOH ヒープ バイトが 3.195 MB であることがわかります。アドレスでオブジェクトをチェックすると(画像2) -> LOHは正確に10MBを割り当てます(カーソルをLOHバーの上に動かしてチェックし、それぞれ1MBのsystem.byte[]データを持つ10個のアドレスを見つけました。

プレビュー レポートで 3.199 MB になるのはなぜですか??