問題タブ [large-object-heap]

ラージオブジェクトヒープとGC第3世代オブジェクトの違いは何ですか？

私のアプリケーションでは、大きなファイル（約250 MB）をメモリにロードする必要があります。ユーザーがファイルを表示するように要求したときに、怠惰な方法でロードしています。その後、ユーザーがファイルにアクセスしようとするたびに、ファイルはすでにメモリにあるため、すぐに表示できます。したがって、問題はガベージコレクションにあります...ロードするすべてのファイル、WeakReferenceを介してロードしていますが、テストしました。数回テストしましたが、約3GBをメモリにロードできました（アプリが使用できなくなるよりも） ）、しかしGCは発生しませんでした。GC.Collect（2）を呼び出すことができないのは、呼び出す時間を決定できないためです。そのため、GCに適切なタイミングでメモリ（弱参照）を収集するように指示する方法（くそー、3GBが多すぎる... GCは彼の仕事をしていません）それを解決するのは暑いですか？本当に遅延読み込みが必要です、

.NETWindowsサービスでSystem.OutOfMemory例外が発生しています。何が原因なのかわかりません。ラージオブジェクトヒープの断片化が疑われますが、よくわかりません。どうすれば仮説を検証できますか？

あらゆる種類のデバッガーを使用できますが、デバッガーで何を探す必要がありますか？

ありがとう

アプリケーションで大きなサイズのオブジェクト (>85000 バイト) の割り当て/割り当て解除を頻繁に行う必要がある場合、最終的にはメモリの断片化が発生し、アプリケーションはメモリ不足の例外をスローします。

この問題の解決策はありますか、それとも CLR メモリ管理の制限ですか?

大きな文字列 (85kb 以上) は、大きな配列のように大きなオブジェクト ヒープの断片化を引き起こす可能性がありますか?

大量のデータをチャンクで転送するC＃4.0アプリケーション（単一のプロデューサー/単一のコンシューマー）があります。新しいメモリ割り当てはありませんが、しばらくするとメモリが不足します。

Redgateメモリプロファイラーを使用してメモリのプロファイルを作成しましたが、そこには多くの空きメモリがあります。断片化のため、空きメモリを使用できないと表示されます。

バッファとしてブロッキングコレクションを使用し、メンバーとしてバイト配列を使用します。

管理されたメモリの断片化を回避するにはどうすればよいですか？

私は知っています、それは実装の詳細であり、一部の人々はそれらに興味を持つことは禁じられていると考えています. それにもかかわらず、私は次の参照と確認を見つけたいと思っています。

1. ラージ オブジェクト ヒープは、セグメント内のホールの空​​きリストを維持します。これを使用して、大きなオブジェクトの割り当て要求を満たします。また、そのような割り当ては、小さなオブジェクト ヒープからの通常の (割り当てポインターのみが増加する) 割り当てよりも高価になる可能性があることを意味しませんか? 参照

2. 32 ビット プロセスでは、セグメント サイズの下限は 16MB です。64 ビット プロセスのサイズ制限はどのくらいですか?

注意: この質問は、適切なオブジェクト設計 (プーリング) ソリューションを求めているわけではありません。

数秒で多数のオブジェクトを保持するアプリケーションがありDictionary、そのうちのいくつかはアプリの有効期間中に継続的に成長します (多くの商品と継続的に成長する注文/取引を伴う取引アプリケーション)。

OutOfMemoryException大きなオブジェクト ヒープの断片化が原因で、s に問題が発生しています。

これに対抗するために、すべてのリーフ ディクショナリが LOH に割り当てられるほど大きくない 2 レベルのディクショナリとして実装される「大きな」ディクショナリを作成しようとしました。単一のバケットが大きくなりすぎたときに辞書全体を再ハッシュする必要がないように、一貫したハッシュ アルゴリズムを使用しました。コンシステント ハッシュ「サークル」はTreeDictionary、C5 コレクション ライブラリからのものです。

私の質問は、C# 用のより良いデータ構造 (または、おそらく私が説明したもののより良い実装) はありますか?

アップデート

これは「大きな」辞書の実装です: https://gist.github.com/956621

LOH ヒープのしきい値も、各ディクショナリ エントリまたはスケーリング アルゴリズムのサイズも仕様に含まれていないため、絶対確実ではないことは理解しています。ただし、これは現在、アプリケーションが日中に爆発するのを避けるために考えられる最善の方法です.

HttpHandler頻繁に呼び出される があります。それはEntity Frameworkそのタスクを達成するために使用します。

w3p.exeこの Web アプリケーション (別のアプリケーション プールがあります) の使用メモリの増加が遅いです。私が使用ANTS memory profilerしたところ、空きメモリがたくさんあります（LOH）。ANTSこれらはGC rootオブジェクトだと言います。私は自分のコードをチェックしましたが、いくつかintあり、string結果としてLOH!

リーク元をたどりましたが、残念ながらプロパティSystem.Objectが多いタイプです。nullまた、LinkedList、いくつかHashTableの 、および がありWeakHashTableます。

このオブジェクトを見つけて修正するにはどうすればよいLOHですか? of を返すtrueのはどうですか？IsReusableHttpHandler

多くの byte[] 配列 (それぞれ約 1 ～ 2 MB) を生成し、それらにデータを入力してから、参照を破棄するループがコードに含まれています。そのため、参照は短期間しか保持されていませんが、プライベート ワーキング セットが成長していることがわかります。

ここで、ループ後に大きな配列 (~ 400 MB) を割り当てようとすると、メモリ不足の例外が発生する可能性がありますか? それとも、割り当てによって GC が一時データを収集するように強制されますか?

ありがとう！