| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
前 |
次 |
この章では、アプリケーションのニーズに合せてWebLogic Serverをチューニングする方法について説明します。
WebLogic Serverを起動するたびに、Javaパラメータを指定する必要があります。簡単な呼出しとしては、コマンド・ラインにweblogic.Serverコマンドを実行して呼出しを行うことができます。ただし、コマンド・ラインからWebLogic Serverを起動するために必要な引数は長くて、間違いやすいため、コマンドをスクリプトに組み込むことをお薦めします。この処理を簡単化するには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic ServerインスタンスのJavaオプションの指定に関する項に記載されているように、WebLogic配布によって提供されたサンプル・スクリプトのデフォルト値を変更して、WebLogic Serverを起動します。
構成ウィザードを使用してドメインを作成した場合、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では、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。
表7-1 起動モード
| 選択するモード | 条件 |
|---|---|
|
開発 |
アプリケーションを作成する場合。このモードではセキュリティの構成がかなり緩和されるので、アプリケーションを自動デプロイできます。 |
|
本番 |
アプリケーションを最終的な形で実行する場合。このモードでは、セキュリティは完全に構成されます。 |
次の表に、開発起動モードと本番起動モードで異なるパフォーマンス関連の構成パラメータを示します。
表7-2 開発モードと本番モードの相違点
| チューニング・パラメータ | 開発モード | 本番モード |
|---|---|---|
|
SSL |
WebLogic Serverセキュリティ・サービスによって提供されるデモンストレーション・デジタル証明書とデモンストレーション・キーストアを使用できます。これらの証明書を使用すると、SSLで保護された環境で動作するアプリケーションを設計できます。 セキュリティ管理の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。 |
デモンストレーション・デジタル証明書とデモンストレーション・キーストアは使用しないでください。使用すると、警告メッセージが表示されます。 |
|
アプリケーションのデプロイ |
domain_name/autodeployディレクトリにあるアプリケーションをWebLogic Serverインスタンスで自動的にデプロイおよび更新できます(domain_nameはドメイン名)。 この方法は、単一サーバーの開発環境でのみ使用することを推奨します。 詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の開発ドメインでのアプリケーションの自動デプロイに関する項を参照してください。 |
自動デプロイメントの機能は無効化されているので、WebLogic Server管理コンソール、weblogic.DeployerツールまたはWebLogic Scripting Tool (WLST)を使用する必要があります。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverのデプロイメントに関する項を参照してください。 |
起動モードの開発モードから本番モードへの切替えについては、Oracle WebLogic Server管理コンソール・ヘルプの本番モードへの切替えに関する項を参照してください。
次の項では、デプロイメントのパフォーマンスを向上させる方法について説明します。
WebLogic Serverでは、起動時に、多くの内部アプリケーションがデプロイされます。この内部アプリケーションの多くは、すべてのユーザーに必要なわけではありません。これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要に応じて)待機およびデプロイするようにWebLogic Serverを構成できます。これにより、デプロイメント時のメモリーとCPU時間が節約されるとともに、サーバーの起動時間が向上しメモリー占有量が少なくなります。
WebLogic Serverでは、起動時に、多くの内部アプリケーションがデプロイされます。この内部アプリケーションの多くは、すべてのユーザーに必要なわけではありません。これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要に応じて)待機およびデプロイするようにWebLogic Serverを構成できます。これにより、デプロイメント時のメモリーとCPU時間を節約できるだけでなく、サーバーの起動時間を短縮し、基本メモリーのフットプリントを減らすことが可能になります。開発ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってオンデマンドでデプロイされます。本番モード・ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってサーバー起動時にデプロイされます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』の「内部アプリケーションのオンデマンド・デプロイメント」を参照してください。
デプロイメント・モードでは、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するようWebLogic Serverを設定できます。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。
汎用オーバーライドでは、アプリケーション固有のファイルをオプションのAppFileOverridesサブディレクトリにオーバーライドすることで、jarファイルを展開せずにアプリケーション固有のプロパティ・ファイルをオーバーライドできます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』の「汎用ファイル・ロード・オーバーライド」を参照してください。
WebLogic Serverは、作業を実行するスレッドを管理するための次のメカニズムを備えています。
このリリースのWebLogic Serverでは、アプリケーションがどのような優先度で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメント(SLA)が維持されます。
サーバー・インスタンスによるスレッドの利用方法をチューニングするには、ワーク・マネージャを定義して、WebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。
『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。
各SLA要件ごとに一意のワーク・マネージャが必要です。
サービス・レベル合意の(SLA)の要件は、リクエスト・クラスのインスタンスによって定義されます。リクエスト・クラスは、サーバー・インスタンスによってスレッドの割当てのために使用されるスケジューリング・ガイドラインを表します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャに関する項を参照してください。
以前のバージョンのWebLogic Serverでは、複数の実行キューで処理を実行していました。優先度や順序の要件に基づいて、クラスの異なる作業を別々のキューで実行することで、デッドロックを回避していました。付録A「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 WebLogic Serverアップグレード・ガイド』のアプリケーション環境をアップグレードするためのロードマップに関する項を参照してください。
WebLogic Serverは、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック・スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバーはスタック・スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Serverは、一定の時間にわたって継続して動作している(アイドル状態ではない)スレッドをスタックしていると診断します。スレッドがスタック・スレッドと診断されるまでの時間を変更すること、および、サーバーがスタック・スレッドを確認する頻度を変更することで、サーバーのスレッド検出動作をチューニングできます。スレッドがスタックされているかどうかを判断するためにWebLogic Serverが使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になったときに「警告」および「クリティカル」のヘルス状態を設定するデフォルトの動作は変更できません。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のオーバーロード条件を避けるようにWebLogic Serverの構成に関する項を参照してください。スタック・スレッド検出動作を構成するには、Oracle WebLogic Server管理コンソール・ヘルプの実行スレッド検出動作のチューニングに関する項を参照してください。
次の項では、クライアントとサーバーの間のネットワーク通信(T3やIIOPプロトコル、およびそれらのセキュア・バージョン)に関して説明します。
WebLogic Serverは、マキサーと呼ばれるソフトウェア・モジュールを使用して、サーバーでの受信リクエストとクライアントでの受信レスポンスを読み込みます。WebLogic Serverでは次のマキサーがサポートされます。
WebLogic Serverでは、次の基準を使用してマキサーの実装を選択します。
Muxer Class属性がweblogic.socket.NIOSocketMuxerに設定されているか、-Dweblogic.MuxerClass=weblogic.socket.NIOSocketMuxerフラグが設定されている場合、NIOSocketMuxerが使用されます。
NativeIOEnabledがfalseで、MuxerClassがnullの場合、Javaソケット・マキサーが使用されます。
NativeIOEnabledがtrueでMuxerClassがnullの場合、ネイティブ・マキサーがプラットフォームで使用可能であれば、それが使用されます。
クライアント・アプリケーションでは、Javaソケット・マキサーが使用されます。
Javaマキサーには次の特徴があります。
ソケットからのデータの読込みにpure-Javaが使用されます。
RMIクライアントで利用可能な唯一のマキサー。
ソケットから読み込まれるデータが現れるまで読込みはブロックされます。この動作は、ソケットが大量に存在する場合や、ソケットにデータが到達する頻度が低い場合は、あまり効率がよくありません。これは、クライアントでは通常問題になりませんが、サーバーで大きなボトルネックになる場合があります。
「ネイティブIOを有効化」パラメータが選択されていない場合、サーバー・インスタンスはJavaマキサーを排他的に使用します。これは、クライアントの数が少なく、サーバーに届くリクエストのレートが非常に高いときに受諾できる場合があります。これらの条件下では、Javaマキサーはネイティブ・マキサーと同様のパフォーマンスを発揮し、Javaネイティブ・インタフェース(JNI)のオーバーヘッドが解消されます。ネイティブ・マキサーと異なり、リクエストの読込みに使用されるスレッドの数は固定されず、Javaマキサーでは、管理コンソールの「ソケット・リーダー」パラメータ設定を構成することによってこの数を調整できます。「使用可能なソケット・リーダーの数の変更」を参照してください。理想的には、スレッドの数がリモートの同時に接続されたクライアントの数とほぼ同じ(最高でも合計スレッド・プール・サイズの50%まで)となるようにこのパラメータを構成する必要があります。各スレッドは、ソケットでデータが利用できるようになるまで一定の時間だけ待機します。到着するデータがない場合、スレッドは次のソケットに移動します。
一方、ネイティブ・マキサーは、プラットフォーム固有のネイティブ・バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIXシステムではポーリング・システム呼出しが使用され、Windowsアーキテクチャでは完了ポートが使用されます。ネイティブ・マキサーでは、非ブロッキング・スレッド・モデルが実装されているため、優れたスケーラビリティが提供されます。ネイティブ・マキサーが使用されると、サーバーでは受信リクエストの読取り専用の固定数のスレッドが作成されます。Oracleでは、「ネイティブIOを有効化」パラメータが選択されているデフォルトの設定を使用することをお薦めします。この設定では、サーバーは使用する適切なマキサーを自動的に選択できます。Oracle WebLogic Server管理コンソール・ヘルプのネイティブIOの有効化に関する項を参照してください。
ネイティブ・マキサーでは、次の設定を使用すると、CPUにバインドされたアプリケーション(SpecJAppServerなど)のスループットを向上できる場合があります。
-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx
xxは、データが使用可能かどうかをチェックする前に遅延する時間です(マイクロ秒単位)。デフォルト値は0で、遅延なしに相当します。
WebLogic Serverでは、一部のアプリケーションのパフォーマンスを拡張する、非ブロッキングIO実装が提供されています。Oracle WebLogic Server管理コンソール・ヘルプのNIOSocketMuxerの有効化に関する項を参照してください。
ベンチマークでは、WebLogic Serverインスタンスのホスト・マシンでネイティブ・パフォーマンス・パックを使用したときにパフォーマンスが大きく向上することが示されています。パフォーマンス・パックでは、プラットフォーム用に最適化されたネイティブのソケット・マルチプレクサを使用して、サーバーのパフォーマンスを向上させています。たとえば、ネイティブ・ソケット・リーダー・マルチプレクサ・スレッドは独自の実行キューを持ち、デフォルトの実行キューからスレッドを借用することがありません。その分、自由になったデフォルトの実行スレッドをアプリケーションの処理に使用できることになります。
現在パフォーマンス・パックを使用できるプラットフォームを確認するには:
最新の動作確認ページへのリンクは、『Oracle WebLogic Serverの新機能』のサポートされる構成に関する項を参照してください。
動作確認されているプラットフォームのリストからご使用のプラットフォームを選択します。
ブラウザの「編集」>「このページの検索」を使用して、「Performance Pack」という文字列をすべて検索し、そのプラットフォームに含まれているかどうかを調べます。
配布キットとともに出荷されている構成では、NATIVEパフォーマンス・パックの使用は、デフォルトで有効化されています。管理コンソールを使用して、パフォーマンス・パックが有効化されていることを確認できます。Oracle WebLogic Server管理コンソール・ヘルプのネイティブIOの有効化に関する項を参照してください。
ホスト・マシンにpure-Javaソケット・リーダーを実装する必要がある場合、各サーバー・インスタンスとクライアント・マシンに対して適切なソケット・リーダースレッド数を構成することで、ソケット通信のパフォーマンスを向上できます。Oracle WebLogic Server管理コンソール・ヘルプの利用可能なソケット・リーダー数のチューニングに関する項を参照してください。
ネットワーク・チャネル(ネットワーク・アクセス・ポイントとも呼ばれる)では、ネットワーク通信の様々なサービス品質(QOS)パラメータを指定できます。各ネットワーク・チャネルは、固有IPアドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド・クライアントからのリクエストが同じリモート接続に対して多重化され、サーバー・インスタンスがソケットからのリクエストを1つずつ読み込みます。リクエストのサイズが大きい場合、これがボトルネックになります。
ネットワーク・チャネルの主な役割はサーバー・インスタンスのネットワーク・トラフィックを制御することですが、複数のカスタム・チャネルを作成できる機能を利用すると、マルチスレッド・クライアントが、複数の接続に対してサーバー・インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム・マルチチャネル通信を構成するには、次の手順に従います。
様々なIPおよびポート設定を使用して複数のネットワーク・チャネルを構成します。Oracle WebLogic Server管理コンソール・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。
クライアント側のコードで、クラスタ環境で使用されるパターンに似たJNDI URLパターンを使用します。次に、2つのネットワーク・チャネルを使用したクライアントでの例を示します。
t3://<ip1>:<port1>,<ip2>:<port2>
『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・チャネルの理解に関する項を参照してください。
WebLogic Serverでは、システムの可用性を最適化すると同時にサービス妨害(DoS)攻撃の可能性を低減するために次の設定を指定することができます。
受信メッセージの最大サイズ
完了メッセージ・タイムアウト
ファイル記述子数(UNIXシステム)
システムのパフォーマンスを最大限にするために、次の項に記載されているように、WebLogic Serverをホストする特定のシステムでこれらの設定が適切で、お互いにバランスが取れてる必要があります。
WebLogic Serverを使用すると、一連の大きなリクエストが攻撃に遭わないように受信リクエスト最大のサイズを指定できます。別々のプロトコルとネットワーク・チャネルに対してグローバルの値または特定の値を設定できます。パフォーマンスには直接的に影響しませんが、宛先へ送信する前にJMSアプリケーションに収集されたメッセージのサイズが指定した値より大きい場合、そのJMSアプリケーションは拒否される場合があります。Oracle WebLogic Server管理コンソール・ヘルプのサーバー: プロトコル」: 一般に関する項、および順序単位を使用したアプリケーションのチューニングを参照してください。
「完了メッセージ・タイムアウト」パラメータがシステムで正しく構成されていることを確認します。このパラメータを使用すると、サーバーが完了メッセージを受信するまでに待機する最大秒数を設定できます。
デフォルト値は60秒で、デフォルト・ネットワーク・チャネルのすべての接続プロトコルに適用されます。サーバーに待機時間の長いクライアントが多くある場合、この設定が適切である場合があります。ただし、システムの可用性を侵害することなく、この設定を可能なかぎり小さな値にする必要があります。
特定のプロトコルのために完了メッセージ・タイムアウトを指定する必要がある場合、かわりに、そのプロトコルに対して新しいネットワーク・チャネルを構成できます。
完了メッセージ・タイムアウト・パラメータを指定できる「管理コンソール」ページの表示の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのプロトコルの構成を参照してください。
UNIXシステムでは、WebLogic Serverへの各ソケット接続がファイル記述子を消費します。可用性を最適化するには、ホスト・マシン上のWebLogic Serverのファイル記述子数が適切である必要があります。デフォルトでは、WebLogic Serverには、1024個ファイル記述子数が構成されています。ただし、特に本番システムでは、この値は小さく設定される場合があります。
WebLogic Serverのファイル記述子数をチューニングする場合、ファイル記述子に行った変更は「完了メッセージ・タイムアウト」パラメータに行った変更とバランスが取れている必要があります。「完了メッセージ・タイムアウト」パラメータの値が大きい場合、メッセージ・タイムアウトが発生するまでソケットが閉じられません。これにより、ファイル記述子の保留時間が長くなります。したがって、「完了メッセージ・タイムアウト」パラメータの値が大きい場合、ファイル記述子数の制限も大きく設定する必要があります。これにより、システムの可用性が最適化され、サービス妨害攻撃の可能性を低減できます。
使用可能なファイル記述子数のチューニング方法については、UNIXベンダーのドキュメントを参照してください。
チャンクは、クライアント側とサーバー側の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チューニングの詳細は、「オペレーティング・システムのチューニング」を参照してください。
WebLogic Serverのインスタンスにより追加のリクエストを否定する前に受け取る接続リクエスト数をチューニングできます。Oracle WebLogic Server管理コンソール・ヘルプの接続バックログ・バッファのチューニングに関する項を参照してください。
HTTP 1.1プロトコルでキープ・アライブが有効な場合に、キャッシュからソケット接続を返す動作のチューニング用のhttp.keepAliveCache.socketHealthCheckTimeoutシステム・プロパティを使用します。デフォルトでは、キャッシュされた接続がクライアントに返され使用できるようになるまで、キャッシュはヘルス状態をチェックしません。ネットワーク接続が不安定な場合などの一定の条件では、クライアントに返す前にシステムが接続ヘルス状態をチェックする必要があります。この動作(ヘルス状態のチェック)を有効にするには、http.keepAliveCache.socketHealthCheckTimeoutを0より大きい値に設定します。
サーバーのコンパイラ・オプションの調整により、パフォーマンスが向上する場合があります。
weblogic.appcユーティリティを使って、EJBコンテナ・クラスをコンパイルします。EJBコンテナにデプロイメントするためにJarファイルをコンパイルする場合は、weblogic.appcを使用して、コンテナ・クラスを生成する必要があります。ejbcは、デフォルトではjavacコンパイラを使用します。-compilerフラグを使用してIBM Jikesなど別のコンパイラを指定することにより、パフォーマンスが向上する場合があります。詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のEnterprise Java Beansの実装に関する項を参照してください。
次の項では、JSPコンパイラ・オプションのチューニングに関する情報を示します。
weblogic.xmlファイルでは、jsp-descriptorの要素は、サーブレットJSPのパラメータ名および値を定義します。precompileパラメータを使用して、WebLogic Serverの起動時にJSPをプリコンパイルできます。『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 WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「jsp-descriptor」を参照してください。
WebLogic ServerクラスタはWebLogic Serverインスタンスのグループで、互いに連携してフェイルオーバーおよびレプリケーション・サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバーに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバー群です。
ドメインには複数のWebLogic Serverクラスタと、クラスタリングされないWebLogic Serverインスタンスが存在できます。ドメイン内でクラスタリングされるWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタリングされないインスタンスと同様です。インスタンスのすべての構成パラメータは、そのインスタンスがクラスタリングされるかどうかにかかわらず、そのドメインの管理サーバーによって管理されます。
クラスタの詳細は、『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サーバーのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとして、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減します。第9章「データベースのチューニング」および第12章「データ・ソースのチューニング」を参照してください。
ユーザー・セッション・データは、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 WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータを調整します。
レプリケーションの動作は、クラスタのタイプによって異なります。次の表では、特定のクラスタ・トポロジでの非同期レプリケーションの動作について説明します。
表7-3 クラスタ・トポロジでの非同期レプリケーションの動作
| トポロジ | 動作 |
|---|---|
|
LAN |
同一クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
|
MAN |
リモートのクラスタのセカンダリ・サーバーにレプリケートされます。これは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。 |
|
WAN |
クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。リモートのクラスタを介するデータベースの永続性は、「async-replication」と「replication」のどちらが選択されていても非同期的に発生します。 |
次に、非同期レプリケーション・セッションの動作の概要を示します。
アンデプロイメント時または再デプロイメント時は、次のように動作します。
セッションが登録解除され、更新キューから削除されます。
セカンダリ・サーバー上のセッションが登録解除されます。
アプリケーションが管理モードに移行している場合、セッションはフラッシュされてセカンダリ・サーバーへレプリケートされます。セカンダリ・サーバーが停止している場合は、システムは別のサーバーへのフェイルオーバーを試みます。
セッション情報の消失の可能性を最小限に抑えるため、サーバーが停止したり障害が発生したりするとバッチ処理されたセッションのレプリケーションが発生します。
PersistentStoreTypeをasync-jdbcに設定して、データのデータベースへの非同期レプリケーションを指定します。『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(読取り専用と更新可能)で表現されます。更新可能Beanの状態が変更されると、コンテナは対応する読取り専用EJBインスタンスを自動的に無効化します。EJBに対する更新が頻繁に行われる場合、読取り専用EJBを無効化するためにサーバーによって行われる処理が、重大なボトル・ネックになります。
「エンティティEJBの無効化」と同様、HTTPセッションも無効化できます。これについては、無効化する必要があるのはセカンダリ・サーバーに格納されているセッション・データのみなので、エンティティEJBの無効化ほどコストがかかりません。絶対に必要な場合を除き、セッションを無効化しないことをお薦めします。
一般的に、JNDIのバインド、アンバインド、およびリバインドは高価な処理です。ただし、これらの処理は、クラスタ環境ではJNDIツリーの変更をクラスタのすべてのメンバーに伝播する必要があるため、大きなボトルネックになります。こうした処理が頻繁に実行される場合、クラスタのスケーラビリティが大幅に縮小する場合があります。
マルチ・コア・マシンについては、クラスタリングされたWebLogic Serverインスタンスと使用可能なコア数の比率を考慮する必要があります。WebLogic Serverには、クラスタ内のサーバー・インスタンス数の制限が組み込まれていないため、大規模なマルチ・コア・サーバーでは、非常に大規模なクラスタまたは多くのクラスタをホストする可能性があります。
WebLogic serverインスタンスに対するコアの最適な比率を決定するときに次の事項を考慮してください。
アプリケーションのメモリー要件。個別インスタンスのヒープ・サイズとインスタンスの総合数を選択して、アプリケーションに十分なメモリーが提供されていて、よいガベージ・コレクション(GC)パフォーマンスが達成できることを確認します。いくつかのアプリケーションでは、単一のインスタンスに非常に大きなヒープ・サイズを割り当てると、ガベージ・コレクション(GC)の休止時間が長くなる場合があります。この場合は、インスタンス数を増加し、各インスタンスに小さいヒープを割り当てると、パフォーマンスが向上する場合があります。
CPUの最大使用。WebLogic Serverでは、インスタンスごとに複数のコアを使用できるので、いくつかのアプリケーションにおいて指定したマシン上のインスタンス数を増加(インスタンスごとにコア数の減少)すると、CPUの使用とパフォーマンスを向上できます。
次の項では、WebLogic Serverドメインのモニター方法を説明します。
管理コンソールは、WebLogic Serverドメインのヘルス状態とパフォーマンスをモニターするツールです。Oracle WebLogic Server管理コンソール・ヘルプのサーバーの監視に関する項を参照してください。
WebLogic診断フレームワーク(WLDF)は、監視および診断フレームワークであり、WebLogic Serverのプロセス内で実行する一連のサービスの定義および実装を行い、標準サーバー・ライフ・サイクルに参加します。『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDFアーキテクチャの概要に関する項を参照してください。
WebLogic Serverでは、独自の一連のMBeansが提供されています。これらを使用して、WebLogic Serverリソースを構成、モニターおよび管理することができます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeansの理解に関する項を参照してください。
WebLogic Scripting Tool (WLST)はコマンドライン・スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeansの理解に関する項を参照してください。
Oracle Technology Network (http://www.oracle.com/technology/index.html)では、製品のダウンロード、記事、サンプル・コード、製品ドキュメント、チュートリアル、ホワイト・ペーパー、ニュース・グループ、およびWebLogic Serverのその他の主要なコンテンツを提供しています。
オラクル社は、製品の監視および管理ツールを提供する他の会社と提携しています。
WebLogic Serverにおけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダーの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステム・クラスパス全体が検索されます。一度だけルックアップされるクラスやリソース(デプロイメント時のクラスロードなど)の場合は、classpath全体の検索にかかる負荷が重大な問題となることは通常はありません。実行時にアプリケーションによって繰返し要求されるクラスやリソース(loadClassまたはgetResourceの明示的な呼出し)の場合は、システムやアプリケーションの長いclasspathが繰り返し検索されることでCPUやメモリーのオーバーヘッドが増大する可能性があります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。クラスまたはリソースが見つからない場合はclasspathの全体スキャンの負荷が発生し、アプリケーションがクラス/リソースの検索に失敗するとリクエストが繰り返される可能性があるため、さらに負荷が高まります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。
見つからないクラスまたはリソースのリクエストおよび同じクラス/リソースをロードするために頻繁に繰り返される呼出しは回避されるよう、アプリケーション・コードが最適化されているのが理想です。サード・パーティのライブラリなど、アプリケーション・コードの修正が可能でない場合は、WebLogic Serverの「フィルタリング・ローダー・メカニズム」を使用します。
WebLogic Serverでは、フィルタリング・ローダー・メカニズムが用意されており、これによって、アプリケーション・クラスパスにある特定のアプリケーション・クラスとリソースを検索するときにシステム・クラスパスの検索を省略できます。このメカニズムでは、ユーザーはシステム・クラスパスの検索を省略する特定のクラスとリソースを指定する必要があります。『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」で名前が始まるリソースにリソース・フィルタリングが構成されています。使用できるワイルド・カードのパターンは「*」のみです。これらのパターンに一致する名前を持つリソースはアプリケーション・クラスパス上でのみ検索され、システム・クラスパスの検索はスキップされます。
|
注意: フィルタリング構成にクラスまたはリソースを追加した後で、クラスまたはリソースが見つからないことを示す例外が発生した場合は、クラスまたはリソースがアプリケーション・ |
WebLogic Serverは、起動を高速化するためにクラス・キャッシングを有効にできます。キャッシングを有効にすると、サーバーは特定の基準に達するまでロードされるすべてのクラスを記録し、クラス定義を非表示のファイルに保持します。サーバーを再起動すると、キャッシュの有効性が既存のコード・ソースによりチェックされます。そして、サーバーは実行回数に記録されたクラスと同じ一連のクラスをバルク・ロードするためキャッシュ・ファイルを使用します。システム・クラスパスまたはその内容を変更すると、キャッシュは無効になり、サーバー再起動時に再作成されます。
クラス・キャッシングを使用する利点は次のとおりです。
サーバーの起動時間が短縮されます。
パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。
詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシングの構成に関する項を参照してください。
|
注意: startWebLogicスクリプトを使用することで、クラス・キャッシングはサーバーの起動時に開発モードでサポートされます。デフォルトでは、クラス・キャッシングは無効になっており本番モードではサポートされません。開始時間の短縮はJREベンダーによって異なります。 |
