JRockit JVM チューニング ガイド
![]() |
![]() |
![]() |
![]() |
アプリケーションで、説明のつかない奇妙な休止が起きたことはありませんか。 1 つまたはすべての CPU の利用率が 100% でその他は 0%、しかもシステムにはトランザクションがほとんどないという状況を経験したことはありませんか。 この 2 つの質問のいずれかに該当する場合、アプリケーションはガベージ コレクタの不十分な実行による影響を受けている可能性があります。 メモリ管理システムのチューニングをごく簡単に行うだけで、多くのアプリケーションではパフォーマンスを大幅に改善することができます。
BEA JRockit JVM には、そのままですぐに使用できるように、BEA JRockit JVM が動作する特定のプラットフォームに自動的に適応するデフォルト値が用意されています。 BEA JRockit JVM のチューニングは、非標準の (-X
) コマンドライン オプションを起動時に使用して行います。 -X
オプションは BEA JRockit JVM 専用です。 このオプションを使用して、BEA JRockit JVM の動作をユーザの Java アプリケーションのニーズに適合させます。
この節では、これらのオプションを使用して BEA JRockit をチューニングする方法について説明します。 内容は以下のとおりです。
注意 : BEA JRockit が予期しない動作をする場合は、BEA JRockit の開発者向け FAQ を参照してください。 それでも問題が解決しない場合は、support@bea.com まで電子メールをお送りください。
システムのパフォーマンスは、JVM で使用できる Java ヒープのサイズに大きく影響されます。 この節では、初期ヒープ サイズ、最大ヒープ サイズ、および世代別ガベージ コレクタで必要になるナーサリのサイズの定義に使用するコマンドライン オプションについて説明します。 また、BEA JRockit の実装に最適なヒープ サイズを決定するときに役立つ重要なガイドラインを示します。
-Xms
はヒープの初期および最小サイズを設定します。 このオプションには、最大ヒープ サイズと同じサイズを設定することをお勧めします。次に例を示します。
-java -Xgcprio:throughput -Xmx:64m
-Xms:64m
myClass
-server
モード : システムの空き物理メモリ量の 25% (最大 64MB、最小 8MB)。
-client
モード : システムの空き物理メモリ量の 25% (最大 16MB、最小 8MB)。
-Xmx:<size>
ほとんどの場合、最大ヒープ サイズは、アプリケーションまたは同じコンピュータ上の他のアプリケーションでページ フォールトを引き起こさない程度に、できる限り大きい値に設定します。 最大ヒープ サイズを設定するには、-Xmx
コマンドライン オプションを使用します。たとえば次のようにします。
-java -Xgcprio:throughput
-Xmx:64m
-Xms:64m myClass
これらのオプションで設定されるものは、将来のリリースで変更される可能性があります。ハードウェア プラットフォーム、オペレーティング システム、使用する BEA JRockit のバージョンなどの多くの要素によって、オプションの設定は変わります。 これらの条件に基づくガイドラインを表 2-1 に示します。
OutOfMemory エラーが発生した場合は、上記のガイドラインに従って最大ヒープ サイズを増やしてください。
-server
および -client
モード : デフォルト値は合計物理メモリの 75% と 1GB のうちの小さい方です。
-Xns:<size>
-Xns
は、世代別ガベージ コレクタにおける若い世代 (ナーサリ) のサイズを設定します。 ガベージ コレクションの休止時間をなるべく短くする一方で、ナーサリを可能な限り大きくするのが最適です。 このことは、多数の一時オブジェクトを作成する場合は特に重要です。
注意 : 休止回数を表示するには、BEA JRockit JVM の起動時に -Xgcpause
オプションを指定します。
ナーサリの最大サイズは最大ヒープ サイズの 95% を超えることはできません。
-server
モード : デフォルトのナーサリ サイズは CPU ごとに 10MB。たとえば、10 CPU のシステムでは 100MB になります。
-client
モード : デフォルトのナーサリ サイズは 2MB。
また、-Xns
を使用してより大きな値に明示的に設定しない限り、デフォルトのナーサリは最大ヒープ サイズの 25% を超えることはできません。
以下のガイドラインでは、最適なパフォーマンスを実現するためのヒープ サイズの設定方法についてヒントを提示します。 以下のガイドラインは、主として -server (デフォルト) 起動オプションの場合に有効です (「デフォルト ガベージ コレクタの設定」を参照)。
-Xms
と -Xmx
を同じ値に設定します。-Xms
を少なくとも実データの量と近い値に設定します。 -Xms
は実データの最小量の 2 倍と同じに設定できます。その場合でもヒープ サイズの自動的な再設定を妨げることはありません。 -Xmx
を設定しないか低い値に設定した場合、BEA JRockit がヒープを増加するまでにガベージ コレクションが頻繁に行われると、起動速度が低下する可能性があります。-Xmx
をシステムの使用可能な物理メモリ量よりも大きく設定しないようにしてください。 また、メモリの可用性に影響するため、JVM で同時に実行する他のアプリケーションのメモリ使用率も考慮する必要があります。-Xmx
を設定しない方が望ましいと思われるかもしれません。 これを設定しないと、システムのメモリが小さすぎるときに BEA JRockit がヒープを増加することができなくなります。 その結果、現在のヒープ サイズでオブジェクトの割り当てが失敗し、ページングを行わないとヒープを増加できなくなると、OutOfMemoryError が送出されることに注意してください。-Xmx
を設定しなくても、ページングが発生する可能性があります。 ヒープの半分以上を実データが占めている場合、BEA JRockit はヒープを縮小しません。 したがって、JRockit の起動後に空きメモリ量が減少しても (別のアプリケーションが起動した場合など)、BEA JRockit がヒープを縮小できない可能性があります。-Xmx
) を小さく設定すると、BEA JRockit が頻繁にガベージ コレクションを実行することになり、パフォーマンスが影響を受ける可能性があります。 「緊縮した」ヒープ (つまり、生存しているオブジェクトの量がヒープのサイズに近い場合) を想定していて、アプリケーションが生存期間の短いオブジェクトを多数割り当てる場合は、シングルスペース ガベージ コレクタ (-Xgc:singlecon
および -Xgc:parallel
) ではなく、世代別ガベージ コレクタ (-Xgc:gencon
) を使用することをお勧めします。
-Xcleartype:<gc|local|alloc>
-Xcleartype
は、ガベージ コレクションされたオブジェクトが占有しているメモリ領域がクリアされる時期を定義します。 クリアが実際に実行される時期は、表 2-2 に示すように、選択されるパラメータによって指定します。
-XclearType
が設定されていない場合、デフォルトは IA32 システムでは alloc
、IA64 システムでは local
です。
-Xss<size>[k|K][m|M]
-Xss<size>[k|K]
[m|M] はスレッド スタック サイズを設定します (単位は KB)。
最小スレッド スタック サイズは 16KB です。 -Xss
を最小値より小さく設定すると、スレッド スタック サイズのデフォルトは自動的に最小値に設定されます。
スレッド スタック サイズを省略した場合のデフォルト値は、BEA JRockit が動作するプラットフォームによって異なります。詳細については、表 2-3 を参照してください。
![]() ![]() |
![]() |
![]() |