JRockit JVMの最適化チェックリスト／チューニングガイド
Pages: 1, 2, 3

反復的なパフォーマンステストのシナリオとアプローチ

初期データの収集および分析が完了したら、反復的にJVMをチューニングすることができます。以下で紹介するテストは、特定のアプリケーションに有 効な設定を確認するためにJRockit JVM層で反復的なチューニングを行う場合の、一般的な方法を示したものです。ここでは、パフォーマンス結果の測定方法が用意されており、すでに定められ ている基準と結果を比較できるものと仮定します。

テスト1：スレッドのローカル領域のサイズとラージオブジェクトのサイズ

このテストでは、スレッドのローカル領域のサイズをチェックします。スレッドのローカル領域のサイズが重要なのは、これらのフラグのデフォルト設定 がアプリケーションに適していなかった場合（ほとんどの場合は適していますが）、ヒープに対するロックが取得され、パフォーマンスに影響するためです。大 半のオブジェクトがこの制限内にあれば、全体的なパフォーマンスにとって有益です。

  • 「収集」段階のJRA記録のデータを分析します。
  • 結果を分析して、-XXtlasizeおよび-XXlargeobjectlimitのチューニングが必要かどうかを確認します。このとき、ほと んどのアプリケーションでは、スレッドのローカル領域のサイズはラージオブジェクトのサイズの2 倍以上必要であることに注意します（eDocsを参照）。これはJRA記録の最初のページの右上に表示されます。tlaSizeの詳細についてはこちらを、largeObjectLimitの詳細についてはこちらを参照してください。JRockit R27.3より以降のバージョンでは、ほとんどの場合これらのフラグをチューニングする必要はありません。

メモ：プロファイリングや測定作業が正常な状態で行われるように、アプリケーションのウォームアップが完了するまで十分な時間をとっ てください。プロファイリング中にこの点を確認するには、JRA記録内の「最適化」タブを参照します。ここに表示される最適化回数と最適化にかかった時間 が、プロファイリングの前後でほぼ同じである（完全に同じであるのが理想）必要があります。

テスト2：ロックのプロファイリング

次に、ロックのプロファイリングをチェックします。アプリケーション内に過剰なロックがないかどうかが、ここからわかります。過剰なロックが存在すると全体的なパフォーマンスに影響します。

  • -Djrockit.lockprofilingを有効にしてテストを実行し、その結果を分析します。JVMからログが有効にされていないことを 確認します。このフラグを指定すると、5～10％のオーバーヘッドが発生し、このデータを収集するために別個のテストが実行されます。このテストではパ フォーマンスは無視され、ロック分析が唯一の分析対象となります。

    -server -Xms1536m -Xmx1536m -Djrockit.lockprofiling
     
  • 同じテスト中に、アプリケーションのウォームアップが完了してから、jrcmd.shユーティリティまたはJRockit Mission Control（JRMC）を使用して10分間のJRA記録を取ります。このツールの使用方法については、eDocsを参照してください。
  • topおよびiostatを使用してオペレーティングシステムを監視し、必要な場合は、ctrhandler.actファイルに指定した情報でスレッドダンプを作成します。
  • 結果を分析します。

テスト3：tlaSizeおよびlargeObjectLimitのチューニング

このテストでは、これまでのテストの結果に従って、スレッドのローカル領域のサイズとラージオブジェクトの制限のチューニングぶりをチェックします。

  • JVMからログが有効にされていないことを確認します。-XXtlaSizeおよび-XXlargeobjectlimitの値を大きくすると効 果がある場合がありますが、 その場合、長時間かけてテストを実施し、確認、比較する必要があります。R27.2では、preferredSizeを16kに設定すると効果がある場合 があります。この問題の詳細については、こちらを 参照してください。これを実施するには、TLA設定を変更し、テスト1と同じJavaコマンドラインオプションを指定してテストを再実行します。このと き、-XXtlaSizeおよび-XXlargeobjectlimitの各TLA設定に値を指定して追加します。tlaSizeの詳細については、こちらを参照してください。 メモ：R27.3以降のバージョンでは、通常はパフォーマンスを向上するためにこれらのフラグをチューニングする必要はありません。これらのフラグをチューニングしすぎると逆効果になる可能性があります。
  • 同じテスト中に、アプリケーションのウォームアップが完了してから、jrcmd.shユーティリティまたはJRockit Mission Control（JRMC）を使用して10分間のJRA記録を取ります。このツールの使用方法については、eDocsを参照してください。
  • topおよびiostatを使用してオペレーティングシステムを監視し、必要な場合は、ctrhandler.actファイルに指定した情報でスレッドダンプを作成します。
  • 結果を分析します。

テスト4：ガーベッジコレクションのアルゴリズムのチューニング

このセクションで説明するテストの目的は、ガーベッジコレクションのアルゴリズムを別のさまざまな設定に変えて実行し、その結果からアプリケーションに最適な設定を判断することにあります。-XXsetGCフラグの詳細については、こちらを 参照してください。JRockitを実行すると、ナーサリ（子供部屋）領域のサイズがチューニングされ、-Xgcprio:throughputフラグが 削除されます。throughputオプションを使用するとガーベッジコレクタのこの2つのバージョンが自動的に切り替わりますが、バージョンを直接選択 した方がパフォーマンスがさらに向上する可能性があります。ナーサリ領域をチューニングする目的は、昇格するオブジェクトの数を最小限に抑えることにあり ます。この部分がナーサリコレクションの中で負荷のかかる部分に当たるからです。これをチューニングするには、ナーサリ領域のサイズを拡大または縮小しま す。ナーサリ領域内のオブジェクトは、必要なオブジェクトであればYC中に昇格を果たすので、ナーサリ領域のサイズは基本的にオブジェクトの寿命に依存し ます。jrcmd <PID> versionを実行して、現在アクティブになっているガーベッジコレクタの実施方法を確認します。

  1. テスト4-1：
    1. -XXsetGC を使用してガーベッジコレクションのアルゴリズムを設定し、テストを実行します。この場合、ガーベッジコレクションのオプションは、 並列型マークアルゴリズムと 並列型スイープアルゴリズムを使用した シングルスペースに設定されます。また、ナーサリ領域のサイズも次のように手動でチューニングされます。
      -server -Xms1536m -Xmx1536m -Xns:384m -Xverboselog:perTestGC.log
      -Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
      -Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC: singleparpar
    2. 同じテスト中に、アプリケーションのウォームアップが完了してから、jrcmd.shユーティリティまたはJRockit Mission Control（JRMC）を使用して10分間のJRA記録を取ります。このツールの使用方法については、eDocsを参照してください。
    3. topおよびiostatを使用してオペレーティングシステムを監視し、必要な場合は、ctrhandler.actファイルに指定した情報でスレッドダンプを作成します。
    4. 結果を分析します。
  2. テスト4-2：
    1. -XXsetGCを使用してガーベッジコレクションのアルゴリズムを設定し、テストを実行します。この場合、ガーベッジコレクションのオプションは、 並列型マークアルゴリズムと 並列型スイープアルゴリズムを使用した 世代別（2スペース）に設定されます。また、ナーサリ領域のサイズも次のように手動でチューニングされます。
      -server -Xms1536m -Xmx1536m -Xns:384m -Xverboselog:perTestGC.log
      -Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
      -Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC: genparpar
    2. 同じテスト中に、アプリケーションのウォームアップが完了してから、jrcmd.shユーティリティまたはJRockit Mission Control（JRMC）を使用して10分間のJRA記録を取ります。このツールの使用方法については、eDocsを参照してください。
    3. topおよびiostatを使用してオペレーティングシステムを監視し、必要な場合は、ctrhandler.actファイルに指定した情報でスレッドダンプを作成します。
    4. 結果を分析します。
  3. テスト4-3： -XXsetGC:genparparに対して同様のテストを実行し、その結果に応じてナーサリ領域のサイズを拡大または縮小します。
  4. テスト4-4： -Xgc:gencon -Xns50mで試します（指標を収集するようにログを設定）。
  5. テスト4-5： -Xgc:parallel -XXcompactratio:1で試します（指標を収集するようにログを設定）。

テスト5：ガーベッジコレクションのスレッドのチューニング

このテストの目的は、gcthreadsフラグの値を設定した場合に全体的なパフォーマンスが向上するかどうかを確認することです。

  • これまでのテスト結果に従って、-XXgcthreadsフラグを実際の物理的なCPUの数にチューニングし、テストを再実行します（ここに入る 値はデフォルトでマシンのコアとハードウェアスレッドの数に基づいているため、このフラグは自動的にチューニングされるはずです）。これについては、「ト ラブルシューティングデータの収集」セクションで収集した詳細な出力ログファイルを参照すると確認できます。gcThreadsフラグの詳細については、こちらを参照してください。

テスト6：ロックの競合のチューニング

ファットロックの競合が発生している場合、-XXdisableFatSpinを使用して無効にすることができます。または、- Djrockit.useAdaptiveFatSpin=trueを使用すると、JRockitによって適応的に無効化されます。ロックの競合が発生し ているかどうかは、テスト2で-Djrockit.lockprofilingを有効にしたときに、JRAの該当するタブで確認できます。JRockit のロックの詳細については、こちらを参照してください。

テスト7：Xeonハードウェアのチューニング

Xeonハードウェアを使用している場合は、-XXallocPrefetchおよび-XXallocRedoPrefetchを追加してメモリ割 り当ての負荷を減らしたうえで、TLAおよびLargeObjectLimitを使用すると効果があります。allocPrefetchフラグの詳細につ いては、こちらを 参照してください。最善の結果を得るため、BIOSでハードウェアのプリフェッチを無効にすることもできます。その方法はBIOSの種類によって異なりま すが、パラメータは一般的に「Hardware Prefetcher」（ハードウェアプリフェッチ）、「Adjacent Sector Prefetcher」（隣接セクタのプリフェッチ）、「Adjacent Cache Line Prefetcher」（隣接キャッシュラインのプリフェッチ）のような名前になっています。これについては、 Intelで詳細をご確認ください。

テスト8：ヒープをlargePagesに入れる

この操作を行うと、ヒープがメモリ内に閉じ込められ、オペレーティングシステムによってスワップされなくなります。largePagesフラグの詳細については、こちらを参照してください。また、Linuxオペレーティングシステムでの設定については、下の「Linuxでの-XXlargePagesの設定」 セクションを参照してください。JRockit R27バージョンでは、このオプションは-XlargePagesになっています。これまでの結果によっては、-XlargePagesフラグをチューニ ングして効果がある場合と効果がない場合があります。このフラグを指定してテストを実行し、結果を見て全体的なパフォーマンスが向上しているかどうかを確 認します。

テスト9：-XXaggressiveフラグを使用したテスト

これは、JVMが高速で実行され、できる限り短時間で安定した状態になるようにするための設定を集めたものです。この目標を達成するため、JVMの 起動時に使用される内部リソースは多くなりますが、目標を達成したら最適化に必要な適応処理の作業が少なくて済みます。実行時間が長く、メモリの使用量が 多い単独のアプリケーションには、このオプションを使用することをお勧めします。-XXaggressiveフラグの詳細については、こちらを参照してください。-XXaggressiveフラグを使用してテストを実行し、結果を見て全体的なパフォーマンスが向上しているかどうかを確認します。

テスト10：-XX:+UseNewHashFunctionフラグを使用したテスト

このオプションを使用すると、高速性の増した新しいハッシュマップ用ハッシュ機能を使用できます。この機能は、Java 5.0 Update 8から導入され、R27.1.0以降のBEA JRockitに含まれています。このハッシュ機能を使用すると、ハッシュの分散が改善されるためパフォーマンスを向上できますが、ハッシュマップ内の要 素の格納順序が変わります。UseNewHashFunctionフラグの詳細については、こちらを参照してください。-XX:+UseNewHashFunctionフラグを使用してテストを実行し、結果を見て全体的なパフォーマンスが向上しているかどうかを確認します。

テスト11：ダークマターの削減

「ダークマター」とは無駄になっているヒープメモリのことであり、ヒープを分断する原因となっています。ヒープを圧縮する必要があるとき、全体的な スループットに影響しないようにダークマターを最小限に抑える必要があります。そのためには、次のオプションを検討してください。

  • 世代別ガーベッジコレクタ（-Xgc:genconまたは-Xgc:genpar）を使用します。若い世代のコレクション（ナーサリガーベッジコ レクション）の実行中に、ナーサリ領域にある必要なオブジェクトが古い世代の領域に移動させられます。これには、オブジェクトが移動時に圧縮されるという 副次的効果もあります。
  • 圧縮比を増加します（-XXcompactionRatio=nn）。圧縮すると、オブジェクトがコンパクトサイズのチャンクに移され、その間にあったダークマターが削除されるため、ダークマターの数が減ります。
  • -XXminBlockSize:<memSize>オプションを使用して、何をダークマターと見なすかの基準を変更します。ダーク マターと見なされるのは、ヒープ上にある最小ブロックサイズよりも小さいブロックです。したがって、最小ブロックサイズをさらに小さくすると、ダークマ ターが少なくなります。ただし、JRockitでヒープの空き容量をさらに細かく検索する必要が出てくるため、ガーベッジコレクションにかかる時間が長く なります。デフォルトでは最小ブロックサイズは2KBです。

その他のテスト：アプリケーションサーバ層のチューニング

最後に、ここで紹介した推奨されるチューニング方法を再確認して、WebLogic Serverのインスタンス層のチューニングを検討してください。

Pages: 1, 2, 3

Next Page »