| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
戻る |
次へ |
以下の節では、WebLogic Server をアプリケーションのニーズに合わせてチューニングする方法について説明します。
Java パラメータの値は、WebLogic Server を起動するたびに指定する必要があります。weblogic.Server コマンドを使用してコマンドラインから行うと、この作業を単純化できます。ただし、コマンドラインから WebLogic Server を起動するために必要な引数は長くなる場合があり、エラーが発生しやすくなるので、コマンドをスクリプトに組み込むことをお勧めします。このプロセスを単純化するため、WebLogic 配布キットに付属するサンプル スクリプトのデフォルト値を変更して WebLogic Server を起動することもできます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止の管理』の「WebLogic Server インスタンスの Java オプションの指定」を参照してください。
コンフィグレーション ウィザードを使用してドメインを作成した場合、WebLogic 起動スクリプトはそのドメインを指定した domain-name ディレクトリに格納されます。このディレクトリは、デフォルトでは MW_HOME\user_projects\domain\domain-name となります。MW_HOME は Oracle 製品をインストールしている Middleware ホーム ディレクトリ、domain-name は選択したコンフィグレーション テンプレートで定義されているドメイン ディレクトリの名前です。
それらのスクリプトのいくつかのデフォルト Java 値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス チューニング パラメータは、JAVA_HOME パラメータと Java ヒープ サイズ パラメータです。
変数 JAVA_HOME の値を JDK の位置に変更します。次に例を示します。
set JAVA_HOME=C:\Oracle\Middleware\jdk160_11
パフォーマンスとスループットをより高めるには、最小 Java ヒープ サイズを最大ヒープ サイズと同じ大きさに設定します。次に例を示します。
"%JAVA_HOME%\bin\java" -server –Xms512m –Xmx512m -classpath %CLASSPATH% -
ヒープ サイズ オプションの設定の詳細については、「ヒープ サイズ値の指定」を参照してください。
ドメインを使用する環境として、開発環境またはプロダクション環境のどちらかを指定できます。WebLogic Server では、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。
表 6-1 起動モード
| 選択するモード | 条件 |
|---|---|
|
開発 |
アプリケーションを作成する場合。このモードではセキュリティのコンフィグレーションがかなり緩和されるので、アプリケーションを自動デプロイできる。 |
|
プロダクション |
アプリケーションを最終的な形で実行する場合。このモードでは、セキュリティは完全にコンフィグレーションされる。 |
次の表に、開発起動モードとプロダクション起動モードで異なるパフォーマンス関連のコンフィグレーション パラメータを示します。
表 6-2 開発モードとプロダクション モードの相違点
| チューニング パラメータ | 開発モード | プロダクション モード |
|---|---|---|
|
SSL |
WebLogic Server セキュリティ サービスによって提供されるデモンストレーション デジタル証明書とデモンストレーション キーストアを使用できる。これらの証明書を使用すると、SSL で保護された環境内で動作するアプリケーションを設計できる。 セキュリティ管理の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照。 |
デモンストレーション デジタル証明書とデモンストレーション キーストアは使用すべきでない。使用すると、警告メッセージが表示される。 |
|
アプリケーションのデプロイ |
domain_name/autodeploy ディレクトリにあるアプリケーションを WebLogic Server インスタンスで自動的にデプロイおよび更新できる (domain_name はドメイン名)。 この方法は、単一サーバの開発環境でのみ使用することを推奨。 詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「開発ドメインへのアプリケーションの自動デプロイ」を参照。 |
自動デプロイメント機能は無効化されるため、WebLogic Server Administration Console、weblogic.Deployer ツール、または WebLogic Scripting Tool (WLST) を使用する必要がある。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「WebLogic Server デプロイメントについて」を参照。 |
開発起動モードからプロダクション起動モードへの切り替えについては、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「プロダクション モードへの変更」を参照してください。
以下の節では、デプロイメントのパフォーマンスを向上させる方法について説明します。
WebLogic Server は、起動時に多くの内部アプリケーションをデプロイします。これらの多くの内部アプリケーションはすべてのユーザが必要なわけではありません。これらのアプリケーションをサーバの起動時に常にデプロイするのではなく、最初のアクセス時に (必要なときに) 待機およびデプロイするよう WebLogic Server をコンフィグレーションできます。これにより、メモリやデプロイメント時の CPU 時間を節約できるだけでなく、WebLogic Server の起動時間を短縮し、基本メモリの占有量を減らすことが可能になります。開発ドメインの場合、デフォルトでは、内部アプリケーションが WLS によってオンデマンドでデプロイされます。プロダクション モード ドメインの場合、デフォルトでは、内部アプリケーションが WLS によってサーバ起動時にデプロイされます。この機能を使用およびコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「内部アプリケーションのオンデマンド デプロイメント」を参照してください。
デプロイメント モードでは、ClassLoader を再ロードせずにインプレースで Java クラスを再定義するよう WebLogic Server を設定できます。つまり、アプリケーションが再デプロイするまで待機した後に作業していた Web ページ フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。この機能を使用およびコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「FastSwap デプロイメントによる再デプロイメントの最小化」を参照してください。
汎用オーバーライドでは、アプリケーション固有のファイルをオプションの AppFileOverrides サブディレクトリにオーバーライドすることで、jar ファイルを展開せずにアプリケーション固有のプロパティ ファイルをオーバーライドできます。この機能を使用およびコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「汎用ファイル ロード オーバーライド」を参照してください。
WebLogic Server は、作業を実行するスレッドを管理するための以下のメカニズムを備えています。
このリリースの WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメント (SLA) が維持されます。
サーバ インスタンスによるスレッドの利用方法をチューニングするには、ワーク マネージャを定義して、WebLogic Server ドメインにグローバルに適用するか、特定のアプリケーション コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
各 SLA 要件ごとにユニークなワーク マネージャが必要です。
サービス レベル アグリーメント (SLA) 要件は要求クラスのインスタンスで定義されます。要求クラスは、サーバ インスタンスがスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャについて」を参照してください。
以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。「WebLogic 8.1 のスレッド プール モデルの使用」を参照してください。
|
注意 : ワーク マネージャを使用するようにアプリケーションを移行することをお勧めします。 |
以前のリリースの実行キューとワーク マネージャの相違点を概念的に理解する最も簡単な方法は、実行キュー (厳密に言えば、実行キュー マネージャ) をワーク マネージャと関連付けて、実行キューとスレッド プールの間の 1 対 1 の関係を切り離すことです。
WebLogic Server 9.0 より前のリリースでは、着信する要求はデフォルトの実行キューまたはユーザ定義の実行キューに入れられます。各実行キューには実行キュー マネージャが関連付けられています。実行キュー マネージャは、一定数のスレッドを持つ排他的な専用のスレッド プールを制御します。要求は先着順でキューに追加されます。実行キュー マネージャは、キューから最初の要求を取り出し、関連付けられたスレッド プールから使用可能なスレッドを 1 つ取得して、そのスレッドで実行するように要求をディスパッチします。
WebLogic Server 9.0 以降のリリースでは、優先順位に基づいた実行キューがサーバ内に 1 つ用意されます。着信する要求には、アプリケーションが実行する作業を管理するためにユーザが作成するワーク マネージャのコンフィグレーションに基づいて、内部的な優先順位が割り当てられます。サーバでは、さまざまなワーク マネージャの要求に応じて、実行キューで使用できるスレッドを増やしたり減らしたりします。実行キュー内の要求の位置は、その要求の内部的な優先順位によって決まります。
優先順位が高いほど、実行キューの先頭近くに置かれる。
キューの先頭に近いほど、使用するスレッドに早くディスパッチされる。
ワーク マネージャを使用すると、実行キューの場合より、スレッドの利用方法 (サーバのパフォーマンス) をうまく制御できます。その主な理由は、優先順位に基づいたスレッド プールに対してスケジューリング ガイドラインを指定するさまざまな方法が用意されていることです。スケジューリング ガイドラインは、数値として設定することも、サーバが管理するリソース (JDBC 接続プールなど) の容量として設定することもできます。
実行キューを含む以前のリリースからアプリケーション ドメインをアップグレードすると、移行後の 9.x ドメインにも実行キューが含まれています。
以前のリリースから WebLogic Server 9.x にアプリケーション ドメインを移行する場合、実行キューはワーク マネージャに自動的に変換されません。
アップグレードされたアプリケーション コンフィグレーションに実行キューが存在する場合、サーバ インスタンスは作業要求を dispatch-policy で指定された実行キューに適切に割り当てます。
dispatch-policy のない要求では、自動チューニング スレッド プールが使用されます。
『Oracle Fusion Middleware Oracle WebLogic Server アップグレード ガイド』の「アプリケーション環境のアップグレードのロードマップ」を参照してください。
WebLogic Server は、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。WebLogic Server がスレッドがスタックかどうかを判断するために使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になった場合に「warning」および「critical」状態を設定するデフォルト動作を変更することはできません。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「過負荷状態を回避するための WebLogic Server のコンフィグレーション」を参照してください。スタック スレッド検出動作をコンフィグレーションするには、Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「スタック スレッドの検出動作のチューニング」を参照してください。
以下の節では、クライアントとサーバの間のネットワーク通信 (T3 や IIOP プロトコル、およびそれらのセキュア バージョン) に関して説明します。
WebLogic Server は、マルチプレクサと呼ばれるソフトウェア モジュールを使用して、サーバでの受信要求とクライアントでの受信応答を読み込みます。これらのマルチプレクサには、主に Java マルチプレクサとネイティブ マルチプレクサの 2 種類があります。
Java マルチプレクサには次の特徴があります。
ソケットからのデータの読み込みに pure-Java が使用される。
RMI クライアントで利用可能な唯一のマルチプレクサ。
ソケットから読み込まれるデータが現れるまで読み込みはブロックされる。この動作は、ソケットが大量に存在する場合や、ソケットにデータが到達する頻度が低い場合は、あまり効率がよくありません。これは、クライアントでは通常問題になりませんが、サーバで大きなボトルネックになる場合があります。
一方、ネイティブ マルチプレクサは、プラットフォーム固有のネイティブ バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIX システムではポーリング システム呼び出しが使用され、Windows アーキテクチャでは完了ポートが使用されます。ネイティブ マルチプレクサでは、非ブロッキング スレッド モデルが実装されているため、優れたスケーラビリティが提供されます。ネイティブ マルチプレクサが使用されると、サーバでは受信要求の読み込み専用の固定数のスレッドが作成されます。Oracle では、[ネイティブ IO を有効化] パラメータが選択されているデフォルトの設定を使用することをお勧めします。この設定では、サーバは使用する適切なマルチプレクサを自動的に選択できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ネイティブ IO の有効化」を参照してください。
[ネイティブ IO を有効化] パラメータが選択されていない場合、サーバ インスタンスは Java マルチプレクサを排他的に使用します。これは、クライアントの数が少なく、サーバに届く要求のレートが非常に高いときに受諾できる場合があります。これらの条件下では、Java マルチプレクサはネイティブ マルチプレクサと同様のパフォーマンスを発揮し、Java ネイティブ インタフェース (JNI) のオーバーヘッドが解消されます。ネイティブ マルチプレクサと異なり、要求の読み込みに使用されるスレッドの数は固定されず、Java マルチプレクサでは、Administration Console の [ソケット リーダー] パラメータ設定をコンフィグレーションすることによってこの数を調整できます。「使用可能なソケット リーダーの数の変更」を参照してください。理想的には、スレッドの数がリモートの同時に接続されたクライアントの数とほぼ同じ (最高でも合計スレッド プール サイズの 50% まで) となるようにこのパラメータをコンフィグレーションする必要があります。各スレッドは、ソケットでデータが利用できるようになるまで一定の時間だけ待機します。到着するデータがない場合、スレッドは次のソケットに移動します。
ネイティブ マルチプレクサでは、以下の設定を使用すると、CPU にバインドされたアプリケーション (SpecJAppServer など) のスループットを向上できる場合があります。
-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx
xx は、データが使用可能かどうかをチェックする前に遅延する時間です (マイクロ秒単位)。デフォルト値は 0 で、遅延なしに相当します。
ベンチマークでは、WebLogic Server インスタンスのホスト マシンでネイティブ パフォーマンス パックを使用したときにパフォーマンスが大きく向上することが示されています。パフォーマンス パックでは、プラットフォーム用に最適化されたネイティブのソケット マルチプレクサを使用して、サーバのパフォーマンスを向上させています。たとえば、ネイティブ ソケット リーダー マルチプレクサ スレッドは独自の実行キューを持ち、デフォルトの実行キューからスレッドを借用することがありません。その分、自由になったデフォルトの実行スレッドをアプリケーションの処理に使用できることになります。
現在パフォーマンス パックを使用できるプラットフォームを確認するには、次の手順に従います。
サポート対象のコンフィグレーションに関するページ (http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html) に移動します。
動作確認されているプラットフォームのリストからご使用のプラットフォームを選択します。
ブラウザの [編集｜このページの検索] を使用して、「Performance Pack」という文字列をすべて検索し、そのプラットフォームに含まれているかどうかを調べます。
配布キットに用意されているコンフィグレーションでは、ネイティブ パフォーマンス パックの使用がデフォルトで有効になっています。Administration Console を使用して、パフォーマンス パックが有効になっていることを確認できます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「ネイティブ IO の有効化」を参照してください。
ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスおよびクライアント マシンごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「使用可能なソケット リーダーの数のチューニング」を参照してください。
ネットワーク チャネル (ネットワーク アクセス ポイントとも呼ばれる) では、ネットワーク通信のさまざまなサービス品質 (QOS) パラメータを指定できます。各ネットワーク チャネルは、ユニークな IP アドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド クライアントからの要求が同じリモート接続に対して多重化され、サーバ インスタンスがソケットからの要求を 1 つずつ読み込みます。要求のサイズが大きい場合、これがボトルネックになります。
ネットワーク チャネルの主な役割はサーバ インスタンスのネットワーク トラフィックを制御することですが、複数のカスタム チャネルを作成できる機能を利用すると、マルチスレッド クライアントが、複数の接続に対してサーバ インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム マルチチャネル通信をコンフィグレーションするには、以下の手順に従います。
異なる IP およびポート設定を使用して複数のネットワーク チャネルをコンフィグレーションします。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「カスタム ネットワーク チャネルのコンフィグレーション」を参照してください。
クライアントサイドのコードで、クラスタ環境で使用されるパターンに似た JNDI URL パターンを使用します。次に、2 つのネットワーク チャネルを使用したクライアントでの例を示します。
t3://<ip1>:<port1>,<ip2>:<port2>
『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ネットワーク チャネルについて」を参照してください。
WebLogic Server では、最大受信要求サイズを指定することによって、サーバが一連の大規模な要求によって攻撃されないようにし、サービス拒否 (DoS) 攻撃の危険性を軽減できます。さまざまなプロトコルおよびネットワーク チャネルに対して、グローバル値または特定の値を設定できます。パフォーマンスに直接影響することはありませんが、送り先に送信する前にメッセージを集約する JMS アプリケーションは、集約サイズが指定値を超える場合、拒否される場合があります。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバ : プロトコル : 全般」および「順序単位を使用したアプリケーションのチューニング」を参照してください。
チャンクは、クライアントサイドとサーバサイドの WebLogic Server ネットワーク レイヤが、データのソケットからの読み込みおよびソケットへの書き込みを行うために使用するメモリの単位です。メモリの割り当てコストを減らすために、サーバ インスタンスはこれらのチャンクのプールを保持します。要求に対して大量のデータを処理するアプリケーションでは、クライアントサイドとサーバサイドの両方でこの値を増やすことによって、パフォーマンスが向上する場合があります。デフォルトのチャンク サイズは約 4K です。チャンク サイズおよびチャンク プール サイズをチューニングするには、次のプロパティを使用します。
weblogic.Chunksize - チャンクのサイズ (バイト単位) を設定します。このプロパティを増やす必要がある第一の状況は、要求のサイズが大きい場合です。この値は、Ethernet または TCP のヘッダ サイズの値が差し引かれたネットワークの最大転送単位 (MTU) の倍数に設定する必要があります。このパラメータは、クライアントとサーバで同じ値に設定してください。
weblogic.utils.io.chunkpoolsize - チャンク プールの最大サイズを設定します。デフォルト値は 2048 です。この値は、サーバが定常状態でチャンクの割り当ておよび破棄を開始するとき、増やす必要がある場合があります。この値を増やす必要があるかどうかを判定するには、CPU プロファイルをモニタするか、コンストラクタ weblogic.utils.io.Chunk を呼び出すコール スタックのメモリまたはヒープ プロファイラを使用します。
weblogic.PartitionSize - 使用されるプール パーティションの数を設定します (デフォルトは 4)。チャンク プールは、プールにアクセスする各要求が同期する必要があるため、重大なロックの競合の原因になる可能性があります。スレッド プールを分割すると、複数のパーティションに対する競合の可能性が分散されます。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。[バックログを受け入れ] パラメータは、待機キューに格納できる Transmission Control Protocol (TCP) 接続の数を指定します。この固定サイズのキューには、TCP スタックでは受信されたが、アプリケーションにはまだ受け入れられていない接続要求が格納されます。TCP チューニングに関する詳細については、「OS チューニングの基本概念」を参照してください。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「接続バックログのバッファリングのチューニング」を参照してください。
サーバのコンパイラ オプションの調整により、パフォーマンスが向上する場合があります。
weblogic.appc ユーティリティを使って、EJB コンテナ クラスをコンパイルします。EJB コンテナにデプロイするために Jar ファイルをコンパイルする場合は、weblogic.appc を使用して、コンテナ クラスを生成する必要があります。ejbc は、デフォルトでは javac コンパイラを使用します。-compiler フラグや Administration Console を使用して IBM Jikes など別のコンパイラを指定することにより、パフォーマンスが向上する場合があります。詳細については、以下を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean の実装」
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「コンパイラ オプションのコンフィグレーション」
以下の節では、JSP コンパイラ オプションのチューニングに関する情報を示します。
weblogic.xml ファイルでは、jsp-descriptor 要素を使用してサーブレット JSP のパラメータの名前と値を定義します。precompile パラメータでは、WebLogic Server の起動時に WebLogic Server で JSP をあらかじめコンパイルするようコンフィグレーションします。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「jsp-descriptor」要素を参照してください。
UNIX マシン上で JSP ファイルをコンパイルしているときに次のエラー メッセージが表示された場合、
failed: java.io.IOException: Not enough space
以下のいずれかまたはすべての処理を試みます。
256MB しかない場合は RAM を増設する。
ファイル記述子の制限を上げる。設定例を示します。
set rlim_fd_max = 4096 set rlim_fd_cur = 1024
optimize-java-expression 要素を設定すると、Java 式を最適化して実行時パフォーマンスを向上させることができます。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「jsp-descriptor」を参照してください。
WebLogic Server クラスタは WebLogic Server インスタンスのグループで、互いに連携してフェイルオーバおよびレプリケーション サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバ群です。
ドメインには複数の WebLogic Server クラスタと、クラスタ化されない WebLogic Server インスタンスが存在できます。ドメイン内でクラスタ化される WebLogic Server インスタンスの動作は、フェイルオーバとロード バランシングの機能を備えること以外は、クラスタ化されないインスタンスと同様です。インスタンスのすべてのコンフィグレーション パラメータは、そのインスタンスがクラスタ化されるかどうかにかかわらず、そのドメインの管理サーバによって管理されます。
クラスタの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』の「WebLogic Server のクラスタ化について」を参照してください。
スケーラビリティとは、リソースの追加に伴ってシステムが 1 つまたは複数の側面において拡張していく能力です。通常、これらの側面としては (他にも多数ありますが) サポート可能な同時接続ユーザの数や、一定時間に処理可能なトランザクションの数などが挙げられます。
優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Server の負荷処理の機能を強化するには、新しい WebLogic Server インスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバでは提供できない、スケーラビリティと可用性という 2 つの大きなメリットをもたらします。
WebLogic Server クラスタは、アプリケーション開発者からは見えないように、Java EE アプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一の WebLogic Server またはコンピュータの能力を超過することができます。クラスタ メンバシップの唯一の制限は、すべての WebLogic Server が IP マルチキャストで通信できなければならないということです。新しい WebLogic Server をクラスタに動的に追加して能力を増大させることもできます。
WebLogic Server クラスタは、複数サーバの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバで、同じサービスを提供できます。1 つのサーバで障害が発生しても、別のサーバが引き継ぎます。障害が発生したサーバから機能しているサーバへのフェイルオーバ機能によって、クライアントに対するアプリケーションの可用性が増大します。
|
注意 : すべてのアプリケーションおよび環境上のボトルネックが解決済みという条件下で初めて、クラスタへの新しいサーバの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期コンフィグレーション テストを実行するときには、単一サーバ環境における問題を洗い出した後で、クラスタ化環境に移行してください。 |
メッセージング サービスでのクラスタ化は、分散送り先、接続のコンセントレータ、接続のロード バランシング (接続ファクトリの対象指定によって決定される)、およびクラスタ化ストア アンド フォワード (SAF) を介して提供されます。分散送り先に関するクライアントのロード バランシングは、接続ファクトリで調整できます。分散送り先をホストする同じクラスタに対象指定されている分散送り先のメッセージ駆動型 Bean (MDB) は、分散送り先のメンバーをホストするクラスタ サーバでのみ自動的にデプロイし、それらのローカル送り先からのメッセージのみ処理します。分散送り先のホストとは異なるサーバまたはクラスタに対象指定されている分散キュー MDB は、各分散送り先メンバーに対してコンシューマを自動的に作成します。たとえば、実行中の各 MDB は、各分散送り先キュー メンバーに対して 1 つのコンシューマを持ちます。
一般的に、クラスタ内のサーバ間で通信を必要とする処理は、スケーラビリティの潜在的な障害となります。以下の節では、クラスタ化 WebLogic サーバを直線的にスケーリングする際に影響のある問題について説明します。
WebLogic サーバのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとしては、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減することです。「データベースのチューニング」および「JDBC アプリケーションのチューニング」を参照してください。
ユーザ セッション データは、2 つの標準的な方法 (ステートフル セッション EJB または HTTP セッション) で、Java EE アプリケーションに格納できます。これらだけで、クラスタのスケーラビリティが影響されることはほとんどありません。ただし、高可用性を提供するために必要なセッション レプリケーション メカニズムと組み合わされると、ボトルネックが発生します。Java EE アプリケーションに Web および EJB コンポーネントがある場合、次の理由から、ユーザ セッション データは HTTP セッションに格納する必要があります。
HTTP セッション管理では、レプリケーション、共有 DB または共有ファイルなど、フェイルオーバを処理するためのオプションが多数提供される。
スケーラビリティが優れている。
HTTP セッション ステートのレプリケーションは、すべてのトランザクションの外部で発生する。一方、ステートフル セッション Bean のレプリケーションは、よりリソースが消費されるトランザクション内部で発生する。
HTTP セッションのレプリケーション メカニズムは高度に洗練され、ステートフル セッション Bean のレプリケーションよりも広範な状況で最適化を実現する。
「セッション管理」を参照してください。
HTTP セッションの非同期レプリケーションでは、以下を使用する非同期セッション レプリケーションを選択できます。
PersistentStoreType を async-replicated または async-replicated-if-clustered に設定して、プライマリ サーバとセカンダリ サーバ間でのデータの非同期レプリケーションを指定します。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThreshold パラメータを調整します。
レプリケーションの動作は、クラスタのタイプによって異なります。次の表では、特定のクラスタ トポロジでの非同期レプリケーションの動作について説明します。
表 6-3 クラスタ トポロジでの非同期レプリケーションの動作
| トポロジ | 動作 |
|---|---|
|
LAN |
同一クラスタ内のセカンダリ サーバへのレプリケーションは、Web アプリケーションで「async-replication」が設定されていると非同期的に発生する。 |
|
MAN |
リモートのクラスタのセカンダリ サーバにレプリケートされる。これは、Web アプリケーションで「async-replication」が設定されていると非同期的に発生する。 |
|
WAN |
クラスタ内のセカンダリ サーバへのレプリケーションは、Web アプリケーションで「async-replication」が設定されていると非同期的に発生する。リモートのクラスタを介するデータベースの永続性は、「async-replication」と「replication」のどちらが選択されていても非同期的に発生する。 |
以下に、非同期レプリケーション セッションの動作の概要を示します。
アンデプロイメント時または再デプロイメント時は、次のように動作する。
セッションが登録解除され、更新キューから削除される。
セカンダリ サーバ上のセッションが登録解除される。
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてセカンダリ サーバへレプリケートされる。セカンダリ サーバが停止している場合は、システムは別のサーバへのフェイルオーバを試みます。
セッション情報の消失の可能性を最小限に抑えるため、サーバが停止したり障害が発生したりするとバッチ処理されたセッションのレプリケーションが発生する。
PersistentStoreType を async-jdbc に設定して、データのデータベースへの非同期レプリケーションを指定します。『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThreshold パラメータおよび SessionFlushInterval パラメータを調整します。
以下に、非同期レプリケーション セッションの動作の概要を示します。
アンデプロイメント時または再デプロイメント時は、次のように動作する。
セッションが登録解除され、更新キューから削除される。
セッションがデータベースから削除される。
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてデータベースへレプリケートされる。
これは、読み書きパターン付き ReadOnly または Optimistic の同時方式を使用するエンティティ EJB に適用されます。
Optimistic - Optimistic 同時方式の Bean が更新されると、EJB コンテナはマルチキャスト メッセージを他のクラスタ メンバーに送信し、それらの Bean のローカル コピーを無効化します。これは、オプティミスティックな同時方式の例外が他のサーバによって送出されるのを防ぐ (それによってトランザクションを再試行する必要性を回避する) ために行われます。EJB に対する更新が頻繁に行われる場合、お互いのローカル キャッシュを無効化するためにサーバによって行われる処理が、重大なボトルネックになります。こうした無効化をオフにするには、cluster-invalidation-disabled と呼ばれるフラグ (デフォルトは false) を使用します。これは、rdbms 記述子ファイルで設定します。
読み書きパターン付き ReadOnly - このパターンでは、さもなければ単一 EJB によって表される永続データが、実際には次の 2 つの EJB によって表されます。読み込み専用 EJB と更新可能 EJB です。更新可能 Bean の状態が変更されると、コンテナは対応する読み込み専用 EJB インスタンスを自動的に無効化します。EJB に対する更新が頻繁に行われる場合、読み込み専用 EJB を無効化するためにサーバによって行われる処理が、重大なボトルネックになります。
「エンティティ EJB の無効化」と同様、HTTP セッションも無効化できます。これについては、無効化する必要があるのはセカンダリ サーバに格納されているセッション データのみなので、エンティティ EJB の無効化ほどコストがかかりません。断固として必要である場合を除き、セッションを無効化しないことをお勧めします。
一般的に、JNDI のバインド、アンバインド、およびリバインドは高価な処理です。ただし、これらの処理は、クラスタ環境では JNDI ツリーの変更をクラスタのすべてのメンバーに伝播する必要があるため、大きなボトルネックになります。こうした処理が頻繁に実行される場合、クラスタのスケーラビリティが大幅に縮小する場合があります。
マルチプロセッサ マシンを使用する場合は、使用可能な CPU の数とクラスタ化された WebLogic Server インスタンスの数との比率も考慮する必要があります。WebLogic Server には、クラスタ内のサーバ インスタンス数に関する制限はありません。したがって、Sun Microsystems の Sun Enterprise 10000 などの大規模マルチプロセッサ サーバは、非常に大規模なクラスタまたは複数のクラスタのホストとなることができます。
CPU と WebLogic Server インスタンスの最適な比率を決定するには、まず、アプリケーションがネットワーク I/O またはディスク I/O ではなく完全に CPU にバインドされていることを確認する必要があります。以下の手順で、CPU とサーバ インスタンスの最適な比率を決定できます。
アプリケーションをテストしてネットワークの要件を決定します。
アプリケーションが主にネットワーク I/O にバインドされている場合は、使用可能な CPU の数を増やす前にネットワーク スループットを高める方策を検討します。アプリケーションが完全にネットワーク I/O にバインドされている場合は、CPU を追加するより高速のネットワーク インタフェース カード (NIC) を取り付ける方がパフォーマンスは向上します。これは、ほとんどの CPU が、使用可能なソケットの読み込み待機中もアイドル状態のままになるためです。
アプリケーションをテストしてディスク I/O の要件を決定します。
アプリケーションが主にディスク I/O にバインドされている場合は、CPU を追加する前に、ディスク スピンドル数または個別のディスクとコントローラの数を増やすことを検討します。
まず、使用可能なすべての CPU に対して 1 つの WebLogic Server インスタンスの比率でパフォーマンスをテストします。
CPU 使用率がほぼ 100% を常に維持していれば、CPU を追加して、サーバ インスタンスに対する CPU の比率を高くします。使用率が許容できるレベルに達するまで CPU を追加していきます。プロダクション システムでは、管理タスクを実行できるように、利用可能な CPU サイクルを予備として常に確保しておきます。
以下の節では、WebLogic Server ドメインのモニタ方法を説明します。
現在の WebLogic Server ドメインの状態およびパフォーマンスをモニタするツールは、Administration Console です。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「サーバのモニタ」を参照してください。
WebLogic 診断フレームワーク (WLDF) とは、WebLogic Server のプロセス内で実行され標準的なサーバのライフサイクルに参加する、一連のサービスを定義および実装するモニタおよび診断フレームワークです。『Oracle Fusion Middleware Using the Diagnostic Framework Console Extension for Oracle WebLogic Server』の「WebLogic 診断フレームワーク コンソール拡張とは」を参照してください。
WebLogic Server には、WebLogic Server リソースをコンフィグレーション、モニタ、および管理するためのさまざまな独自の MBean が用意されています。『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」を参照してください。
WebLogic Scripting Tool (WLST) は、システム管理者やオペレータが、WebLogic Server インスタンスおよびドメインのモニタと管理に使用する、コマンドライン スクリプト インタフェースです。『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」を参照してください。
Oracle Technology Network (http://www.oracle.com/technology/index.html) では、製品のダウンロード、記事、サンプル コード、製品マニュアル、チュートリアル、ホワイト ペーパー、ニュース グループ、および WebLogic Server のその他の主要なコンテンツを提供しています。
Oracle は、製品のモニタ ツールおよび管理ツールを提供する他の企業と提携しています。「プロダクションのパフォーマンス管理」を参照してください。
WebLogic Server におけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステムの classpath 全体が検索されます。一度だけルックアップされるクラスやリソース (デプロイメント時のクラスロードなど) の場合は、classpath 全体の検索にかかる負荷が重大な問題となることは通常はありません。実行時にアプリケーションによって繰り返し要求されるクラスやリソース (loadClass または getResource の明示的な呼び出し) の場合は、システムやアプリケーションの長い classpath が繰り返し検索されることで CPU やメモリのオーバーヘッドが増大する可能性があります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。クラスまたはリソースが見つからない場合は classpath 全体がスキャンされることになり、負荷は高くなります。また、アプリケーションがクラス/リソースの検索に失敗すると要求が繰り返される可能性があるため、状況はさらに悪化します。この問題は、クラスの場合よりもリソースの場合に多く発生します。
見つからないクラスまたはリソースの要求および同じクラス/リソースをロードするために頻繁に繰り返される呼び出しは回避されるよう、アプリケーション コードが最適化されているのが理想です。サードパーティのライブラリなど、アプリケーション コードの修正が可能でない場合は、WebLogic Server の「フィルタリング ローダ メカニズム」を使用します。
WebLogic Server には、アプリケーションの classpath 上にある特定のアプリケーション クラスおよびアプリケーション リソースを検索する場合に、システムの classpath の検索を回避できるフィルタリング ローダ メカニズムが用意されています。このメカニズムを使用するには、システムの classpath の検索を回避するクラスおよびリソースをユーザが指定する必要があります。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「フィルタリング クラスローダの使用」を参照してください。
このリリースでは、リソースのロード要求をフィルタリングできる機能が追加されました。リソースのフィルタリングの基本的なコンフィグレーションは、META-INF/weblogic-application.xml ファイルで指定します。クラスのフィルタリングの場合も同様です。リソースをフィルタリングする構文の例を以下に示します。
<prefer-application-resources> <resource-name>x/y</resource-name> <resource-name>z*</resource-name> </prefer-application-resources>
この例では、「x/y」という名前のリソースと「z」で名前が始まるリソースにリソースのフィルタリングがコンフィグレーションされています。使用できるワイルド カードは「*」のみです。これらのパターンに一致する名前を持つリソースはアプリケーションの classpath 上でのみ検索され、システムの classpath の検索はスキップされます。
|
注意 : フィルタリングのコンフィグレーションにクラスまたはリソースを追加した後で、クラスまたはリソースが見つからないことを示す例外が発生した場合は、クラスまたはリソースがアプリケーションのclasspath 上ではなくシステムの classpath 上に存在している可能性があります。 |
