Javaの-Xmsおよび-Xmxオプションの速度のトレードオフ
-
20-08-2019 - |
質問
これらの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によって提供されたメモリを割り当てようとし、スワップを使用する場合(これも1になります)、VMの起動時にのみパフォーマンスへの影響があります。
メモリの割り当てが速度にどのように影響するかを言うのは困難です。 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の値を同じにするかどうか
<!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp;-ほとんどのWebサイトやオラクルのドキュメントでさえ、同じであることが推奨されています。ただし、急にトラフィックが急増した場合や偶発的なメモリリークが発生した場合に、ヒープのサイズ変更をアプリケーションに与えるために、これらの値の間に10〜20%程度のバッファを用意することをお勧めします。
2.ヒープサイズを小さくしてアプリケーションを起動するかどうか
<!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp;-だから、GC Algoを使用してもG1)、大きなヒープには常にトレードオフがあります。目標は、レイテンシとスループットの観点からGCの一時停止を許可できるヒープサイズに対するアプリケーションの動作を識別することです。
<!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp;-たとえば、アプリケーションに多数のスレッドがある場合(各スレッドはネイティブメモリに1 MBのスタックがあり、ヒープにはない)、占有しない場合重いオブジェクトスペースの場合、Xmsの値を低くすることをお勧めします。
<!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp; <!> nbsp;-アプリケーションがスレッド数を増やして多くのオブジェクトを作成する場合、それらのSTW一時停止を許容するために設定できるXmsの値を特定します。これは、許容できる着信リクエストの最大応答時間を特定し、それに応じて最小ヒープサイズを調整することを意味します。