Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
戻る |
次へ |
WebLogic Server および WebLogic Server アプリケーションのパフォーマンスのチューニングは、複雑で繰り返し実施しなければならない作業です。以下の節では、システム パフォーマンスの向上に利用できるチューニングのロードマップおよびヒントを示します。
ここでは、現在のアプリケーション環境をチューニングしてパフォーマンスを最適化するのに役立つロードマップを示します。
パフォーマンスの目標を決めるには、デプロイされているアプリケーションや、システム環境の制約について理解する必要があります。アプリケーションのコンポーネントの条件にかなうアクティビティのレベルに関する情報を収集してください。これには次のものが含まれます。
予想されるユーザの数
要求の数とサイズ
データの量と一貫性
目標とする CPU 使用率
目標とする CPU 使用率を 100% にすることはできません。目標とする CPU 使用率は、使用しているアプリケーションのニーズ (ピーク使用時の CPU サイクルなど) に基づいて決定する必要があります。通常の負荷時に CPU 使用率が 100% に最適化されている場合、ピーク時の負荷を処理するキャパシティが残っていないことになります。レイテンシに敏感なアプリケーションでは、高速な応答時間を実現できることが重要になります。CPU 使用率が高い (使用率が 100% に近づく) と、応答時間が長くなる場合があります。一方、スループットは一定に保たれるか、サーバで処理がキューイングされるため増大します。このようなアプリケーションでは、CPU 使用率を 70 ~ 80% にすることをお勧めします。レイテンシに敏感でないアプリケーションにおいては、90 % 程度を目標に設定することをお勧めします。
パフォーマンスの目標は、次のような制約によって制限されます。
CPU の種類、ディスク サイズとディスク速度の関係、メモリが足りているかどうかなど、ソフトウェアおよびハードウェアのコンフィグレーション
ハードウェア要件を決定するための一定の公式というのはありません。アプリケーションのニーズを十分に満たすために、必要なソフトウェアおよびハードウェア コンフィグレーションを決定するプロセスをキャパシティ プランニングといいます。キャパシティ プランニングでは、システム パフォーマンスの目標を評価し、アプリケーションを理解する必要があります。サーバ ハードウェアのキャパシティ プランニングでは、最大のパフォーマンス要件に焦点を絞って検討します。「キャパシティ プランニング」を参照してください。
ドメイン間での相互運用、レガシー システムの使用、およびレガシー データのサポートが可能かどうか
開発、実装、およびメンテナンスの費用
こうした情報を使用して、特定のハードウェアにおける応答時間、スループット、および負荷など、現在のアプリケーション環境における現実的なパフォーマンス目標を設定します。
「パフォーマンスに関する目標の設定」に示したパフォーマンス条件を決定したら、パフォーマンス目標を数値で示すために使用されるメトリックを測定します。「負荷テスト ツール」を参照してください。以下の節では、基本的なパフォーマンス メトリックの測定に関して説明します。
高い負荷をかけた状態でアプリケーションを実行して以下をモニタします。
アプリケーション サーバ (ディスクおよび CPU の使用率)
データベース サーバ (ディスクおよび CPU の使用率)
目的は、設定した目標の CPU 使用率をアプリケーション サーバが達成することです。アプリケーション サーバの CPU 使用率が低い場合は、データベースにボトルネックがないかどうかを確認します。データベースサーバの CPU 使用率が 100% に達する場合は、アプリケーションの SQL 呼び出しクエリのプランを見直します。たとえば、SQL 呼び出しで、インデックスを使用したりリニア検索を実行したりしていないかを確認します。また、データベース サーバの CPU に負荷がかかる ORDER BY
句を、アプリケーションで使用しすぎていないかどうかも確認します。「オペレーティング システムのチューニング」を参照してください。
データベース サーバのディスクがボトルネックになっている (ディスクの使用率が 100% に達している) ことが判明したら、アプリケーションで必要とされるだけの書き込みが実行できていないとみなし、より高速なディスクに交換するか、RAID (redundant array of independent disks) コンフィグレーションに変更します。
データベース サーバがボトルネックではないと判明したら、アプリケーション サーバのディスクがボトルネックになっていないかどうかを確認します。アプリケーション サーバのディスクがボトルネックになる原因としては以下が考えられます。
永続ストアの書き込み
トランザクション ロギング (tlog)
HTTP ロギング
サーバ ロギング
アプリケーション サーバでのディスク I/O を最適化する方法としては、より高速なディスクや RAID の使用、JMS の同時書き込みの無効化、tlog への JTA 直接書き込みの使用、HTTP ログ バッファの増設などがあります。
アプリケーションとアプリケーション サーバの間、およびアプリケーション サーバとデータベース サーバの間のデータ転送の量を確認します。このデータ量がネットワークの帯域幅を超えないようにします。帯域幅を超える場合、ネットワークがボトルネックとなります。「ndd コマンドを使用した TCP パラメータの設定」を参照してください。
ネットワークおよびデータベース サーバがボトルネックになっていないことが判明したら、オペレーティング システム、JVM、および WebLogic Server のコンフィグレーションを調べます。もっとも重要なのは、クライアントの負荷が高い状態で、WebLogic Server を実行するマシンの CPU 使用率が目標値に達するかどうかです。目標値に達しない場合は、アプリケーション内でロックが発生していないかどうかを確認します。ボトルネックを特定してアプリケーションのパフォーマンスを向上させるには、市販されているツール (JProbe、OptimizeIt など) を使用してアプリケーションをプロファイリングします。
ヒント : CPU 使用率が 100% に達している場合でも、アプリケーションをプロファイリングしてパフォーマンスを向上させることをお勧めします。 |
アプリケーションのプロファイリング ツールの詳細については、「パフォーマンス解析ツール」を参照してください。
この手順では、現在の環境をチューニングして、設定したパフォーマンス目標に対するボトルネックの影響を軽減します。この手順では、ボトルネックの影響を排除するのではなく、軽減するという点に注意してください。チューニングでは、リソースを調整して設定したパフォーマンス目標を達成できます。このマニュアルで説明する範囲は次のとおりです (重要性の高い項目からリストされています)。
『Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications』の著者の言葉によれば、「優れたアプリケーション パフォーマンスは、優れたアプリケーション設計によって実現されます。あまりにも複雑すぎたり、設計が不十分なアプリケーションでは、パフォーマンスを向上させるために最良慣行を実施したり、システムレベルのチューニングを行っても、低いパフォーマンスしか得られません」。つまり、設計が不十分なアプリケーションによって、無用なボトルネックが生み出される場合があります。たとえば、リソースの競合は、アプリケーション ドメインに起因するというよりは、設計が不十分なケースと考えられます。
詳細については、以下を参照してください。
データベースがエンタープライズ レベルのボトルネックになる可能性もあります。データベースの最適化は複雑となる場合があるため、ベンダに依存する場合があります。「データベースのチューニング」を参照してください。
WebLogic Server では、実際の環境やアプリケーションに合わせて細かくチューニングできるパフォーマンス関連の多数の OOTB (out-of-the-box) パラメータを使用しています。これらのパラメータをシステム要件に基づいてチューニングすることで、デフォルト設定のまま実行する場合に比べ、単一ノードのパフォーマンスおよびアプリケーションのスケーラビリティ特性を大きく向上させることができます。「WebLogic Server のチューニング」を参照してください。
Java 仮想マシン (JVM) は、マイクロプロセッサ上で Java クラス ファイルのバイト コードを実行する仮想の「実行エンジン」インスタンスです。「Java 仮想マシン (JVM) のチューニング」を参照してください。
設定されているデフォルトのチューニング パラメータは、オペレーティング システムによって異なります。Windows プラットフォームの場合、通常はデフォルト設定を変更する必要はありません。一方、UNIX および Linux オペレーティングシステムでは、通常は適切なチューニングを行う必要があります。「オペレーティング システムのチューニング」を参照してください。
パフォーマンス チューニングは反復操作です。システム上でボトルネックの影響を軽減したら、2 つ目の手順の「パフォーマンス メトリックの測定」に進み、パフォーマンス目標を満たしているかどうかを判断します。
この節では、システム パフォーマンス全体をチューニングする際のヒントおよびガイドラインを示します。
パフォーマンス チューニングは特効薬ではない。すなわち、優れたシステム パフォーマンスは、優れた設計、優れた実装、明確なパフォーマンス目標、およびパフォーマンス チューニングに基づきます。
パフォーマンス チューニングは継続的操作である。設定したパフォーマンス目標に対して比較可能なパフォーマンス メトリックを提供するメカニズムを実装します。これによって、システムに障害が発生する前にチューニング局面をスケジュールできます。
目的は、設定したパフォーマンス目標を満たすことであって、すべてのボトルネックを排除することではない。システム内のリソースは有限です。本質的に、少なくとも 1 つのリソース (CPU、メモリ、または I/O) がシステムのボトルネックになります。チューニングすることによって、設定したパフォーマンス目標に対するボトルネックの影響を軽減できます。
以下の点を考慮したパフォーマンスを発揮するアプリケーションを設計すること。
何事もシンプルに保つ - 公開されているパターンを不適切に使用しないでください。
Java EE のパフォーマンス パターンを適用する。
Java コードを最適化する。