Javaの-Xmsおよび-Xmxオプションの速度のトレードオフ
これらの2つのコマンドを考える
A：
$ Java -Xms10G -Xmx10G myjavacode input.txt
B：
$ Java -Xms5G -Xmx5G myjavacode input.txt
2つの質問があります。
- コマンドAはパラメーターでより多くのメモリを予約するため、AはBよりも速く実行されますか？
-Xmxと-Xmsは、実行中のプロセスとプログラムの出力にどのように影響しますか？
Javaが使用しているGCに依存します。並列GCは、より大きなメモリ設定でより適切に動作する可能性があります-私はそれについては専門家ではありません。
一般に、メモリが大きい場合、GCを実行する必要は少なくなります-ガベージのためのスペースがたくさんあります。ただし、GCに関しては、GCはより多くのメモリで動作する必要があります。これは、より低速になる可能性があります。
-Xmx引数は、ヒープがJVMに到達できる最大メモリサイズを定義します。プログラムを熟知し、負荷のかかった状態でどのように動作するかを確認し、それに応じてこのパラメーターを設定する必要があります。プログラムのヒープメモリが最大ヒープサイズに達した場合、値が低いとOutOfMemoryExceptionsまたはパフォーマンスが非常に低下する可能性があります。プログラムが専用サーバーで実行されている場合、他のプログラムに影響を与えないため、このパラメーターを高く設定できます。
-Xms引数は、JVMの初期ヒープメモリサイズを設定します。つまり、プログラムを起動すると、JVMはこの量のメモリを即座に割り当てます。これは、プログラムが最初から大量のヒープメモリを消費する場合に便利です。これにより、JVMが絶えずヒープを増加させず、そこである程度のパフォーマンスを得ることができます。このパラメーターが役立つかどうかわからない場合は、使用しないでください。
要約すると、これは、プログラムのメモリ動作のみに基づいて決定する必要がある妥協案です。
場合によっては、メモリが多すぎるとプログラムが遅くなることがあります。
たとえば、負荷が増加するにつれてゆっくりと実行を開始する休止状態ベースの変換エンジンがありました。 dbからオブジェクトを取得するたびに、hibernateは二度と使用されないオブジェクトのメモリをチェックしていることが判明しました。
解決策は、セッションから古いオブジェクトを削除することでした。
スチュアート
- 割り当ては常にOSに依存します。あまりにも多くのメモリを割り当てた場合、スワップにロードされた部分を持つことになりますが、実際には遅いです。
- プログラムの実行速度が遅いか速いかは、VMが処理およびクリーニングする必要がある参照に依存します。 GCは、放棄されたオブジェクトを見つけるために、割り当てられたメモリをスイープする必要はありません。オブジェクトと、参照マッピングによって割り当てられるメモリの量を知っています。したがって、スイープはオブジェクトのサイズに依存します。両方のケースでプログラムが同じように動作する場合、VMがOSによって提供されたメモリを割り当てようとし、スワップを使用する場合、パフォーマンスへの影響はVM起動のみになります（再び1につながります。）
メモリの割り当てが速度にどのように影響するかを言うのは困難です。 JVMが使用しているガベージコレクションアルゴリズムに依存します。たとえば、ガベージコレクタが完全なコレクションを実行するために一時停止する必要がある場合、実際に必要なメモリが10個以上ある場合、コレクタはクリーンアップするためにさらに10個のガベージを持ちます。
Java 6を使用している場合は、jconsole（jdkのbinディレクトリ内）を使用してプロセスにアタッチし、コレクターの動作を確認できます。一般に、コレクターは非常にスマートであり、チューニングを行う必要はありませんが、必要な場合は、収集プロセスをさらにチューニングするために使用できる多数のオプションがあります。
> C:\Java -X
-Xmixed mixed mode execution (default)
-Xint interpreted mode execution only
-Xbootclasspath:<directories and Zip/jar files separated by ;>
set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and Zip/jar files separated by ;>
append to end of bootstrap class path
-Xbootclasspath/p:<directories and Zip/jar files separated by ;>
prepend in front of bootstrap class path
-Xnoclassgc disable class garbage collection
-Xincgc enable incremental garbage collection
-Xloggc:<file> log GC status to a file with time stamps
-Xbatch disable background compilation
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
-Xss<size> set Java thread stack size
-Xprof output cpu profiling data
-Xfuture enable strictest checks, anticipating future default
-Xrs reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni perform additional checks for JNI functions
-Xshare:off do not attempt to use shared class data
-Xshare:auto use shared class data if possible (default)
-Xshare:on require using shared class data, otherwise fail.
-Xオプションは非標準であり、予告なく変更される場合があります。
（コピーペースト）
これは、リクエストごとに膨大な数のスレッドを作成するアプリケーションの1つで作業していたときに常に疑問でした。
したがって、これは非常に良い質問であり、これには2つの側面があります。
1。 XmsとXmxの値を同じにする必要があるかどうか
-ほとんどのWebサイトとOracleのドキュメントでさえ、同じであることが推奨されています。ただし、突然の高トラフィックスパイクOR偶発的なメモリリークが発生した場合に、ヒープのサイズ変更をアプリケーションに与えるために、これらの値の間に10〜20％程度のバッファを用意することをお勧めします。
2。低いヒープサイズでアプリケーションを起動する必要があるかどうか
[。目標は、レイテンシとスループットの観点からGCの一時停止を許可できるヒープサイズに対するアプリケーションの動作を識別することです。
-たとえば、アプリケーションに多数のスレッドがある場合（各スレッドにはネイティブメモリに1 MBのスタックがあり、ヒープにはない）、重いオブジェクトスペースを占有しない場合、Xmsの値を低くすることをお勧めします。
-アプリケーションがスレッド数を増やして多数のオブジェクトを作成する場合、それらのSTW一時停止を許容するように設定できるXmsの値を特定します。これは、許容できる着信リクエストの最大応答時間を特定し、それに応じて最小ヒープサイズを調整することを意味します。