問題タブ [large-object-heap]

さて、私はしばらくASP.NETプロジェクトに取り組んできましたが、プロジェクトが含まれるデータの点でどんどん大きくなっているので、私を悩ませているいくつかの悪いデザインの選択をしたようです。

.NETメモリ管理について読んだ後、私は潜在的な理由のすべてのセットを特定したと思います。私がやっていることは特に特別なことではないので、私がやりたいことを達成するための標準的なパターンが欠けているのではないかと思います。

したがって、1から20000の結果を生成する（やや高価なクエリ）があります。以降のリクエストでは、結果セットをページングしている可能性があるため、この結果をセッションに保存します。セッションはInProcです。不思議なんだけど：

• a）結果を保存するb）セッションにc）処理中に保存することは理にかなっていますか？（a）の速度が欲しいです。ユーザーが保存するよりも効率的な方法があるかどうか（b）、より洗練された状態サーバーを使用する場合は、遅くなりませんか（c）？または、セッションが期限切れになるまで最後の結果セットをRAMに保持するのではなく、これらの大きなオブジェクトをより迅速に破棄するという解決策でしょうか？

• 〜20000行を超える結果セットがLOHを台無しにする可能性がある場合、それを回避する一般的な方法はありますか？

私はこの質問が少し過小評価されていることを知っています。全体的な設計に欠陥がある可能性があることに気づきました（スケーラビリティーに関して）。そして、どれだけ欠陥があるかを正確に見積もろうとしています。それにもかかわらず、これを一般的に有用な質問に変える標準パターンに関するいくつかのヒントが収集されることを願っています。

私はいくつかのかなり大きな文字列を含むデータデータベースを持っており、それぞれがシリアル化された階層データコレクションを保持しています（データはVB6との相互作用を可能にするためにバイナリストリームとしてではなく文字列として保存されます）。私の知る限り、85,000バイトを超える文字列を返すデータベースクエリは、すぐにその文字列をラージオブジェクトヒープにスローします。文字列がすぐに小さな断片に分割され、大きなオブジェクトが短命になる場合、それらのオブジェクトが大きなオブジェクトヒープに移動し、次のLOHコレクションまで無駄にそこにとどまるのを回避する方法はありますか？私はLOHオブジェクトを再利用する必要があることを読み続けていますが、このコンテキストでそれをどのように行うのかわかりません。

編集-私はDataReaderでSqlClientオブジェクトを使用しています。

私はC＃アプリケーションに取り組んでいますが、多くのオブジェクトがラージオブジェクトヒープでメモリ割り当てを取得しているため、このアプリケーションはメモリ不足に直面しています。

私のC＃アプリケーションは（文字列オブジェクトとして）多くの大きなファイルで動作する必要があるため、この文字列型オブジェクトのメモリは、大きなオブジェクトヒープから何度も割り当てられます（したがって、LOHの断片化につながります）。

文字列は不変オブジェクトであるため、LOHの新しいメモリは常にこのオブジェクトに割り当てられます。私の質問は、大きなオブジェクトヒープにメモリを事前に割り当てて、常に同じメモリを文字列オブジェクトに割り当てる方法はありますか。

詳細は次のとおりです。前述したように、私はこれらの大きなファイルを処理しています。処理を行うには、文字列に変換する必要があります。stringBuilderを使用している場合でも、Stringに変換するとすぐに、このための別のメモリがLOHに割り当てられるため、あまり役に立ちません。

したがって、メモリに100 KBを割り当てることを期待していました。新しいファイルを読み取って文字列に変換するたびに、これらの100KBが割り当てられます。

世代別ガベージ コレクションによってパフォーマンスが向上することは理解しています。

1. Gen2 以外のコレクションでは、すべてのオブジェクトを最大 2 回移動する必要があり、Gen2 コレクションはまれです。
2. システムが Gen0 コレクションを実行していて、オブジェクト (Gen1 または Gen2) が最後の Gen0 コレクション以降に書き込まれていない場合、システムはそのオブジェクトをスキャンしてその中の参照にタグを付ける必要はありません (それらはすべて Gen1 であるため)。または Gen2)。同様に、システムが Gen1 コレクションを実行している場合、最後の Gen1 コレクション以降に書き込まれなかったオブジェクトは無視できます。ガベージ コレクションの作業のほとんどはオブジェクトのスキャンであるため、スキャン時間の短縮は大きなメリットです。

Gen1 ガベージ コレクションから大きなオブジェクトを除外すると、どのようなパフォーマンス上の利点があるのでしょうか? 大きなオブジェクトは、ガベージ コレクターによってスキャンされても再配置されません。Gen1 コレクションは、オブジェクトの書き込みを介在させずに 2 つの連続する Gen1 コレクションが発生しない限り、または発生するまで、そのコンテンツをスキャンする必要があると予想されます。

私が見ていないパフォーマンス上の利点はありますか?

.NET メモリ管理がこのような大きなオブジェクト ヒープを作成するのはなぜですか? ほとんどが空っぽのようです。これは気にする必要がありますか？

以下のデータは、実際にはアプリケーション内に 179 MB 相当のラージ オブジェクトしかないことを意味しますか? 1171428792 (Heap0 LOH) から 983396616 (フリー LOH) を引くと、179 MB になります。

以下の情報は、w3wp.exe、つまり ASP.NET プロセスで作成されたダンプ ファイルで WinDbg を使用して収集されました。このプロセスは、Windows 2008 64 ビット オペレーティング システムでホストされています。このアプリケーションは、Microsoft .NET Framework 4.0 および ASP.NET MVC 3 を使用して構築されています。

.NET3.5アプリケーションを使用しています

• 関数が100万回実行されている
• 1MB以上の文字列（異なるサイズの文字列）で検索、置換、正規表現の操作を実行します

アプリケーションのプロファイルを作成すると、これらの文字列がLOHに保存されていることを確認できますが、後でGCによって再利用されるため、特定の時点で最大10個の文字列のみがLOHにあります（10スレッドが実行されています）。

私の理解では、これらの大きな文字列はLOHに配置され、GCによって再利用されますが、割り当て場所が原因で（LOHにあるため、圧縮されないため）、断片化が発生します。これは、操作中にメモリリークがないにもかかわらず発生しています。

約100K回は問題を引き起こしませんが、100万回以上に達すると、メモリ不足の例外が発生します。

私はANTSMemoryProfilerを使用していますが、これは初期の実行で得られた結果です。

1. 手元のデータに基づいて、私の診断は正しいと思いますか？
2. もしそうなら、どうすればこのLOHフラグメンテーションの問題を解決できますか？私はそれらの文字列を処理する必要があり、それらは大きな文字列です。それらを分割してそのように処理する方法を見つける必要がありますか？その場合、分割文字列で正規表現などを実行することは非常に困難です。

大きなオブジェクト ヒープを視覚化するツールはありますか?

現在、ANTS Memory Profiler を使用しています。LOH が断片化されていることがわかりますが、実際には断片化を確認できません (Windows Defrag ツールがディスクの断片化を視覚化するように、LOH を視覚的に表現したいと思っています)。

重複の可能性：
StringBuilderの容量はどのように変化しますか？

StringBuilderが割り当てられた後、85kを超えるまでに成長したとすると、ラージオブジェクトヒープに移動されますか？

何日も何ヶ月も再起動せずに実行するはずの Windows コンソール アプリがあります。アプリは、MSMQ から「作業」を取得して処理します。作業チャンクを同時に処理する 30 のスレッドがあります。

MSMQ からの各ワーク チャンクは約 200 KB で、そのほとんどは 1 つの String オブジェクトに割り当てられます。

これらの作業チャンクを約 3 ～ 4 千処理した後、アプリケーションのメモリ消費量が途方もなく高く、1 ～ 1.5 GB のメモリを消費していることに気付きました。

私はプロファイラーを介してアプリを実行し、このメモリのほとんど (おそらくギグ程度) が大きなオブジェクト ヒープで使用されていないことに気付きましたが、構造は断片化されています。

これらの未使用 (ガベージ コレクション) バイトの 90% が以前に割り当てられた文字列であることがわかりました。私は、MSMQ から入ってくる文字列が割り当てられ、使用され、割り当てが解除されたため、断片化の原因になっているのではないかと疑い始めました。

GC.Collect(2 または GC.Max...) のようなものは、大きなオブジェクト ヒープを gc しますが、圧縮しないため、役に立たないことを理解しています (これが問題です)。したがって、これらの文字列をキャッシュして何らかの方法で再利用する必要があると思いますが、文字列は不変であるため、StringBuilders を使用する必要があります。

私の質問は次のとおりです。基本的な構造を変更せず (つまり、MSMQ を使用してこれを変更することはできません)、LOH の断片化を避けるために毎回新しい文字列を初期化することを回避する方法はありますか?

ありがとう、ヤニス

更新: これらの「作業」チャンクが現在どのように取得されているかについて

現在、これらは MSMQ に WorkChunk オブジェクトとして格納されています。これらの各オブジェクトには、Contents という文字列と、Headers という別の文字列が含まれています。これらは実際のテキスト データです。必要に応じてストレージ構造を別のものに変更したり、必要に応じて基になるストレージ メカニズムを MSMQ 以外のものに変更したりできます。

ワーカーノード側では現在行っています

WorkChunk チャンク = _Queue.Receive();

したがって、この段階でキャッシュできるものはほとんどありません。どういうわけか構造を変更すれば、少し進歩できると思います。いずれにせよ、この問題を解決しなければならないので、何ヶ月もの作業を無駄にしないために必要なことは何でもします。

更新:以下の提案をいくつか試してみたところ、この問題はローカル マシン (Windows 7 x64 および 64 ビット アプリを実行) では再現できないことに気付きました。これは物事を非常に困難にします-誰かが理由を知っていれば、この問題をローカルで解決するのに本当に役立ちます.