これらの2つのコマンドが与えられた
A:
$ java -Xms10G -Xmx10G myjavacode input.txt
B:
$ java -Xms5G -Xmx5G myjavacode input.txt
2つの質問があります:
- コマンドAはそのパラメーターでより多くのメモリを予約するので、AはBよりも速く実行されますか?
- 実行中のプロセスとプログラムの出力にどのよう
-Xmx
に影響しますか?-Xms
これらの2つのコマンドが与えられた
A:
$ java -Xms10G -Xmx10G myjavacode input.txt
B:
$ java -Xms5G -Xmx5G myjavacode input.txt
2つの質問があります:
-Xmx
に影響しますか?-Xms
引数は、-Xmx
ヒープがJVMに対して到達できる最大メモリサイズを定義します。プログラムをよく理解し、負荷がかかった状態でどのように動作するかを確認し、それに応じてこのパラメーターを設定する必要があります。プログラムのヒープメモリが最大ヒープサイズに達している場合、値が小さいとOutOfMemoryExceptionsまたはパフォーマンスが非常に低下する可能性があります。プログラムが専用サーバーで実行されている場合は、他のプログラムに影響を与えないため、このパラメーターを高く設定できます。
-Xms
引数は、JVMの初期ヒープメモリサイズを設定します。これは、プログラムを起動すると、JVMがこの量のメモリを即座に割り当てることを意味します。これは、プログラムが最初から大量のヒープメモリを消費する場合に役立ちます。これにより、JVMが常にヒープを増やすことを回避し、そこでパフォーマンスを向上させることができます。このパラメータが役立つかどうかわからない場合は、使用しないでください。
要約すると、これは、プログラムのメモリ動作のみに基づいて決定する必要がある妥協案です。
これは、Javaが使用しているGCによって異なります。並列GCは、より大きなメモリ設定でより適切に機能する可能性がありますが、私はその専門家ではありません。
一般に、メモリが大きい場合は、GCを実行する必要が少なくなります。つまり、ガベージの余地がたくさんあります。ただし、GCに関しては、GCはより多くのメモリで動作する必要があり、その結果、速度が低下する可能性があります。
場合によっては、メモリが多すぎるとプログラムの速度が低下することがあります。
たとえば、負荷が増加するにつれてゆっくりと実行を開始するHibernateベースの変換エンジンがありました。dbからオブジェクトを取得するたびに、hibernateは二度と使用されないオブジェクトのメモリをチェックしていたことが判明しました。
解決策は、セッションから古いオブジェクトを削除することでした。
スチュアート
-Xmsと-Xmxのさまざまな設定間の速度のトレードオフは、Javaアプリケーションを実行するアプリケーションとシステムによって異なります。また、JVMおよび使用するその他のガベージコレクションパラメータによっても異なります。
この質問は11年前のものであり、それ以降、JVMパラメーターがパフォーマンスに与える影響を事前に予測することはさらに困難になっています。したがって、さまざまな値を試してパフォーマンスへの影響を確認するか、OptimizerStudioなどの無料のツールを使用して最適なJVMパラメーター値を自動的に見つけることができます。
メモリ割り当てが速度にどのように影響するかを言うのは難しいです。これは、JVMが使用しているガベージコレクションアルゴリズムによって異なります。たとえば、ガベージコレクターが完全なコレクションを実行するために一時停止する必要がある場合、実際に必要なメモリよりも10個多いメモリがある場合、コレクターはクリーンアップするガベージが10個多くなります。
java 6を使用している場合は、(jdkのbinディレクトリにある)jconsoleを使用してプロセスに接続し、コレクターの動作を監視できます。一般に、コレクターは非常に賢く、調整を行う必要はありませんが、必要な場合は、収集プロセスをさらに調整するために使用できるオプションが多数あります。
> 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ドキュメントでさえ同じであると示唆しています。ただし、突然のトラフィックの急増や偶発的なメモリリークが発生した場合に備えて、ヒープのサイズ変更オプションをアプリケーションに提供するために、これらの値の間に10〜20%のバッファを配置することをお勧めします。
2.アプリケーションをより小さなヒープサイズで開始する必要があるかどうか
-つまり、これが重要です-使用するGC Algo(G1でも)に関係なく、大きなヒープには常にトレードオフがあります。目標は、レイテンシとスループットの観点から、GCの一時停止を許可できるヒープサイズに対するアプリケーションの動作を特定することです。
-たとえば、アプリケーションに多数のスレッドがあり(各スレッドには、ヒープではなくネイティブメモリに1 MBのスタックがあります)、重いオブジェクトスペースを占有しない場合は、Xmsの値を低くすることをお勧めします。
-アプリケーションがスレッド数の増加に伴って多数のオブジェクトを作成する場合は、それらのSTW一時停止を許容するように設定できるXmsの値を特定します。これは、許容できる着信要求の最大応答時間を特定し、それに応じて最小ヒープサイズを調整することを意味します。