問題タブ [large-object-heap]

次のクラスがあるとします：

まず、次を割り当てます。

それぞれがb1, c1, d185K 未満であるため、小さなオブジェクト ヒープに割り当てられます。それから私は：

質問 1:のメモリ!DumpHeap -stat使用量にAは、メンバー変数によって占有されているメモリが含まれますか? そうでない場合、実際には何が含まれていますか?
編集: この投稿でこの質問に対する回答が見つかりました: http://blogs.msdn.com/b/tess/archive/2005/11/25/dumpheap-stat-explained-debugging-net-leaks.aspx。Aのメモリ使用量には、が占有するメモリが含まれていないことは理にかなっていb1, c1, d1ます。b1, c1, d1これには、参照自体を格納するために必要なメモリが含まれます。

質問 2:a1大きなオブジェクト ヒープ (サイズがb1 + c1 + d185K を超えると想定) に割り当てられますか? なんで？参照b1, c1, d1は、小さなオブジェクト ヒープ上のオブジェクトを指しています。それでは、なぜa1LOHに座るのでしょうか?

質問 3: ひっくり返してみましょう。のサイズがb185K を超えると、LOH に割り当てられます。しかし、への参照を保存するb1, c1, d1には、数バイトしか必要ありません。a1それが小さなオブジェクト ヒープに割り当てられると 信じているのは正しいですか?

大量のメモリを処理する必要のある分析アプリケーションをC＃で作成しています。メモリ管理を最適化するためにANTSMemoryProfiler7.4を使用しています。そうしているうちに、私が使用している（そして必要な）double [、]配列はすべて、LOHに配置されていることに気付きましたが、これらの配列の最大のものは約24.000バイトです。私の知る限り、オブジェクトは85.000バイトより前に配置しないでください。問題は、これらのdouble [、]配列のインスタンスが約数千あるため、メモリの断片化が多いことです（合計メモリ使用量の約25％は、使用できない空きメモリです）。LOHに格納されているこれらの配列の一部は、サイズがわずか1.036バイトですらあります。問題は、より大規模な分析を実行しなければならない場合があり、LOHの断片化による大量のメモリ損失のために、メモリ不足の例外が発生することです。

定義上大きなオブジェクトであってはならないのに、なぜこれが起こっているのか誰かが知っていますか？

64ビットプロセス内でC＃コードを実行するAzureの役割で、ZIPファイルをダウンロードしてできるだけ早く解凍したいと思います。次のことができると思いました。MemoryStreamインスタンスを作成しMemoryStream、そこにダウンロードしてから、ストリームをZIP処理ライブラリに渡して解凍し、解凍が完了したらストリームを破棄します。このようにして、多くのI/Oを不必要に実行する書き込み-読み取り-書き込みシーケンスを取り除くことができます。

MemoryStreamただし、配列に裏打ちされた0.5ギガバイトの配列は、間違いなく「ラージオブジェクト」と見なされ、ガベージコレクションで圧縮されないラージオブジェクトヒープに割り当てられることを読みました。これは、おそらくこの使用法がMemoryStreamプロセスメモリの断片化と長期的な悪影響につながるのではないかと心配しています。

これは私のプロセスに長期的な悪影響を与える可能性がありますか？

私たちのアプリケーションは、大量のデータ (たとえば、数十から数百メガバイト) に対して配列を継続的に割り当てます。これらのデータは、破棄されるまでの短い時間存続します。

これを単純に行うと、大きなオブジェクト ヒープの断片化が発生し、現在ライブ オブジェクトのサイズが過大ではないにもかかわらず、最終的に OutOfMemoryException でアプリケーションがクラッシュする可能性があります。

過去にこれをうまく管理してきた 1 つの方法は、配列をチャンクアップして、最終的に LOH にならないようにすることです。これは、ガベージ コレクターによってメモリを圧縮できるようにすることで断片化を回避するという考え方です。

最新のアプリケーションは、以前よりも多くのデータを処理し、このシリアル化されたデータを、別の AppDomains または別のプロセスでホストされているアドイン間で非常に頻繁に渡します。以前と同じアプローチを採用し、メモリが常にチャンク化されていることを確認し、大きなオブジェクト ヒープの割り当てを避けるように細心の注意を払いました。

ただし、外部の 32 ビット プロセスでホストする必要があるアドインが 1 つあります (メイン アプリケーションは 64 ビットであり、アドインは 32 ビット ライブラリを使用する必要があるため)。特に重い負荷の下で、大量の SOH メモリ チャンクがすばやく割り当てられ、すぐに破棄されると、チャンク アプローチでさえ 32 ビット アドインを保存するには不十分であり、OutOfMemoryException でクラッシュします。

OutOfMemoryException が発生した瞬間に WinDbg を使用すると、次のようになり!heapstat -inclUnrootedます。

!dumpheap -statこれを見せてください:

これらは、メモリ使用量が過度ではなく、大きなオブジェクト ヒープが予想どおり非常に小さいことを示しています (したがって、ここでは大きなオブジェクト ヒープの断片化を扱っていません)。

しかし、!eeheap -gcこれを示しています：

ここで私を驚かせたのは、最後の SOH ヒープ セグメントが 0x73b41000 で始まっていることです。これは、32 ビット アドインで使用可能なメモリの限界に達しています。

したがって、私がそれを正しく読んでいる場合、私たちの問題は、仮想メモリがマネージ ヒープ セグメントで断片化されていることのようです。

ここでの私の質問は次のようになると思います。

• 私の分析は正しいですか？
• チャンキングを使用して LOH フラグメンテーションを回避するアプローチは合理的ですか?
• 現在見られているように見えるメモリの断片化を回避するための良い戦略はありますか?

私が考えることができる最も明白な答えは、メモリ チャンクをプールして再利用することです。これは実行できる可能性がありますが、メモリのその部分を自分で効果的に管理する必要があるため、むしろ避けたいと思います。

非常に大量のバイナリデータをデータベース（MS SQL）に格納し、EFを介してこのデータベースとやり取りする必要があります。残念ながら、EFはFILESTREAMをサポートしていません（より正確には、ストリーミングサポートはありません）。

そこで、データをチャンクで保存することにしました。チャンクは単なるエンティティタイプです。

まず、チャンクサイズを最適な値（たとえば1 Mb）で制限したいと思いました。
しかし、それから私は大きなオブジェクトとLOHについて思い出しました。

私が理解している限り、すべてのChunk.Contentインスタンスは次の結果（特にメモリの断片化）を伴う大きなオブジェクトと見なされます。したがって、Chunkオブジェクトを集中的に作成すると、最終的に発生しますOutOfMemoryException（これは「24時間年中無休」のアプリケーションであり、そのバイナリデータを操作することがアプリケーションの主な目的です）。

EFを使用しているため、データチャンクにバッファーを再利用できません...
チャンクサイズを小さくして、85Kより小さくする必要がありますか？
それとも妄想ですか？:)

HTTPプロトコルを使用するWCFサービスがあります。特に大きなクエリがシステムにヒットすると、大きな Byte[] が作成され、バッファを経由して HttpChannelListener に到達し、最終的にサービス ホスト自体に到達します。これは、WCF トランザクションが完了した後もそのままです。これにより、ラージ オブジェクト ヒープの断片化が発生し、最終的にアプリケーションで OOM 例外がスローされます。

Byte[] へのパスは次のとおりです: ServiceHost.channelDispatchers.items._items[0].listener.innerChannelListener.typedListener.bufferManager.innerBufferManager.bufferPools[13].pool.globalPool.items._array[0]

システムは、トランザクションにバッファーされた WCF 通信を使用して、信頼性を確保します。

これらの大きなオブジェクトがメモリに残るのを防ぐためにできることはありますか?

最近の 4.5 .NET サポートにより、ユーザーはオブジェクトに 2 GB を超えるメモリを割り当てることができます。これを行うには、ユーザーが app.config ファイルで gcAllowVeryLargeObjects を true に設定すると、問題なく動作します。

ただし、ASP.NET のこの設定を見つけるのに苦労しています。Web サイトでこれが本当にサポートされているかどうかをテストする必要がある Web サイトがあります。VS組み込みサーバーが32ビットプロセスであることは知っています。そのため、ユーザーは単純に Web サイトを起動して大規模なアレイをテストすることはできません。

これは ASP.NET でも可能ですか? IIS7 を使用して Web サイトをホストしています。

WCF サーバーから大きなバイト配列を返す必要があります。

問題は-そのような配列を返すために-作成する必要がある-そしてそのような配列を作成するとき-それは自動的にラージオブジェクトヒープに移動します-つまり、サービスにストレスがかかると-実際の問題が発生しますメモリの使用と管理。

大規模なマネージド バイト配列の使用を避けるために、アンマネージド メモリを使用することを考えましたが、それでも、WCF サービスからそのような配列を返すにはどうすればよいでしょうか?

マネージ バイト配列を実際に作成することを含まない WCF サービスからバイトの「ストリーム」を返す方法はありますか? WCF 自体が BufferManager を使用していることはわかっています。そのため、アンマネージ メモリを読み取り、そのバッファ管理を使用して送信前に格納するだけであれば、問題が発生しないことを願っています。

ASP.NET ワーカー プロセスが断続的に CPU を 100% 使用している状況があります。perfmon の結果とメモリ ダンプを分析したところ、ガベージ コレクタが CPU 時間を大量に使用していることがわかりました。

WinDbg を使用して、LOH が HTML ページの完全なページを含む文字列でいっぱいであることを確認しました。文字列への!gcrootでルートが見つからないことがよくあります。問題は、これが ASP.NET アプリケーションでは正常なのか、それとも Web サイトの構築方法に固有のものなのかということです。

この ASP.NET Web サイトは Sitecore ベースの Web サイトであることに注意してください。Sitecore が HTML 出力をキャッシュすることは理解していましたが、私の理解では、Sitecore はページ全体をキャッシュするのではなく、レンダリング レベルでのみキャッシュします。

Spring 3.1.0.Final を使用し、WAS 6.1 にデプロイされたポートレット アプリケーションがあります。

過去に Spring MVC を使用した複数のポートレットがありました。これは Spring 3 を使用した最初のポートレットです。コードのほとんどの場所で注釈とオートワイヤーを使用しています。

このアプリケーションがサーバーにデプロイされると、ベース ヒープの使用量が 25 MB 以上増加しました。

Jprofiler を使用してプロファイリングを行ったところ、StringHTTPMessageConverter がすべての文字セットをメモリにロードし、約 14 MB のメモリを占有していることがわかりました (com.ibm.nio.charset.Charset がメモリを消費します)。

これはポートレットアプリであるため、構成で明示的に定義された org.springframework.web.portlet.mvc.annotation.Ann otationMethodHandlerAdapter Bean があり、 org.springframework.web.servlet.mvc.annotation.An otationMethodHandlerAdapter ではありません。

これは私がこれまでに試したことです

1) StringHttpMessageConvertor の設定を変更する

私の構成で次のBeanを定義しました

これでは運が悪い。

2）構成ファイルで定義しました。いくつかの投稿で提案されているように、タグをコメントアウトして上記の構成も試しました。しかし、運がありません。

3) いくつかのフォーラムで提案されているように、BeanPostProcessor を書き込もうとしましたが、StringHttpMessageConverter クラスが見つかりませんでした。

構成で org.springframework.web.servlet.mvc.annotation.An otationMethodHandlerAdapter を明示的に定義する必要がありますか?

私の質問は

1) すべての文字セットがメモリに読み込まれないようにする方法はありますか?

2) また、ベース ヒープでの 25 MB のジャンプは正当化できますか? Spring 3.1.0 の通常のメモリフットプリントは?

アイデアが不足しています。Spring フレームワークの微調整に関するヘルプをいただければ幸いです。

感謝と敬意

ラヴィグ