| Oracle® JRockitパフォーマンス・チューニング・ガイド リリースR28 B61439-02 |
|
 前 |
 次 |
この章では、JVMのメモリー管理システムのチューニングに使用できる重要なオプションについて説明します。
メモリー管理とは、結局のところ、オブジェクトをどのように割り当てるかということです。メモリー管理システムは、新しいオブジェクトのための空き領域を探す役割と、古いオブジェクトにガベージ・コレクションを行って新しいオブジェクトのための空き領域を作成する役割を果たします。Javaアプリケーションが割り当てるオブジェクトの数が多いほど、メモリー管理に多くのリソースが使用されます。メモリー管理システムが適切にチューニングされていれば、ガベージ・コレクションによるオーバーヘッドは最小限に抑えられ、オブジェクトの割当てが高速化します。
この章の内容は次のとおりです。
Oracle JRockit JVMにおけるメモリー管理の詳細は、『Oracle JRockit JDKの紹介』のメモリー管理の概要に関する項を参照してください。
ヒープは、Javaオブジェクトが格納されている領域です。ヒープ・サイズは、JVMおよびJavaアプリケーションのパフォーマンスに影響します。
JVMが世代別のガベージ・コレクション方式を使用する場合、ヒープの一部がナーサリとして確保されます。小規模なオブジェクトはすべてナーサリ(若い領域)に割り当てられます。ナーサリが一杯になると、若いコレクションが行われ、ナーサリでずっとアクティブであったオブジェクトが古い領域(ヒープの残りの領域)に移動します。
最近割り当てられたオブジェクトと、ナーサリ内に一定の期間存在していたオブジェクトを見分けるために、JVMは保持領域を使用します。保持領域には、ナーサリ内に最近割り当てられたオブジェクトが保管されます。またこの領域は、次の若いコレクションまではガベージ・コレクションは行われません。
コマンドライン・オプション: -Xms:size -Xmx:size
ヒープ・サイズは、割当ての速度、ガベージ・コレクションの頻度、ガベージ・コレクションの実行時間に影響します。ヒープが小さいとすぐに一杯になるため、頻繁にガベージ・コレクションを行う必要があります。ヒープが大きいと、ガベージ・コレクションの実行時間にオーバーヘッドが生じます。システム内の利用可能な物理メモリーよりもヒープが大きいと、ディスクにページ・アウトしなければならないため、アクセス時間が長くなり、特にガベージ・コレクション中にアプリケーションのフリーズを招くおそれがあります。
通常は、ヒープのページ・アウトが発生しないかぎり、大きなヒープによる追加オーバーヘッドは、ガベージ・コレクション頻度の増加や割当て速度によって発生するオーバーヘッドよりも小さくてすみます。適切なヒープ・サイズは、利用可能な物理メモリーを超えない範囲でできるだけ大きいヒープです。
ヒープ・サイズの設定のパラメータは、以下の2つです。
-Xms:sizeはヒープの初期サイズと最小サイズを設定します。
-Xmx:sizeはヒープの最大サイズを設定します。
例:
java -Xms:1g -Xmx:1g MyApplication
このコマンドによって、ヒープ・サイズが1GBに固定されたJVMが起動します。
アプリケーションで決められた最適なヒープ・サイズが分かっている場合は、-Xmsおよび-Xmxをその最適値に設定することをお薦めします。このように設定すると、起動時から、最適なヒープ・サイズに調整された環境でアプリケーションを実行できます。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
64ビット・システムでは、メモリー・アドレスが64ビット長であるため、32ビット・アドレスのシステムよりも多くのメモリーに対応できます。参照ごとに2倍のメモリーも必要になります。64ビット・システムにおけるメモリーの使用状況を緩和するために、JRockit JVMは圧縮参照を使用します。圧縮参照は参照を32ビットに削減します。これは、ヒープ全体を32ビットで対応できれば、使用することが可能です。使用可能な場合、圧縮参照は常にデフォルトで有効になっています。
様々なアドレスのビットおよびヒープ・サイズに対する圧縮参照は、-XXcompressedrefsコマンドライン・オプションを使用して変更できます。-XXcompressedrefsおよびそのパラメータの詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -Xns:size
ナーサリのサイズは、割当ての速度、ガベージ・コレクションの頻度、ガベージ・コレクションの実行時間に影響します。ナーサリが小さいとすぐに一杯になるため、頻繁にガベージ・コレクションを行わなければなりませんが、ナーサリを大きくしてもガベージ・コレクションにかかる時間はわずかに長くなるだけです。ごく小さいナーサリには、若いコレクションが開始する前に生存期間の過ぎたオブジェクト数が少ないか、または一切ないため、ほとんど役に立ちません。あまりにも大きいナーサリも役に立ちません。このようなナーサリでは、古い領域に大規模オブジェクトを割り当てるために発生するヒープ全体のガベージ・コレクション間に若いコレクションが行われないためです。
アプリケーション・スループットの最大化を実現する最適なナーサリ・サイズは、空きヒープの半分ぐらいのサイズです。この目標は、古いコレクションではなく若いコレクションによって、できるかぎり多くのオブジェクトのガベージ・コレクションが行われることです。JRockit JVMでは、スループットを優先して最適化する動的ガベージ・コレクションのモードの-Xgc:throughputと、静的世代別パラレル・ガベージ・コレクタの-Xgc:genparが、ほぼ最適値になるようにナーサリ・サイズを動的に設定します。
スループットを実現する最適なナーサリ・サイズは、通常はかなり大きいため、若いコレクション時間が長くなります。若いコレクションの実行中はすべてのJavaスレッドが休止するため、ナーサリ・サイズを最適値より低く設定し、若いコレクションの休止時間を短かくしたほうがよい場合があります。
例:
java -Xns:100m MyApplication
このコマンドによって、ナーサリ・サイズが100MBに固定されたJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -XXkeepAreaRatio:percentage
保持領域のサイズは、古いコレクションと若いコレクションの両方の頻度に影響します。保持領域が大きいと、若いコレクションが頻繁に行われますが、保持領域が小さすぎると、オブジェクトが早期に昇格するときに古いコレクションが頻繁に行われます。
最適な保持領域のサイズは、昇格率を低く維持できる範囲で、できるだけ小さい値です。昇格率は、フライト・レコーダ記録や、-Xverbose:memory=debugからの冗長出力、-Xverbose:gcreportによって出力されるガベージ・コレクション・レポートで確認できます。
保持領域のサイズは、ナーサリの割合として定義されます。
例:
java -XXkeepAreaRatio:10 MyApplication
このコマンドによって、ナーサリ・サイズの10%の保持領域が設定されたJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
ガベージ・コレクションの影響は、選択したガベージ・コレクションの方法に応じて、様々な手法で分散させることができます。-Xgc:modeコマンドライン・オプションを使用して、ガベージ・コレクション・モードを指定します。
-Xgcオプションの詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
この項の内容は次のとおりです。
ガベージ・コレクション・モードは使用するモードに応じて特定の目的を優先して最適化されるため、実行時にメモリー管理システムを調整します。
ガベージ・コレクション・モードを次に示します。
throughput: アプリケーションのスループットを最大化するためにガベージ・コレクタを最適化します。
pausetime: 休止時間を短く、均等にするためにガベージ・コレクタを最適化します。
deterministic: 休止時間を非常に短く、確定的にするためにガベージ・コレクタを最適化します。
ガベージ・コレクション・モードは、高度なヒューリスティックを使用して次のパラメータを実行時に調整します。
ナーサリ・サイズ
圧縮の量と種類
コマンドライン・オプション: -Xgc:throughput
スループット・モードは世代別ガベージ・コレクタ(-Xgc:genparまたは、-Xgc:throughputのみが指定されている場合)、もしくは非世代別ガベージ・コレクタ(-Xgc:singleparまたは-Xgc:parallelが指定されている場合)のいずれかを使用できます。
throughputモードは、必要最小限のCPUリソースしか使用しないため、Javaアプリケーションに割り当てられるCPUサイクルが最大になります。JRockit JVMは、ガベージ・コレクションの全期間を通してJavaアプリケーションを停止し、利用可能なすべてのCPUを使用してガベージ・コレクションを行うパラレル・ガベージ・コレクタを使用することによって、これを実現します。個々のガベージ・コレクションの停止時間は長くなる可能性がありますが、全体としては、ガベージ・コレクタが消費するCPU時間を必要最小限に抑えられます。
throughputモードは、高いスループットを必要とする一方で、ガベージ・コレクションによる休止時間がときどき長くなってもあまり影響を受けないアプリケーションに使用します。
throughputモードは、JVMが-serverモード(デフォルト)で実行される場合のデフォルトです。または、-Xgc:throughputオプションを使用して有効にすることもできます。
例:
java -Xgc:throughput MyApplication
このコマンドによって、スループットを優先して最適化されたガベージ・コレクション・モードでJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -Xgc:pausetime
休止時間モードは世代別ガベージ・コレクタ(-Xgc:genconまたは、-Xgc:pausetimeのみが指定されている場合)、もしくは非世代別ガベージ・コレクタ(-Xgc:singleconが指定されている場合)のいずれかを使用できます。
pausetimeモードは、可能なかぎり高いスループットを維持しながらも、ガベージ・コレクションの休止時間を所定の目標休止時間以内に抑えることを目標としています。JRockit JVMはこの目標を達成するため、ガベージ・コレクション期間のほとんどの間、Javaアプリケーションを実行し続けることが可能なモーストリ・コンカレント・ガベージ・コレクション方式を使用します。
pausetimeモードは、長いレイテンシの影響を受けやすいアプリケーション(トランザクション時間を一定にする必要のあるトランザクションベースのシステムなど)で使用します。
例:
java -Xgc:pausetime MyApplication
このコマンドによって、休止時間の短縮を優先して最適化されたガベージ・コレクション・モードでJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -XpauseTarget:time
pausetimeモードは、目標休止時間を使用して休止時間を最適化します。目標休止時間はアプリケーションのスループットに影響します。目標休止時間を短く設定すると、メモリー管理システムに課されるオーバーヘッドが増加します。
目標休止時間には、アプリケーションで許容される最長の値を設定してください。
例:
java -Xgc:pausetime -XpauseTarget:300 MyApplication
このコマンドによって、短い休止時間と、目標休止時間の300ミリ秒を優先して最適化されたガベージ・コレクション・モードでJVMが起動します。
pausetimeモードの目標休止時間はデフォルトで500ミリ秒に設定されています。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -Xgc:deterministic
deterministicモードは、ガベージ・コレクションの休止時間を非常に短く抑え、さらに合計の休止時間が所定の枠内に収まるようにします。JRockit JVMは、ガベージ・コレクション期間中もできるかぎりJavaアプリケーションを実行し続けるモーストリ・コンカレント・ガベージ・コレクタを使用して、これを実現します。
deterministicモードは、レイテンシを短く確定的にする必要があるアプリケーション(証券業アプリケーションなどのトランザクションベースのアプリケーション等)に使用します。
例:
java -Xgc:deterministic MyApplication
このコマンドによって、短く確定的な休止時間を優先して最適化されたガベージ・コレクション・モードでJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
確定的なガベージ・コレクションの実行時間は、JRockit Mission Control Clientの影響を受けることがあります。確定的なガベージ・コレクタを使ってOracle WebLogic Real Timeを実行する場合、すべてのJRockit Mission Controlツールが完全にサポートされますが、次の点に注意する必要があります。
-Xmanagementオプションが単独で確定的なガベージ・コレクションの休止時間を長くすることはありませんが、JVMによって実行されるJavaコードの量を多少増やす原因にはなります。-Xmanagementオプションを使用しない場合に比べて、これがレスポンス時間とパフォーマンスに影響を与える可能性があります。
JRockitフライト・レコーダを使用して記録を作成するときに、情報収集のための休止時間を許容できないような、待機時間の影響を受けやすい状況でアプリケーションを実行する場合は、ヒープの統計(heapstat)を無効にしてください。heapstatでは、ヒープの内容に関する追加のブックキーピングが提供されます。これらの統計はフライト・レコーダ記録の最初と最後の休止時間の中で収集されます。heapstatを無効にするには、記録をリクエストするときに特定の引数を使用します。
heapstatが無効になっている場合でも、JRockitフライト・レコーダ記録によって、確定的ガベージ・コレクションの休止時間が若干長くなることがあります。
JRockitフライト・レコーダ記録と同様に、メモリー・リークの傾向分析によってもガベージ・コレクションの休止時間が長くなることがあります。
メモリー・リーク・ディテクタがグラフィカル・ユーザー・インタフェースまたは診断コマンドを使用しているときに、より多くの情報をリクエストすると、休止時間が長くなることがあります(あるタイプのオブジェクトのインスタンスの数を取得する場合や、インスタンスやクラスへの参照のリストを取得する場合など)。
JRockit Mission Controlの詳細は、Oracle JRockit Mission Controlオンライン・ヘルプを参照してください。
コマンドライン・オプション: -XpauseTarget:time
確定的モードは、目標休止時間を使用して休止時間を最適化します。目標休止時間はアプリケーションのスループットに影響します。目標休止時間を短く設定すると、メモリー管理システムに課されるオーバーヘッドが増加します。
目標休止時間には、アプリケーションで許容される最長の値を設定してください。
ガベージ・コレクタは、ガベージ・コレクションの休止時間を所定の目標休止時間以内に抑えることを目指します。この目標の成否は、アプリケーションおよびハードウェアによって異なります。たとえば、ヒープが1GBで、コレクション時のライブ・データが平均で30%以下のアプリケーションを以下のハードウェアで実行する場合、目標休止時間は30ミリ秒で検証されます。
2 x Intel Xeon 3.6GHz、2MBレベル2キャッシュ、4GB RAM
4 x Intel Xeon 2.0GHz、0.5MBレベル2キャッシュ、8GB RAM
低速なハードウェアでアプリケーションを実行している、ヒープ・サイズが異なる、ライブ・データが多いなどの条件下では、確定的な動作が維持されなかったり、時間の経過に応じてパフォーマンスが低下するおそれがあります。高速なハードウェアを使用するか、ライブ・データを少なくすると、目標休止時間を低く設定することができます。
例:
java -Xgc:deterministic -XpauseTarget:40ms MyApplication
このコマンドによって、確定的かつ短い休止時間と、目標休止時間の40ミリ秒を優先して最適化されたガベージ・コレクション・モードでJVMが起動します。
deterministicモードの目標休止時間はデフォルトで30ミリ秒に設定されています。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
アプリケーションに最適なガベージ・コレクション方式を選択するには、次のワークフローに従います。
ガベージ・コレクションの休止期間が長い場合(500ミリ秒以上)、アプリケーションは影響を受けやすいですか?
はい: モーストリ・コンカレント・ガベージ・コレクション・モードのgenconまたはsingleconを選択します。
いいえ: パラレル・ガベージ・コレクション・モードのgenparまたはsingleparを選択します。
アプリケーションは多数の一時オブジェクトを割り当てますか?
はい: 二世代のガベージ・コレクション・モードのgenconまたはgenparを選択します。
いいえ: 一世代のガベージ・コレクション・モードのsingleconまたはsingleparを選択します。
たとえば、Oracle WebLogic SIP Serverは、各トランザクションに新しいオブジェクトを割り当てるトランザクションベースのシステムであり、トランザクションのタイムアウトは短く設定されています。ガベージ・コレクションによる休止時間が長いと、トランザクションがタイムアウトするため、モーストリ・コンカレント・ガベージ・コレクション(genconまたはsinglecon)を使用します。トランザクションでは多数の一時的な(短い間しか生存しない)オブジェクトが生成されるため、二世代のガベージ・コレクション・モード(gencon)が適切です。
静的なガベージ・コレクション方式は、-Xgc:modeオプションで設定します。
例:
java -Xgc:gencon MyApplication
このコマンドによって、世代別コンカレント・ガベージ・コレクタが設定されたJVMが起動します。
コマンドライン・オプション: -XXgcTrigger:value
ガベージ・コレクションで(マーク・フェーズまたはスイープ・フェーズで、あるいは両方のフェーズで)コンカレント方式を使用している場合、ガベージ・コレクションのコンカレント・フェーズでヒープの空き領域が不足するのを回避するために、JRockit JVMは古い世代のガベージ・コレクションを開始するタイミングを自動的に調整します。このトリガーは、前回のコレクション後にヒープ内で使用可能になった領域の大きさなどの要素に基づいて決定されます。JVMが使用可能な領域の最適化を動的に行おうとして、コンカレント・ガベージ・コレクション中に空きヒープがなくなる場合もあります。この状態が発生すると、次のような冗長出力が-Xverbose:memdbgオプションを使用中の場合に表示されます。
[DEBUG][memory ] [OC#55] Starting parallel sweeping phase. [DEBUG][memory ] [OC#55] Will run parallel sweep due to: Alloc Queue Not Empty. or [DEBUG][memory ] [OC#55] Will run parallel sweep due to: Promotion Failed.
このメッセージは、コンカレント・スイープを時間内に終了できなかったため、JVMが使用可能なすべてのリソースをスイープのために使用していることを表します。この場合は、パラレル・スイープが行われます。JVMが正しく適合されず、この出力が繰り返し表示される場合は、パフォーマンスに悪影響が生じます。
この事態を避けるには、-XXgcTriggerオプションを設定して、指定したヒープの割合が残っている時点でガベージ・コレクションがトリガーされるようにします。
例:
java -XXgcTrigger:20 MyApplication
このコマンドによって、空きヒープのサイズの20%未満が未使用のままになると、古い世代のガベージ・コレクションがトリガーされます。
(マーク・フェーズとスイープ・フェーズの両方で)パラレル・ガベージ・コレクション方式を使用している場合は、ヒープが完全に一杯になると古い世代のガベージ・コレクションが実行されます。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
圧縮は、割当て済み領域のチャンクをヒープの下部に移動して、連続した空きメモリーをヒープの上部に作成できるようにするプロセスです。JRockit JVMでは、古いコレクションの実行時にヒープの部分的な圧縮を行います。使用されるガベージ・コレクションのモードに応じて、圧縮領域のサイズと位置、および圧縮方式が、高度なヒューリスティックによって選択されます。
多数のオブジェクトが割り当てられている大きな領域を圧縮すると、ガベージ・コレクションの休止時間が長くなります。一方、圧縮が十分に行われない場合、ヒープが断片化し、パフォーマンスが低下します。断片化が長期にわたって進行すると、JRockit JVMは、ガベージ・コレクションによる長い休止時間を伴うヒープの完全な圧縮を行うか、OutOfMemoryErrorのスローを行わざるを得なくなります。
アプリケーションで長期的なパフォーマンスの低下が断続的に発生する場合、たとえば低下を続けていたパフォーマンスが突然良好な状態に戻り、その後再び低下し始める場合は、おそらく断片化の問題が発生しています。ヒープの断片化は古いコレクションが行われるたびに進行し、やがてオブジェクトの割当てができなくなります。そうすると、JVMはヒープの完全な圧縮を行わざるを得なくなります。完全な圧縮を行うと断片化が解消しますが、次のガベージ・コレクションを開始するとまた断片化が発生します。これは、JRockit Mission Controlの管理コンソールを通じてJVMを監視する-Xverbose:memory出力で確認するか、またはJRockitフライト・レコーダ記録を作成してガベージ・コレクション・データを検証することで確認できます。古いコレクション後に使用されるヒープの量が長期的に増加し続け、最大値に達した後、次の古いコレクション時に再び低下する場合は、断片化の問題が発生しています。
断片化の進行が遅く、一定している場合は、圧縮が適切にチューニングされていると考えられます。
JRockit JVMの圧縮のヒューリスティックはガベージ・コレクションの休止時間を短く均等に保つように設計されていますが、状況によっては、圧縮率を制限してガベージ・コレクションの休止時間をさらに軽減したほうがよい場合もあります。また、ヒープの断片化を管理するために圧縮率を高くしたほうがよい場合もあります。
圧縮率を調整するには、次のいずれかの手法を使用します。
コマンドライン・オプション:-XXcompaction:percentage=value
静的な圧縮率を設定すると、JVMで、古いコレクションのたびに指定の割合でヒープの圧縮が行われます。これにより、ヒープのレイアウトに基づいて動的に圧縮率を選択するヒューリスティックが無効になります。-XXcompaction:percentageオプションを使用して、圧縮率にヒープの静的な割合を設定することができます。
例:
java -XXcompaction:percentage=5 MyApplication
このコマンドによって、ヒープの5%の静的圧縮率が設定されたJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
JVMで、デフォルトで選択される値よりも低い圧縮率または高い圧縮率を使用する場合は、このオプションを使用してください。圧縮率は、-Xverbose:compaction出力およびJRockitフライト・レコーダ記録で監視できます。圧縮率が高いと、ヒープの断片化を低く抑えることができますが、圧縮による休止時間が長くなります。
コマンドライン・オプション: -XXcompaction:maxReferences=value
圧縮によってオブジェクトが移動した場合は、そのオブジェクトへの参照を更新する必要があります。ガベージ・コレクタは、Javaスレッドが再実行できるようになる前に参照の更新を行います。更新された参照の数に比例して、ガベージ・コレクションによる休止時間が長くなります。
圧縮領域外のオブジェクトから圧縮領域内のオブジェクトへ存在する参照の最大数は、使用するガベージ・コレクション・モードによって異なり、一部のモードでは実行時に動的に調整されます。
圧縮による休止時間を制限するには、-XXcompaction:maxReferencesオプションを使用して、静的な最大参照数を指定します。ガベージ・コレクション中に、選択した圧縮領域への参照数が指定したmaxReferences値を超えると、圧縮は取り消されます。
例:
java -XXcompaction:maxReferences=20000 MyApplication
このコマンドによって、最大参照数が20000に設定されたJVMが起動します。
圧縮の動作と圧縮の休止時間は、-Xverbose:compaction出力とフライト・レコーダ記録で監視できます。取り消される(中止する)圧縮が多すぎる場合は、maxReferencesの値を大きくします。圧縮による休止時間が長すぎる場合は、maxReferencesの値を小さくします。
最大参照数の詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -XXcompaction:enable=false
圧縮を一切行わなくても長期間生存できるアプリケーションはわずかしかありませが、そのようなアプリケーションでは、圧縮を完全に無効にすることができます。
例:
java -XXcompaction:enable=false MyApplication
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
コマンドライン・オプション: -XXcompaction:full
一部のアプリケーションは、ガベージ・コレクションの休止時間にあまり影響を受けないか、古いコレクションをほとんど行いません。このようなアプリケーションについては、ガベージ・コレクション間のオブジェクト割当てのパフォーマンスを最大化するために、完全な圧縮を行ったほうがよい場合があります。ただし、多数のオブジェクトが割り当てられている大きなヒープに対して完全な圧縮を行うと、処理に数秒かかることがあります。
例:
java -XXcompaction:full MyApplication
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
オブジェクトの割当て用に領域を空けるガベージ・コレクションの最適化とは別に、オブジェクト割当て自体をチューニングして、アプリケーションのスループットを最大化することができます。
コマンドライン・オプション: -XXtlaSize:min=size,preferred=size,wasteLimit=size
スレッド・ローカル領域のサイズは割当て速度に影響しますが、ガベージ・コレクションの頻度にも影響します。TLAのサイズを大きく設定すると、新しいTLAをリクエストする前に各スレッドが多数のオブジェクトを割り当てることができます。さらにJRockit JVMでは、スレッド・ローカル領域に大規模オブジェクトを割り当てることが可能です。一方、TLAサイズを大きくすることで、空きメモリーの小さなチャンクがオブジェクト割当てに使用されなくなるため、断片化による影響が拡大します。TLAサイズは空き領域の利用可能なチャンクのサイズによって動的に決まり、最少サイズから推奨サイズの間で変動します。
推奨TLAサイズを増やすと、各スレッドが多数のオブジェクトを割り当てるアプリケーションに効果的です。二世代のガベージ・コレクション方式が使用されている場合、TLAの最少サイズと推奨サイズを大きく設定すると、ナーサリ内に大規模オブジェクトを割り当てることができます。推奨TLAサイズは、常に、ナーサリ・サイズの5%未満です。
ガベージ・コレクタは最少TLAサイズに満たない空きチャンクを無視するため、最少TLAサイズを大きくするとガベージ・コレクションの実行時間が多少短縮されます。
推奨TLAサイズを小さくすると、終了するまでにわずかなオブジェクトしか割り当てないスレッドを持つアプリケーションに効果的です。このようなアプリケーションは、大きなTLAサイズを一杯にできないからです。推奨TLAサイズを小さくすると、無数のスレッドを持つアプリケーションに効果的です。このようなアプリケーションでは、ガベージ・コレクションが行われる前に、スレッドがTLAを一杯にする時間がないからです。
最少TLAサイズを小さくすると、断片化への影響が減ります。
現在のTLAのメモリーが-XXtlaSize:wasteLimitオプションで指定された値を下回ると、スレッドは新規のTLAを最も早くリクエストします。-XXtlaSize:wasteLimitの値を低くすると使用可能なメモリーをより有効に活用できますが、TLA以外のメモリーでより遅いケースの割当てが発生します。-XXtlaSize:wasteLimitオプションの値を大きくすると遅い割当ては減少しますが、ガベージ・コレクションの頻度が増加します。-XXtlaSize:wasteLimitは、-XXtlaSize:minと同じ値に設定することをお薦めします。
TLAサイズは一般に、最少TLAサイズを2KB - 4KBに、推奨TLAサイズを16KB - 256KBに設定します。
例:
java -XXtlaSize:min=1k,preferred=512k MyApplication
このコマンドによって、最少TLAサイズが1KBで、推奨TLAサイズが512KBに設定されたJVMが起動します。
詳細は、『Oracle JRockitコマンドライン・リファレンス』を参照してください。
