パフォーマンスチューニングに関するいくつかのメモを読んでいるときに、メモリサイズを設定する際の推奨事項に気づきました。
永続生成スペースを拡大または縮小するには完全なGCが必要であるため、Javaアプリケーションは、永続生成の初期サイズと最大サイズの両方を同じ値にサイズ設定する必要があります。ヒープサイズ、つまりを設定するときにも同様の提案があります-Xmx=-Xms。
私の質問は、なぜ-Xms設定があるのですか？
また、 -Xmxと-Xmsの値が異なる場合に、GCが頻繁にトリガーされるのはなぜですか。また、-Xmxと-Xmsのサイズが同じ場合はトリガーされません。
2番目の質問にさらに追加すると、最小ヒープサイズが64M、最大ヒープサイズが512 Mの場合、アプリで使用されるメモリが512Mに達しない限り、完全なGCはトリガーされないと思います。
同様に、-Xmxと-Xmsの両方で512Mから開始した場合でも、アプリのメモリ使用量がこの制限に達すると、JVMは完全なGCをトリガーします。では、なぜmaxとminの両方を同じ値に設定することが推奨されるのでしょうか。
設定フラグは、VMが世代別の増分収集を行う前に設計されました。その場合、完全なコレクションがすべてありました。より現代的なコレクターでは、完全なコレクションはまれです。インクリメンタルコレクションは通常数ミリ秒であり、UIエクスペリエンスは変わらないため、これは良いことです。大きなアリーナの完全なコレクションには、さらに数秒かかる場合があります。アリーナのサイズを変更すると（ドキュメントに記載されているように）、毎回完全なコレクションが作成されることが保証されています。
ガイダンスは100％完璧ではありません。アリーナの成長を許可することが合理的であるアプリの種類はほとんどありません。
-Xms=64m -Xmx=512m「64〜512MBのヒープで起動する」という意味ではありません。起動時に64MBのコミット済みメモリと512MBの予約済みメモリを要求するようにJVMに指示します。ヒープは最初は64MBで、いっぱいになると、予約されたスペースに拡張されます。したがって、64MBのXmsを使用すると、ヒープが64MBにいっぱいになる前に完全なコレクションが表示されます。
Xmsの値を低くしてアプリケーションを起動し、GCロギングをオンにすると（-verbose:gc -Xloggc:FILENAME）、ログファイルには、アプリケーションの実行時にヒープと世代のサイズがどのように変化するかが示されます。
マイナーコレクションは、Xmsが低いほど頻繁に発生する可能性があります。これは、新しい世代が小さくなり（明示的ではなく比例世代のサイズ設定を使用していると想定）、より早くいっぱいになるためです。
-Xms <-Xmxを使用する理由の1つは、JVMがXmx全体を事前に割り当てないようにして、他のアプリケーションで違いを利用できるようにするためです。ゴーリーの詳細はこちら：http ：//www.ibm.com/developerworks/library/j-memusage/