WebLogic Server パフォーマンス チューニング ガイド
|
 |
 |
|
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
Java パラメータの値は、WebLogic Server を起動するたびに指定する必要があります。weblogic.Server コマンドを使用してコマンドラインから行うと、この作業を単純化できます。ただし、コマンドラインから WebLogic Server を起動するために必要な引数は長くなる場合があり、エラーが発生しやすくなるので、コマンドをスクリプトに組み込むことをお勧めします。このプロセスを単純化するため、WebLogic 配布キットに付属するサンプル スクリプトのデフォルト値を変更して WebLogic Server を起動することもできます。詳細については、「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
コンフィグレーション ウィザードを使用してドメインを作成した場合、WebLogic 起動スクリプトはそのドメインを指定した domain-name ディレクトリに格納されます。このディレクトリは、デフォルトでは BEA_HOME\user_projects\domain\domain-name となります。BEA_HOME は製品のインストール ディレクトリ、domain-name は選択したコンフィグレーション テンプレートで定義されているドメイン ディレクトリの名前です。コンフィグレーション ウィザードを使用したドメインの作成については、『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
それらのスクリプトのいくつかのデフォルト Java 値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
JAVA_HOME の値を JDK の位置に変更します。次に例を示します。"%JAVA_HOME%\bin\java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、「ヒープ サイズ値の指定」を参照してください。
ドメインを使用する環境として、開発環境またはプロダクション環境のどちらかを指定できます。WebLogic Server では、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。
表 5-2 に、開発起動モードとプロダクション起動モードで異なるパフォーマンス関連のコンフィグレーション パラメータを示します。
|
|
|
|
|
|
|
|
|
|
||
開発起動モードからプロダクション起動モードへの切り替えについては、Administration Console オンライン ヘルプの「プロダクション モードへの変更」を参照してください。
ベンチマークでは、WebLogic Server インスタンスのホスト マシンでネイティブ パフォーマンス パックを使用したときにパフォーマンスが大きく向上することが示されています。パフォーマンス パックでは、プラットフォーム用に最適化されたネイティブのソケット マルチプレクサを使用して、サーバのパフォーマンスを向上させています。たとえば、ネイティブ ソケット リーダー マルチプレクサ スレッドは独自の実行キューを持ち、デフォルトの実行キューからスレッドを借用することがありません。その分、自由になったデフォルトの実行スレッドをアプリケーションの処理に使用できることになります。
ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
現在パフォーマンス パックを使用できるプラットフォームを確認するには、次の手順に従います。
配布キットに用意されているコンフィグレーションでは、ネイティブ パフォーマンス パックの使用がデフォルトで有効になっています。Administration Console を使用して、パフォーマンス パックが有効になっていることを確認できます。
WebLogic Server は、作業を実行するスレッドを管理するための以下のメカニズムを備えています。
このリリースの WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメント (SLA) が維持されます。
サーバ インスタンスによるスレッドの利用方法をチューニングするには、ワーク マネージャを定義して、WebLogic Server ドメインにグローバルに適用するか、特定のプリケーション コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『WebLogic Server 環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
各 SLA 要件ごとにユニークなワーク マネージャが必要です。
サービス レベル アグリーメント (SLA) 要件は要求クラスのインスタンスで定義されます。要求クラスは、サーバ インスタンスがスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。『WebLogic Server 環境のコンフィグレーション』の「ワーク マネージャについて」を参照してください。
注意 : 実行キューは、このリリースの WebLogic Server で非推奨になりました。ワーク マネージャを使用するようにアプリケーションを移行することをお勧めします。
以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。「ユーザ定義の実行キューの使用」を参照してください。
以前のリリースの実行キューとワーク マネージャの相違点を概念的に理解する最も簡単な方法は、実行キュー (厳密に言えば、実行キュー マネージャ) をワーク マネージャと関連付けて、実行キューとスレッド プールの間の 1 対 1 の関係を切り離すことです。
WebLogic Server 9.0 より前のリリースでは、着信する要求はデフォルトの実行キューまたはユーザ定義の実行キューに入れられます。各実行キューには実行キュー マネージャが関連付けられています。実行キュー マネージャは、一定数のスレッドを持つ排他的な専用のスレッド プールを制御します。要求は先着順でキューに追加されます。実行キュー マネージャは、キューから最初の要求を取り出し、関連付けられたスレッド プールから使用可能なスレッドを 1 つ取得して、そのスレッドで実行するように要求をディスパッチします。
WebLogic Server 9.0 以降のリリースでは、優先順位に基づいた実行キューがサーバ内に 1 つ用意されます。着信する要求には、アプリケーションが実行する作業を管理するためにユーザが作成するワーク マネージャのコンフィグレーションに基づいて、内部的な優先順位が割り当てられます。サーバでは、さまざまなワーク マネージャの要求に応じて、実行キューで使用できるスレッドを増やしたり減らしたりします。実行キュー内の要求の位置は、その要求の内部的な優先順位によって決まります。
ワーク マネージャを使用すると、実行キューの場合より、スレッドの利用方法 (サーバのパフォーマンス) をうまく制御できます。その主な理由は、優先順位に基づいたスレッド プールに対してスケジューリング ガイドラインを指定するさまざまな方法が用意されていることです。スケジューリング ガイドラインは、数値として設定することも、サーバが管理するリソース (JDBC 接続プールなど) の容量として設定することもできます。
実行キューを含む以前のリリースからアプリケーション ドメインを移行すると、移行後の 9.1 ドメインにも実行キューが含まれています。
dispatch-policy で指定された実行キューに適切に割り当てます。dispatch-policy のない要求では、自動チューニング スレッド プールが使用されます。 ドメインの移行の詳細については、『WebLogic のアプリケーション環境のアップグレード』を参照してください。
WebLogic Server は、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。WebLogic Server がスレッドがスタックかどうかを判断するために使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になった場合に「warning」および「critical」状態を設定するデフォルト動作を変更することはできません。詳細については、『WebLogic Server 環境のコンフィグレーション』の「過負荷状態を回避するための WebLogic Server のコンフィグレーション」を参照してください。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。[バックログを受け入れ] パラメータは、待機キューに格納できる Transmission Control Protocol (TCP) 接続の数を指定します。この固定サイズのキューには、TCP スタックでは受信されたが、アプリケーションにはまだ受け入れられていない接続リクエストが格納されます。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。
JSP サーブレットをコンパイルするための標準 Java コンパイラは javac です。サーバの Java コンパイラを javac ではなく sj または jikes に設定することにより、パフォーマンスを大幅に向上させることができます。
サーバ インスタンスが Java コードをコンパイルするときに使用するコンパイラとコンパイラ オプションを変更できます。
サーバの標準 Java コンパイラの値を変更するには、次の手順に従います。
weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。
compileCommand パラメータでは、生成される JSP サーブレットをコンパイルするための Java コンパイラを指定します。precompile パラメータでは、WebLogic Server の起動時に WebLogic Server で JSP をあらかじめコンパイルするようコンフィグレーションします。サーバの Java コンパイラを weblogic.xml ファイルで設定する作業の詳細については、jsp-descriptor 要素を参照してください。
weblogic.appc ユーティリティを使用すると、EJB 2.0 および 1.1 のコンテナ クラスをコンパイルできます。EJB コンテナにデプロイするために Jar ファイルをコンパイルする場合は、weblogic.appc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac コンパイラを使用します。パフォーマンスを向上させるには、-compiler フラグを使用して別のコンパイラ (Symantec の sj など) を指定します。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean の実装」を参照してください。
UNIX マシン上で JSP ファイルをコンパイルしているときに次のエラー メッセージが表示された場合、
failed: java.io.IOException: Not enough space
set rlim_fd_max = 4096
set rlim_fd_cur = 1024
-native フラグを使用してネイティブ スレッドを使用する。
WebLogic Server クラスタは WebLogic Server インスタンスのグループで、互いに連携してフェイルオーバおよびレプリケーション サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバ群です。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。ドメイン内でクラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。インスタンスのすべてのコンフィグレーション パラメータは、そのインスタンスがクラスタ化されるかどうかにかかわらず、そのドメインの管理サーバによって管理されます。
クラスタの詳細については、「WebLogic Server のクラスタ化について」を参照してください。
スケーラビリティとは、リソースの追加に伴ってシステムが 1 つまたは複数の側面において拡張していく能力です。通常、これらの側面としては (他にも多数ありますが) サポート可能な同時接続ユーザの数や、一定時間に処理可能なトランザクションの数などが挙げられます。
優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Server の負荷処理の機能を強化するには、新しい WebLogic Server インスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバでは提供できない、スケーラビリティと可用性という 2 つの大きなメリットをもたらします。
WebLogic Server クラスタは、アプリケーション開発者からは見えないように、J2EE アプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一の WebLogic Server またはコンピュータの能力を超過することができます。クラスタ メンバシップの唯一の制限は、すべての WebLogic Server が IP マルチキャストで通信できなければならないということです。新しい WebLogic Server をクラスタに動的に追加して能力を増大させることもできます。
WebLogic Server クラスタは、複数サーバの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバで、同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。
警告 : すべてのアプリケーションおよび環境上のボトルネックが解決済みという条件下で初めて、新しいサーバへのクラスタの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期コンフィグレーション テストを実行するときには、単一サーバ環境における問題を洗い出した後で、クラスタ化環境に移行してください。
マルチプロセッサ マシンを使用する場合は、使用可能な CPU の数とクラスタ化された WebLogic Server インスタンスの数との比率も考慮する必要があります。WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、非常に大規模なクラスタまたは複数のクラスタのホストとなることができます。
CPU と WebLogic Server インスタンスの最適な比率を決定するには、まず、アプリケーションがネットワーク I/O またはディスク I/O ではなく完全に CPU にバインドされていることを確認する必要があります。以下の手順で、CPU とサーバ インスタンスの最適な比率を決定します。
|
|
|