Since Java 7 is going to use the new G1 garbage collection by default is Java going to be able to handle an order of magnitude larger heap without supposed "devastating" GC pause times? Has anybody actually implemented G1 in production, what were your experiences?
To be fair the only time I have seen really long GC pauses is on very large heaps, much more than a workstation would have. To clarify my question; will G1 open the gateway to heaps in the hundreds of GB? TB?
私は重いアプリケーションでそれをテストしてきました：ヒープに割り当てられた60-70GB、いつでも20-50GBが使用されています。この種のアプリケーションでは、マイレージが異なる可能性があると言っても過言ではありません。LinuxでJDK1.6_22を実行しています。マイナーバージョンは重要です。約1.6_20より前は、ランダムなNullPointerExceptionsを引き起こすバグがG1にありました。
ほとんどの場合、一時停止の目標を維持するのが非常に優れていることがわかりました。デフォルトは100ms（0.1秒）の一時停止のようですが、その半分（-XX：MaxGCPauseMillis = 50）を実行するように指示しています。ただし、メモリが非常に少なくなると、パニックに陥り、完全に停止したガベージコレクションが実行されます。65GBの場合、30秒から2分かかります。（CPUの数はおそらく違いはありません。おそらくバス速度によって制限されます。）
CMS（デフォルトのサーバーGCではありませんが、Webサーバーやその他のリアルタイムアプリケーション用である必要があります）と比較すると、通常の一時停止ははるかに予測可能であり、はるかに短くすることができます。これまでのところ、私はCMSで大きな一時停止の運が良かったのですが、それはランダムかもしれません。私はそれらを24時間ごとに数回しか見ていません。現時点では、どちらが本番環境に適しているかはわかりませんが、おそらくG1です。オラクルがそれを調整し続けるならば、私はG1が最終的に明らかに勝者になるだろうと思う。
既存のガベージコレクターに問題がない場合は、今すぐG1を検討する理由はありません。GUIアプリケーションなどの低レイテンシのアプリケーションを実行している場合は、G1がおそらく正しい選択であり、MaxGCPauseMillisは非常に低く設定されています。バッチモードのアプリケーションを実行している場合、G1は何も購入しません。
G1のポイントは、最大の一時停止時間の目標を指定できるようになるまで、一時停止時間を短くすることであるように思えます.
ガベージ コレクションは、単純な「満杯です。すべてを一度に移動して最初からやり直しましょう」という単純な取引ではなくなりました。バックグラウンドで一時停止することなくメンテナンスの多くを行うことができます。また、実行時にシステムが予想するパターンに関する知識を使用して、ほとんどのオブジェクトが作成された直後に消滅すると仮定するなどの支援も行います。
GC の一時停止時間は、今後のリリースで悪化するのではなく、改善し続けると思います。
編集：
読み返してみると、Java を毎日使っていることに気づきました。Eclipse、Azureus、そして私が開発したアプリです。大幅な一時停止ではありませんが、一時停止はまったくありません。
Windows エクスプローラーを右クリックしたとき、または (時折) 特定の USB ハードウェアを接続したときに一時停止するのを見たことがありますが、Java ではまったくありません。
GCはまだ誰かの問題ですか?
私は本番環境で G1 をテストしていませんが、「巨大な」ヒープがない場合、GC はすでに問題があるとコメントしたいと思います。具体的には、たとえば 2 ギガまたは 4 ギガだけのサービスは、GC によって深刻な影響を受ける可能性があります。若い世代の GC は通常、1 桁のミリ秒 (または最大で 2 桁) で終了するため、問題はありません。しかし、古い世代のコレクションは、1 ギガ以上の古い世代のサイズで数秒かかるため、はるかに問題があります。
現在: 理論的には、CMS はほとんどの操作を同時に実行できるため、そこで大いに役立ちます。ただし、時間の経過とともに、これを行うことができず、「世界を止める」コレクションにフォールバックしなければならない場合があります。そして、それが起こったとき（たとえば、1時間後-頻繁ではありませんが、それでも頻繁に）、まあ、あなたのf *** ing帽子を握ってください. 1 分以上かかる場合があります。これは、最大レイテンシを制限しようとするサービスにとって特に問題です。たとえば、リクエストを処理するのに 25 ミリ秒かかっていたのが、10 秒以上かかるようになりました。侮辱的なクライアントに傷害を追加すると、多くの場合、リクエストがタイムアウトして再試行され、さらなる問題 (別名「シット ストーム」) につながります。
これは、G1 が大いに役立つと期待されていた分野の 1 つです。私は、ストレージとメッセージ ディスパッチ用のクラウド サービスを提供する大企業で働いていました。また、CMS を使用することはできませんでした。これは、多くの場合、並行バージョンよりもうまく機能していましたが、これらのメルトダウンがあったためです。それで、約1時間、物事はうまくいきました。そして、物事はファンにぶつかりました...そして、サービスはクラスターに基づいていたため、1つのノードがトラブルに陥ると、他のノードが通常続きました（GCによって引き起こされるタイムアウトにより、他のノードはノードがクラッシュしたと信じ、再ルーティングにつながるため）.
GC はアプリにとってそれほど問題ではないと思います。おそらく、クラスター化されていないサービスでさえ影響を受けることはあまりありません。しかし、ますます多くのシステムがクラスター化され (特に NoSQL データ ストアのおかげで)、ヒープ サイズが増大しています。OldGen GC は、ヒープ サイズに非常に直線的に関連しています (ライブ データ セットのサイズも 2 倍になると仮定すると、ヒープ サイズを 2 倍にすると GC 時間が 2 倍以上になることを意味します)。
ほぼ2年前からすでにG1GCを使用しています。ミッションクリティカルなトランザクション処理システムで優れたパフォーマンスを発揮し、高スループット、低一時停止、同時実行性、最適化された大量のメモリ管理をサポートする優れた機能であることが証明されました。
次のJVM設定を使用しています。
-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
更新しました
-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000
Azul の CTO である Gil Tene は、ガベージ コレクションに関連する問題の優れた概要と、Java ガベージ コレクションの理解とそれについてできることのプレゼンテーションでさまざまなソリューションのレビューを行っています。この記事には追加の詳細があります。 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 一時停止が非常に少なくなります。
また、以前の回答で行われた声明を修正するために、Zing はオペレーティング システムに変更を加える必要はありません。変更されていない Linux ディストリビューションでは、他の JVM と同じように動作します。
G1 コレクターは、完全なコレクションの影響を軽減します。完全なコレクションの必要性をすでに減らしているアプリケーションがある場合、Concurrent map Sweep コレクターも同様に優れており、私の経験では、マイナー コレクションの時間が短くなります。
最近引っ越してきました
JDK 1.7.45 を搭載したサーバーで 4G ヒープと 8 コア プロセッサを搭載した CMS から G1GC へ。
(JDK 1.8.x G1GC は 1.7 よりも優先されますが、いくつかの制限があるため、1.7.45 バージョンに固執する必要があります)
以下の主要なパラメーターを構成し、他のすべてのパラメーターをデフォルト値のままにしました。
-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n apart from -Xms and -Xmx
これらのパラメータを微調整したい場合は、このオラクルの記事をご覧ください。
主な所見:
それでも、最大 GC 一時停止時間が CMS よりも少ないのは嬉しいことです。最大 GC 一時停止時間を1.5 秒に設定しましたが、この値はまだ超えられていません。
関連する SE の質問:
JDK7u4 を開始する G1 が最終的に正式にサポートされたよう です。
大規模な JVM でのテストでは、CMS を調整しても G1 よりも優れた動作をしますが、今後さらに良くなると思います。
Terracotta Big Memory プロジェクトに G1 ガベージ コレクターを実装しました。さまざまなタイプのコレクターに取り組んでいる間、G1 は 600 ミリ秒未満の応答時間で最高の結果をもたらしました。
テスト結果 (合計 26 件)はこちら
それが役に立てば幸い。
G1 GC の方がうまくいくはずです。ただし、 -XX:MaxGCPauseMillis を積極的に設定しすぎると、ガベージの収集が遅くなります。これが、David Leppik の例でフル GC がトリガーされた理由です。
CMS は、tenured オブジェクトを蓄積せずに実行している場合でも、パフォーマンスが徐々に低下する可能性があります。これは、G1 が回避すると思われるメモリの断片化が原因です。
有料サポートでのみ利用可能な G1 に関する神話は、まさに神話です。Sun と現在 Oracle は、JDK ページでこれを明確にしています。
最近、Twicsyの一部を128GBのRAMを搭載した新しいサーバーに移行し、1.7を使用することにしました。1.6で使用したのと同じメモリ設定をすべて使用することから始めました（500MBのヒープから最大15GBまで、さまざまなことを実行しているインスタンスがいくつかありますが、現在は40GBの新しいインスタンスがあります）、それはまったくうまくいきませんでした。1.7は1.6よりも多くのヒープを使用しているようで、最初の数日間で多くの問題が発生しました。幸運なことに、動作するRAMが十分にあり、ほとんどのプロセスでRAMを増やしましたが、それでもいくつかの問題がありました。私の通常のMOは、最大ヒープが数ギガバイトであっても、16mの非常に小さい最小ヒープサイズを使用してから、インクリメンタルGCをオンにすることでした。これにより、一時停止が最小限に抑えられました。しかし、それは今は機能しません。最小サイズを、ヒープ内で平均して使用すると予想されるサイズに増やす必要がありました。そしてそれは非常にうまくいきました。インクリメンタルGCはまだオンになっていますが、オンにせずに試してみます。現在、一時停止はまったくなく、物事は非常に高速に実行されているようです。ですから、この話の教訓は、メモリ設定が1.6から1.7に完全に変換されることを期待しないことだと思います。
G1 により、アプリケーションの機敏性が大幅に向上します。アプリケーションのレイテンシが上昇します。アプリケーションは「ソフト リアルタイム」と呼ばれます。これは、2 種類の GC 実行 (小さな小さなものと Tenured Gen の大きなもの) を同じサイズの小さなものに置き換えることによって行われます。
詳細については、http: //geekroom.de/java/java-expertise-g1-fur-java-7/を参照してください。
私は Java 8 で G1GC を使用し、Groovy (Java 8 も) でも使用しています。さまざまな種類のワークロードを実行しています。全体的に G1GC は次のように動作します。
メモリ使用量は非常に低く、たとえば、デフォルトの Java 設定と比較して 500MB ではなく 100MB です。
応答時間は一貫しており、非常に短い
デフォルト設定と G1GC の間のパフォーマンスは、G1GC を最悪のシナリオ (チューニングなし、シングル スレッド アプリケーション) で使用すると 20% 低下します。優れた応答時間と低いメモリ使用量を考慮すると、それほど多くはありません。
マルチスレッドの Tomcat から実行すると、全体的なパフォーマンスが 30% 向上し、メモリ使用量が大幅に減少し、応答時間も大幅に短縮されます。
したがって、全体として、非常にさまざまなワークロードを使用する場合、G1GC はマルチスレッド アプリケーション用の Java 8 の非常に優れたコレクターであり、シングル スレッドの場合でもいくつかの利点があります。
私は Java を使用して、ヒープの大小を問わず、GC とフル GC の問題が毎日発生します。これは、制約が他のものよりも厳しい場合があるためです。特定の環境では、0.1 秒のスカベンジャー GC またはフル GC、kill単純に機能的であり、きめの細かい構成と機能を備えていることが重要です (CMS、iCMS、その他 ... 目標は、ほぼリアルタイムの処理で可能な限り最高の応答時間を実現することです (ここでは、リアルタイム処理は多くの場合 25 ミリ秒です)。したがって、基本的に、GC のエルゴノミーとヒューリスティックの改善は大歓迎です。