77

Java で 12 GB 以上の非常に大きなヒープを使用した経験のある人はいますか?

  • GC はプログラムを使用不能にしますか?
  • どのGCパラメータを使用していますか?
  • これには、どの JVM、Sun、または BEA が適していますか?
  • このような条件下で、Linux と Windows のどちらのプラットフォームのパフォーマンスが優れているでしょうか?
  • Windows の場合、64 ビット Vista と XP では、このような高いメモリ負荷の下でパフォーマンスに違いはありますか?
4

14 に答える 14

75

アプリケーションがインタラクティブではなく、GC の一時停止が問題にならない場合、64 ビット Java が非常に大きなヒープ (数百 GB であっても) を処理するのに問題はありません。また、Windows でも Linux でも、安定性の問題は確認されていません。

ただし、GC の一時停止を低く抑える必要がある場合、事態は非常に厄介になります。

  1. デフォルトのスループットである stop-the-world GC は忘れてください。中程度のヒープ (< ~30 GB) の場合は数十秒間、大きなヒープ (> ~30 GB) の場合は数分間、アプリケーションを一時停止します。また、より高速な DIMM を購入しても役に立ちません。

  2. おそらく最善の策は、-XX:+UseConcMarkSweepGC によって有効化される CMS コレクターです。CMS ガベージ コレクタは、最初のマーキング フェーズと再マーキング フェーズでのみアプリケーションを停止します。4 GB 未満のような非常に小さなヒープの場合、これは通常問題にはなりませんが、大量のガベージと大きなヒープを作成するアプリケーションの場合、再マーキング フェーズにかなり長い時間がかかる場合があります。 、しかし、非常に大きなヒープでは依然として問題になる可能性があります。

  3. CMS ガベージ コレクターの速度が不十分で、Tenured 世代がいっぱいになる前に操作を終了できない場合、標準の stop-the-world GC にフォールバックします。サイズが 16 GB のヒープでは、最大 30 秒以上の一時停止が予想されます。これを回避して、アプリケーションの長期間のガベージ生成率をできるだけ低く保つことができます。CMS は 1 つのコアしか使用しないため、アプリケーションを実行するコアの数が多いほど、この問題が大きくなることに注意してください。明らかに、CMS が STW コレクターにフォールバックしないという保証はないことに注意してください。その場合、通常は負荷のピーク時に発生し、アプリケーションは数秒間停止します。このような構成では、SLA に署名したくないでしょう。

  4. さて、その新しいG1のものがあります。理論的には CMS の問題を回避するように設計されていますが、試してみたところ、次のことがわかりました。

    • そのスループットは CMS よりも劣ります。
    • 理論的には、メモリの人気のあるブロックを最初に収集することを避ける必要がありますが、すぐにほとんどすべてのブロックが「人気」の状態に達し、それが基づいている仮定は単に機能しなくなります。
    • 最後に、G1 には stop-the-world フォールバックがまだ存在します。そのコードがいつ実行されることになっているのか、オラクルに聞いてください。彼らが「決して」と言う場合は、なぜコードがあるのか​​を尋ねてください。したがって、IMHO G1 は実際には Java の巨大なヒープの問題をなくすわけではなく、(ほぼ間違いなく) 少し小さくするだけです。

  5. 大容量のメモリを備えた大規模なサーバーに投資する場合は、おそらく、Azul が提供するような、優れた商用ハードウェア アクセラレーションの一時停止のない GC テクノロジにも投資することになります。384 GB の RAM を搭載したサーバーの 1 つがあり、実際に正常に動作します。一時停止も、GC での世界停止コードの行も 0 行です。

  6. LinkedIn がソーシャル グラフ処理で行ったように、大量のメモリを必要とするアプリケーションの重要な部分を C++ で記述します。これを行ってもすべての問題 (ヒープの断片化など) を回避できるわけではありませんが、一時停止を低く抑える方が確実に簡単になります。

于 2011-06-14T08:07:48.127 に答える
17

私は Azul Systems の CEO であるため、このトピックに関する私の意見は明らかに偏っています。:) そうは言っても...

Azul の CTO である Gil Tene は、Garbage Collection に関連する問題の概要と、Java Garbage Collection の理解とそれについてできることのプレゼンテーションでさまざまなソリューションのレビューを行っています。この記事には追加の詳細があります。 www.infoq.com/articles/azul_gc_in_detail .

Zing JVM の Azul の C4 ガベージ コレクターは、並列かつ同時実行の両方であり、新世代と旧世代の両方に同じ GC メカニズムを使用し、両方のケースで同時に動作し、圧縮します。最も重要なことは、C4 にはストップ・ザ・ワールドのフォールバックがないことです。すべての圧縮は、実行中のアプリケーションと同時に実行されます。非常に大規模 (数百ギガバイト) を実行しているお客様がいて、最悪の場合の GC 一時停止時間は 10 ミリ秒未満であり、アプリケーションによっては 1 ～ 2 ミリ秒未満になることがよくあります。

CMS と G1 の問題は、ある時点で Java ヒープ メモリを圧縮する必要があり、両方のガベージ コレクタが圧縮を実行するために世界を停止/STW (つまり、アプリケーションを一時停止) することです。したがって、CMS と G1 は STW の一時停止を押し出すことができますが、それらを排除することはできません。ただし、Azul の C4 は STW の一時停止を完全に排除します。そのため、巨大なヒープ サイズでも Zing の GC 一時停止が非常に少なくなります。

于 2012-02-15T20:25:47.747 に答える
14

12 ～ 16 Gb を割り当てるアプリケーションがありますが、通常の操作では実際には 8 ～ 10 にしか達しません。私たちは Sun JVM を使用しています (IBM を試してみましたが、ちょっとした惨事でしたが、それは私たちの無知だったのかもしれません... IBM で働いていることを誓う友人がいます)。アプリに余裕を持たせる限り、JVM は GC をあまり使用せずに大きなヒープ サイズを処理できます。大量の「余分な」メモリが重要です。
Linux はほとんどの場合、Windows よりも安定しており、安定していない場合、その理由を突き止めるのは非常に簡単です。Solaris も堅実で、DTrace も取得できます :) この種の負荷があるのに、一体なぜ Vista や XP を使用するのでしょうか? あなたはトラブルを求めているだけです。GC パラメーターに関して特別なことは何もしていません。最小割り当てを最大と等しくなるように設定しているため、常にサイズ変更を試みているわけではありませんが、それだけです。

于 2008-10-18T01:56:59.337 に答える
9

Sun 1.6 JVM の 64 ビット バージョン (明らかに) を使用して、Linux と Solaris でそれぞれ 2 つの異なるアプリケーションで 60 GB を超えるヒープ サイズを使用しました。

Linux ベースのアプリケーションでガベージ コレクションの問題が発生したことはありませんが、ヒープ サイズの制限に近づいた場合を除きます。そのシナリオに固有のスラッシングの問題 (ガベージ コレクションに時間がかかりすぎる) を回避するために、プログラム全体のメモリ使用量を単純に最適化し、ピーク時の使用量が 64 GB のヒープ サイズ制限を約 5 ～ 10% 下回るようにしました。

しかし、Solaris で別のアプリケーションを実行すると、ガベージ コレクションに関する重大な問題が発生し、多くの調整が必要になりました。これは、主に次の 3 つの手順で構成されていました。

  1. -XX:+UseParallelGC -XX:+UseParallelOldGC JVM オプションによるパラレル ガベージ コレクタの使用の有効化/強制、および -XX:ParallelGCThreads オプションによる使用される GC スレッドの数の制御。詳細については、「Java SE 6 HotSpot 仮想マシンのガベージ コレクションのチューニング」を参照してください。

  2. 不要になった後、ローカル変数を「null」に設定する、大規模でばかげているように見える。これらのほとんどは、スコープ外になった後にガベージ コレクションの対象となるはずの変数であり、参照がコピーされていないため、メモリ リークの状況ではありませんでした。しかし、ガベージ コレクションを支援するためのこの「手持ち」戦略は、問題の Solaris プラットフォームでのこのアプリケーションの何らかの理由で不可解にも必要でした。

  3. System.gc() メソッド呼び出しの主要なコード セクションでの選択的な使用は、一時的なオブジェクトの割り当てが長期間続いた後です。これらの呼び出しを使用することに対する標準的な警告と、通常は不要であるという議論は認識していますが、このメモリ集約型アプリケーションを実行するときにガベージ コレクションを制御するには、それらが重要であることがわかりました。

上記の 3 つの手順により、このアプリケーションを維持し、約 60 GB のヒープ使用量で生産的に実行することが可能になりました。制御不能になって 128 GB のヒープ サイズ制限に達することはありませんでした。特に並列ガベージ コレクタは非常に役立ちました。オブジェクトが多数ある場合、メジャー ガベージ コレクションのサイクルはコストがかかるためです。つまり、メジャー ガベージ コレクションに必要な時間は、ヒープ内のオブジェクトの数の関数です。

この規模での他のプラットフォーム固有の問題についてコメントすることはできません。また、Sun (Oracle) 以外の JVM を使用したこともありません。

于 2010-12-02T02:21:00.287 に答える
8

Sun の Hotspot などの適切な JVM 実装では、12Gb は問題になりません。SUN VM を使用する場合は、コンカレント マーク アンド スイープ コレクター ( -XX:+UseConcMarkSweepGC) を使用することをお勧めします。そうしないと、GC 中にすべてのスレッドが停止するなど、長い「ストップ ザ ワールド」フェーズに直面する可能性があります。

OS によって GC のパフォーマンスが大きく変わることはありません。

もちろん、64 ビット OS と十分な物理 RAM を備えたマシンが必要です。

于 2008-10-18T20:08:56.523 に答える
7

また、ヒープ ダンプを取得して、アプリのどこでメモリ使用量を改善できるかを確認し、Eclipse の MATなどでダンプを分析することもお勧めします。MAT ページには、メモリ リークの検索を開始するための記事がいくつかあります。jmap を使用して、次のような方法でダンプを取得できます...

jmap -heap:format=b pid
于 2008-10-18T02:09:56.470 に答える
2

前述のように、非対話型プログラムを使用している場合は、既定の (圧縮) ガベージ コレクター (GC) が適切に機能するはずです。対話型プログラムを使用していて、(1) GC が追いつくよりも速くメモリを割り当てない、および (2) 大きすぎる一時オブジェクト (またはオブジェクトのコレクション) を作成しない (全体に対して最大 JVM メモリ) を使用して GC を回避する場合は、CMS が最適です。

GC に十分な余裕がない対話型プログラムがあると、問題が発生します。これはメモリの量に関係なく当てはまりますが、メモリが多いほど悪化します。これは、メモリが少なくなりすぎると、CMS がメモリ不足になり、圧縮 GC (G1 を含む) がすべてのメモリのゴミをチェックするまですべてを一時停止するためです。このストップ・ザ・ワールドの一時停止は、メモリが多いほど大きくなります。信じてください。サーブレットを 1 分以上停止させたくありません。G1 でのこれらの一時停止に関する詳細な StackOverflow の回答を書きました。

それ以来、私の会社はAzul Zingに切り替えました。アプリが実際に必要とするメモリよりも多くのメモリを必要とする場合はまだ処理できませんが、その瞬間までは夢のように動作します。

しかし、もちろん、Zing は無料ではなく、その特別なソースは特許を取得しています。お金よりもはるかに時間があれば、JVM のクラスターを使用するようにアプリを書き直してみてください。

近いうちに、Oracle は数ギガバイトのヒープ用の高性能 GC に取り組んでいます。ただし、今日の時点では、それはオプションではありません。

于 2014-05-01T23:00:04.297 に答える
1

SunのJava6に関する記事が役に立ちます：https ：//www.oracle.com/java/technologies/javase/troubleshooting-javase.html

于 2008-10-18T04:37:58.263 に答える
1

これは、Javaチャンピオンの1つからのgcに関する記事です-http ://kirk.blog-city.com/is_your_concurrent_collector_failing_you.htm

著者のカークは「GCログを送ってください

現在、SunJVMで生成されたGCログの調査に興味があります。これらのログにはビジネスに関連する情報が含まれていないため、機密情報の保護に関する懸念が緩和されるはずです。ログを使用して、OS、JREの完全なバージョン情報、および設定したヒープ/gc関連のコマンドラインスイッチについて言及してください。また、Grails / Groovey、JRuby、Scala、またはJava以外のもの、またはJavaと一緒に実行しているものがあるかどうかも知りたいです。最適な設定は-Xloggc：です。このログは、OSのサイズ制限に達してもロールオーバーしないことに注意してください。何か面白いことがあれば、お返しに非常に簡単な概要をお伝えします。「」

于 2008-10-19T01:50:14.773 に答える
1

アプリに対して visualgc を実行してみてください。これは、 http://java.sun.com/performance/jvmstat/の jvmstat ダウンロードの一部であるヒープ視覚化ツールです。

GC ログを読むよりもはるかに簡単です。

ヒープの各部分 (世代) がどのように機能しているかをすばやく理解するのに役立ちます。合計ヒープは 10GB かもしれませんが、ヒープのさまざまな部分ははるかに小さくなります。ヒープの Eden 部分の GC は比較的安価ですが、古い世代の完全な GC は高価です。Eden が大きくなり、古い世代がほとんど触れられないようにヒープのサイズを調整することは、適切な戦略です。これにより、全体的なヒープが非常に大きくなる可能性がありますが、JVM がページにまったくアクセスしない場合、それは単なる仮想ページであり、RAM を占有する必要はありません。

于 2008-10-28T19:05:07.313 に答える
1

数年前、私は JRockit と Sun JVM の 12G ヒープを比較しました。JRockit が勝利し、Linux hugepage のサポートにより、テストの実行が 20% 速くなりました。YMMV は、私たちのテストが非常にプロセッサ/メモリを集中的に使用し、主にシングル スレッドであったためです。

于 2009-05-14T16:22:25.387 に答える
1

64 ビットに切り替えると、より多くのメモリを使用します。ポインターは 4 バイトではなく 8 バイトになります。多数のオブジェクトを作成している場合、すべてのオブジェクトが参照 (ポインター) であるため、これは顕著です。

最近、Sun 1.6 JVM を使用して Java で 15GB のメモリを問題なく割り当てました。それはすべて一度だけ割り当てられますが。最初の量の後は、それほど多くのメモリが割り当てられたり解放されたりすることはありません。これは Linux 上でしたが、Sun JVM は 64 ビット Windows でも同様に機能すると思います。

于 2008-10-18T02:57:05.983 に答える
0

itaniumは人気のある目的地ではありませんが、sunにはしばらくの間itanium64ビットjvmがあります。ソラリスとLinuxの64ビットJVMは、あなたが求めているものでなければなりません。
いくつかの質問

1）アプリケーションは安定していますか？
2）32ビットJVMでアプリをすでにテストしましたか？
3）同じボックスで複数のJVMを実行しても大丈夫ですか？

Windowsの64ビットOSは約1年ほどで安定すると思いますが、それまでは、solaris/linuxの方が適しているかもしれません。

于 2008-10-18T04:23:35.390 に答える
0

XP がアドレス指定できる最大メモリは 4 ギガです (こちら)。したがって、そのためにXPを使用したくない場合があります（64ビットOSを使用してください）。

于 2008-10-18T02:51:17.073 に答える