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