問題タブ [large-object-heap]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
1887 参照

c# - 大きなオブジェクト ヒープ内の大きな文字列は問題を引き起こしますが、いずれにしても最終的には文字列になる必要があります

私はこの質問hereからフォローアップしています

私が抱えている問題は、主に文字列である MSMQ からの大きなオブジェクトがいくつかあることです。これらのオブジェクトがラージ オブジェクト ヒープ (LOH) で作成され、したがって断片化されていることにメモリの問題を絞り込みました (プロファイラーの助けを借りて確認しました)。

上に投稿した質問では、主に文字列を文字配列に分割するという形でいくつかの回避策を得ました。

私が直面している問題は、文字列処理の最後に (どのような形式であっても)、その文字列を制御できない別のシステムに送信する必要があることです。そこで、この文字列を LOH に配置する次の解決策を考えていました。

  1. それぞれ 85k 未満の char 配列の配列として表します (LOH に配置されるオブジェクトのしきい値)
  2. 送信側で圧縮し(つまり、ここで説明している受信側のシステムで受信する前に)、サードパーティシステムに渡す前にのみ解凍します。

私が何をするにしても - 何らかの方法で - 文字列は完全でなければなりません (char 配列や圧縮はありません)。

私はここで立ち往生していますか?管理された環境を使用することがここで間違いだったのではないかと考えており、弾丸をかじって C++ のような環境に移行するべきかどうかを考えています。

ありがとう、ヤニス

編集:ここに投稿されたコードに問題を正確に絞り込みました

通過する大きな文字列は LOH に配置されます。メッセージを受け取った時点からすべての処理モジュールを削除しましたが、メモリ消費の傾向は変わりません。

したがって、この WorkContext がシステム間で受け渡される方法を変更する必要があると思います。

0 投票する
2 に答える
330 参照

c# - オブジェクトはラージオブジェクトヒープに配置されますか?

CLRがオブジェクトをラージオブジェクトヒープに配置する場合、それは「オールオアナッシング」取引ですか?クラス/構造体のメンバーは「分割」され、異なるヒープに配置されていますか?

TwoSmallObjects合計サイズが85,000バイトを超えるため、ラージオブジェクトヒープに配置されますか?両方のメンバーが個別にしきい値を下回っていても?どうMixedSizeObjectsですか?

0 投票する
3 に答える
1879 参照

c# - RegEx、StringBuilder、およびラージオブジェクトヒープの断片化

LOHフラグメンテーションを発生させずに、大きな文字列で(一致を見つけるために)多くの正規表現を実行するにはどうすればよいですか?

これStringBuilderは.NETFramework4.0なので、使用しているのでLOHには含まれていませんが、RegExを実行する必要があるとすぐに呼び出す必要がありStringBuilder.ToString()ます。つまり、LOHに含まれることになります。

この問題の解決策はありますか?このような大きな文字列や正規表現を処理する長時間実行アプリケーションを使用することは事実上不可能です。

この問題を解決するためのアイデア:

この問題について考えているうちに、私は汚い解決策を見つけたと思います。

ある時点で私は5つの文字列しか持っておらず、これらの5つの文字列(85KBより大きい)はに渡されRegEx.Matchます。

新しいオブジェクトがLOHの空のスペースに収まらないために断片化が発生するため、これで問題が解決するはずです。

  1. PadRightすべての文字列を最大にします。許容サイズ、たとえば1024KB(これを行う必要がある場合がありますStringBuider
  2. そうすることで、前の文字列はすでにスコープ外にあるため、すべての新しい文字列はすでに空になったメモリに収まります
  3. オブジェクトのサイズは常に同じであるため、断片化は発生しません。したがって、特定の時間に1024 * 5のみを割り当て、LOHのこれらのスペースはこれらの文字列間で共有されます。

この設計の最大の問題は、他の大きなオブジェクトがLOHでこの場所を割り当てると、アプリケーションが1024 KBの文字列を大量に割り当て、さらに悪い断片化が発生する場合にどうなるかを推測します。fixedステートメントは役立つかもしれませんが、固定メモリアドレスにない新しい文字列を実際に作成せずに、固定文字列をRegExに送信するにはどうすればよいですか?

この理論について何か考えはありますか?(残念ながら、問題を簡単に再現することはできません。通常、メモリプロファイラーを使用して変更を観察しようとしていますが、このためにどのような分離されたテストケースを作成できるかわかりません)

0 投票する
5 に答える
44449 参照

.net - ラージ オブジェクト ヒープの理由とその重要性

Generations と Large object heap について読みました。しかし、大きなオブジェクト ヒープを持つことの重要性 (または利点) をまだ理解できていません。

大きなオブジェクトを格納するために CLR が第 2 世代 (大きなオブジェクトを処理するには Gen0 と Gen1 のしきい値が小さいことを考慮すると) に依存していた場合、(パフォーマンスまたはメモリの点で) 何が問題になる可能性がありますか?

0 投票する
4 に答える
2666 参照

java - ラージオブジェクトセットのJavaメモリ割り当て

現在、Javaでゲームエンジンに取り組んでいますが、たとえば、ヒープに大量のオブジェクトを割り当てると、パフォーマンスの問題が発生します。

上記のコードは、割り当てのせん断レベルが原因で、開始時にフレームが大幅に低下します。不足しているものや、この問題を解決するためのテキストがあるかどうか疑問に思いました。

アップデート

GLParticleクラスの要求されたデータメンバー。

ありがとうゲイリー

0 投票する
1 に答える
236 参照

.net - 64 ビット システムでの LOH フラグメンテーションの悪さ

大きなオブジェクト ヒープの断片化は、32 ビット システムでは明らかな問題です。これは、アドレス空間が比較的小さいため、アドレス空間が不足して OutOfMemoryException が「すぐに」発生する可能性があるためです。

64 ビットのアドレス空間ははるかに大きいため、アドレスが不足することはあまり問題になりません (このシナリオでは)。したがって、主な問題は、これがマシンのパフォーマンスにどのように影響するかです。

LOH の空き領域は予約されていますがコミットされていませんか? それともコミットされたままですか? コミットされていても、未使用の場合はページアウトされ、実際には物理メモリを占有しませんか?

私たちの特定のシナリオでは、十分なアドレス空間がないために OOM にヒットする心配はあまりありません。これは、1. しばらく時間がかかり、2. これが発生するとサービスが自動的に再起動されるためです。

私たちは、これが実行しているマシンの全体的なパフォーマンスに与える影響についてより懸念しています.

誰でもこの主題に光を当てることができますか?

0 投票する
1 に答える
974 参照

java - EOFExceptionをスローする大きなオブジェクトを送信するJavaActiveMQ

AciveMQを使用して大きなJavaオブジェクトを送信しているときにjava.io.EOFExceptionを取得します。

以下は私が送ろうとしている大きなオブジェクトです

}

以下はstackTraceです。

適切なオブジェクトを送信していることを示すプロデューサー。しかし、消費者側では、例外を超えています。

ActiveMQConnectionFactoryを使用して以下の構成も試しました

私にいくつかの解決策を提案してください。前もって感謝します。

0 投票する
1 に答える
12666 参照

jvm - -XX:+UseLargePagesが有効になっているJVMを作成できません

現在14GBのヒープで実行されているJavaサービスがあります。-XX:+ UseLargePagesオプションを試して、これがシステムのパフォーマンスにどのように影響するかを確認したいと思います。適切な共有メモリとページ値を使用して、Oracleの説明に従ってOSを構成しました(これらはオンラインツールを使用して計算することもできます)。

OSを構成すると、予想される量のメモリが巨大なページとして割り当てられていることがわかります。ただし、-XX:+UseLargePagesオプションセットを使用してVMを起動すると、常に次のいずれかのエラーが発生します。

-Xms/-Xmxが巨大なページ割り当てとほぼ等しい場合:

-Xms/-Xmxが巨大なページ割り当てより少ない場合:

ある程度の余裕を持たせてみました。32GBのシステムで、24GBの共有メモリと巨大なページを20GBのヒープで構成されたJVMで使用するために割り当てましたが、現在は14GBしか使用されていません。また、JVMを実行しているユーザーがと一致するグループ権限を持っていることを確認しました/proc/sys/vm/hugetlb_shm_group

誰かが私がどこで間違っているのか、そして次に何を試すことができるのかについてのいくつかの指針を私に与えることができますか?

割り当て/使用率:

  • -Xms/ -Xmx-20GB
  • 使用されるヒープ-14GB
  • /proc/sys/kernel/shmmax-25769803776(24GB)
  • /proc/sys/vm/nr_hugepages-12288

環境:

  • システムメモリ-32GB
  • システムページサイズ-2048KB
  • debian 2.6.26-2-amd64
  • Sun JVM 1.6.0_20-b02

解決

解決策につながる答えを提供してくれた@jfgagneに感謝します。 /proc/sys/kernel/shmall設定(4KBページとして指定)に加えて、Thomasのブログで説明されているようにエントリを追加する必要がありまし/etc/security/limits.confた。ただし、アプリケーションの使用を開始すると、rootユーザーの設定も複製する必要がありました(制限はKBで指定されていることに注意してください)。jsvc

-versionまた、次の引数を使用してJVMを起動することにより、設定をすばやくテストできることにも言及する価値があります。

0 投票する
2 に答える
2292 参照

c# - Protobuf-net でチャンク化されたバイト配列をシリアル化する際のメモリ使用量

私たちのアプリケーションには、特にバイトのチャンクリストを含むいくつかのデータ構造があります(現在は として公開されていますList<byte[]>)。バイト配列を大きなオブジェクト ヒープに配置できるようにすると、時間の経過とともにメモリの断片化が発生するため、バイトをチャンクアップします。

また、独自に生成したシリアライゼーション DLL を使用して、Protobuf-net を使用してこれらの構造をシリアライズすることも開始しました。

ただし、シリアル化中に Protobuf-net が非常に大きなメモリ内バッファーを作成していることに気付きました。ソースコードをざっと見てみると、List<byte[]>後でバッファの先頭に全長を書き込む必要があるため、構造全体が書き込まれるまで内部バッファをフラッシュできないようです。

残念なことに、これは最初にバイトをチャンク化する作業を元に戻し、最終的にはメモリの断片化のために OutOfMemoryExceptions を発生させます (例外は、Protobuf-net がバッファーを 84k を超えて拡張しようとしているときに発生します。 LOH であり、全体的なプロセス メモリの使用量はかなり低いです)。

Protobuf-net の動作に関する私の分析が正しい場合、この問題を回避する方法はありますか?


アップデート

マークの答えに基づいて、私が試したことは次のとおりです。

次に、それをシリアル化します。

ただし、メソッドの下部に向かっProtoWriter.WriteBytes()て呼び出す場所にブレークポイントを設定してにステップインすると、 equals が原因でバッファーがフラッシュされていないことがわかります。DemandSpace()DemandSpace()writer.flushLock1

次のように ABase の別の基本クラスを作成すると:

次ににwriter.flushLock等しい。2DemandSpace()

派生型を扱うために、ここで見逃した明らかなステップがあると思いますか?

0 投票する
3 に答える
690 参照

.net - C# の非常に大きなオブジェクトとマネージド ヒープ

マネージ ヒープよりも大きい非常に大きなオブジェクトを物理メモリに保存しようとするとどうなりますか? たとえば、フィルムのサイズは 4.5 GB で、仮想メモリ (RAM) のサイズはわずか 2 GB です。この場合、ガベージコレクターはどのように機能しますか? (物理的なスペースは十分です)