小さなメモリフットプリントでG1GCを調整するにはどうすればよいですか？

Question

私は自分のプロジェクトの1つでJava 8（Oracle JVM）を使ってG1GCを試してきました。私のGCフラグは効果的です：

-Xms64m 
-Xmx1024m 
-XX:+UseG1GC 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-Xloggc:/tmp/gc.log 
-XX:+PrintAdaptiveSizePolicy 

私はヒープが私が持っているライブデータの量よりもはるかに大きくなることがわかります。 GCログには、私は根本的な原因と思われるものを示しています。

[G1Ergonomics (Heap Sizing) attempt heap expansion, reason: recent GC overhead higher than threshold after GC, recent GC overhead: 10.17 %, threshold: 10.00 %, uncommitted: 811597824 bytes, calculated expansion amount: 162319564 bytes (20.00 %)] 

が効果的に私のアプリケーションは、ごみの多くを生成している、ので、GCに費やされる時間の割合が10％以上である、とそうG1の人間工学が増加しますヒープサイズ。パラレルコレクタに

---

このしきい値は-XX:GCTimeRatio（スループット目標）を用いて調整することができるが、私はdocsで見ることができるものからG1には同等のフラグが存在しません。

パラレルコレクタの場合、Java SEはアプリケーションの特定の動作を達成することに基づく2つのガベージコレクションチューニングパラメータを提供します。最大停止時間目標とアプリケーションスループット目標。パラレルコレクタのセクションを参照してください。これらの2つのオプションは、他のコレクタでは使用できません。これらの動作は、必ずしも満たされるとは限りません。

私の質問は、最大ヒープサイズを下げることとは別に、より小さなメモリフットプリントでG1GCを調整する方法はありますか？

ログには、最大休止時間の目標を超えているという証拠はなく、実際にはそれを上げても問題は解決されません。 Which JVM Flag sets the GC overhead threshold mentioned in the G1Ergonomics log?、しかしそこには、間違った答えが受け入れられているように見えます：

---

これはおそらく、この質問のデュープです。 （あるいは、古いバージョンのJVMだけが正しいかもしれません）。

Answer 1

さらなる調査の結果、G1の人間工学は、ドキュメントが言っているものの、-XX:GCTimeRatioを尊重しているようです。

Answer 2

概要：this Oracle articleで

• （1）あなたは（-XX:MaxGCPauseMillisをinlcuding）G1のための最も重要なフラグを見つけることができます。

• This bug reportは、GCTimeRatioフラグがG1内でも使用されていることを示します。

• this related question & answer（2）も参照してください。

• -XX:MaxGCPauseMillisを高く設定するか、アプリケーションで若い世代のガベージが作成されていることがわかっている場合は、若い世代のサイズに関する設定で再生できます。編集：OK、これに非常に注意してください：（1）状態：*若い世代サイズ*：若い世代のサイズを明示的に-Xmnオプション、または-XX：NewRatioなどの関連オプションで設定しないでください。若い世代のサイズを固定すると、目標の休止時間の目標が上書きされます。

---

（1）

重要デフォルト：

G1 GCは、それが変形することなく効率的に作業することを可能にデフォルト値を持つ適応ガベージコレクタです。重要なオプションとそのデフォルト値の一覧を示します。このリストは、最新のJava HotSpot VM（ビルド24）に適用されます。JVMのコマンドラインで変更された設定で次のオプションを入力することにより、G1 GCをアプリケーションのパフォーマンスニーズに適応させ、調整できます。

• -XXは：G1HeapRegionSize = N

はG1領域のサイズを設定します。値は2の累乗で、1MBから32MBの範囲で設定できます。目標は、Javaのヒープサイズの最小値に基づいて2048個の領域を持つことです。

• -XX：所望の最大停止時間の目標値を設定し

  = 200

MaxGCPauseMillis。デフォルト値は200ミリ秒です。指定された値はヒープサイズに適合しません。

• -XX：G1NewSizePercent = 5

は、若い世代のサイズの最小値として使用するヒープの割合を設定します。デフォルト値はJavaヒープの5％です。これは実験的なフラグです。例については、「実験的なVMフラグのロックを解除する方法」を参照してください。この設定は、-XX：DefaultMinNewGenPercent設定を置き換えます。この設定は、構築、は、Java HotSpot VMでは利用できません23.

• -XX：G1MaxNewSizePercent = 60

は、若い世代のサイズの最大として使用するヒープサイズの比率を設定します。デフォルト値はJavaヒープの60％です。これは実験的なフラグです。例については、「実験的なVMフラグのロックを解除する方法」を参照してください。この設定は、-XX：DefaultMaxNewGenPercent設定を置き換えます。 ParallelGCThreads = N

はSTWワーカースレッドの値を設定：この設定は、Java HotSpot VMの中で、23

• -XXを構築できません。 nの値を論理プロセッサの数に設定します。 nの値は、8までの論理プロセッサーの数と同じです。

  8つ以上の論理プロセッサーがある場合は、nの値を論理プロセッサーの約5/8に設定します。これは、nの値が論理プロセッサの約5/16である大規模なSPARCシステムを除いて、ほとんどの場合に機能します。

  • -XX：ConcGCThreads = N

  は、並列マーキングスレッドの数を設定します。並列ガベージコレクションスレッド（ParallelGCThreads）の数の約1/4にnを設定します。

  • -XX：InitiatingHeapOccupancyPercent = 45

  はマーキングサイクルをトリガーするJavaヒープの占有しきい値を設定します。デフォルト占有率はJavaヒープ全体の45％です。

  • -XX：G1MixedGCLiveThresholdPercent = 65

  は、混合ガベージコレクションサイクルに含まれる古い地域の占有しきい値を設定します。デフォルトの占有率は65％です。これは実験的なフラグです。例については、「実験的なVMフラグのロックを解除する方法」を参照してください。この設定は、-XX：G1OldCSetRegionLiveThresholdPercent設定を置き換えます。この設定は、構築、は、Java HotSpot VMでは利用できません23.

  • -XX：G1HeapWastePercent = 10

  あなたが無駄に喜んでいるヒープの割合を設定します。再利用可能なパーセンテージがヒープの廃棄率未満の場合、Java HotSpot VMは混在ガベージコレクションサイクルを開始しません。デフォルトは10％です。この設定は、構築、23

  • -XXは、Java HotSpot VMでは使用できません。G1MixedGCCountTarget = 8

  は高々と古い領域を収集するためにマーキングサイクルの後、混合ガベージコレクションの目標数を設定します。 G1MixedGCLIveThresholdPercentライブデータ。デフォルトは8つの混在ガベージコレクションです。混合コレクションの目標は、この目標数内にすることです。この設定は、Java HotSpot VMの中では使用できません、23

  • -XXを構築：G1OldCSetRegionThresholdPercent = 10

  は、混合ガベージコレクションサイクル中に収集されるように、古い領域の数に上限を設定します。 。デフォルトはJavaヒープの10％です。この設定は、Java HotSpot VMの中では使用できません、23

  • -XXを構築：G1ReservePercent = 10

  はと空間の危険性を低減するように、予備のメモリの割合が自由に保つために設定します。オーバーフローする。デフォルトは10％です。パーセンテージを増減する場合は、Javaヒープの総量を同じ量だけ調整してください。この設定は、Java HotSpot VMの中では使用できません、23

  ---

  を構築（2）

  私の推測では、recent GC overhead higher than thresholdはG1の決定を駆動しているということです。-XX:GCTimeRatio=4を設定することで緩和することができます。これにより、10％でなくGCingのアプリケーション時間に対してCPUサイクルの20％を占めるようになります。それはそれを作る、それが簡単に順番に、それは長くのためにコレクションを延期することができることを意味しているの休止時間の目標を達成するためになるだろう - それはあまりにも多くのなら

  あなたはどちらか

  • は、それがより多くのCPUコアを使用できるようにする必要がありますスループットの目標を満たすのが簡単です。 はい、これは、より多くのコアを実際に使用するCPUサイクルを全体的に減らすことができるということを意味します。

  • それはあなたが実際にヒープサイズは、（あなたの箱上のプロセスのRAMの使用、またはヒープサイズをリストJVMのMBeanメトリクス）を増加させる参照くださいあまり頻繁に