Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
戻る |
次へ |
以前のリリースでパフォーマンスを向上させるために実行キューを使用していた場合は、アプリケーション ドメインを WebLogic Server 9.x にアップグレードした後も引き続き実行キューを使用できます。
注意 : 実行キューから、ワーク マネージャによる自動チューニング実行キューの使用に移行することをお勧めします。『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。 |
アップグレード後のアプリケーションがユーザ定義の実行キューを引き続き使用できるように、自動チューニング実行プールを無効にして下位互換性を提供するためのフラグが用意されています。
WebLogic Server 9.x ドメインでユーザ定義の実行キューを使用するには、config.xml ファイルの server
要素に use81-style-execute-queues
下位要素を指定して、サーバを再起動する必要があります。
注意 : 81-style-execute-queues モードで WebLogic Server を実行し、スレッド数を調整できるようにするには、追加の手順が必要です。まず、コンフィグレーション ファイルで use81-style-execute-queues 要素を true に設定し、次に、Administration Console でweblogic.kernel.Default 実行キューを明示的に作成し、サーバを再起動します。 |
以下のサンプル コードでは、myserver
というインスタンスが実行キューを使用できるようにします。
コード リスト B-1 use81-style-execute-queues 要素の使用
.
.
.
<server>
<name>myserver</name>
<ssl>
<name>myserver</name>
<enabled>true</enabled>
<listen-port>7002</listen-port>
</ssl>
<use81-style-execute-queues>true</use81-style-execute-queues>
<listen-address/>
</server>
.
.
.
コンフィグレーション済みのワーク マネージャは、実行時にサーバ インスタンスによって実行キューに変換されます。
config.xml
ファイルの ExecuteQueue
要素の ThreadCount
属性の値は、実行キューを使用するアプリケーションで実行可能な同時処理の数と同じです。処理が WebLogic Server のインスタンスに渡されると、その処理は実行キューに置かれます。次に、この処理は 1 つのスレッドに割り当てられて実行されます。スレッドはリソースを消費するため、この属性は注意して取り扱う必要があります。値を不必要に大きくすると、パフォーマンスが低下する可能性があります。WebLogic Server は、サーバ インスタンスの起動モードに応じて、デフォルト実行キューのスレッド数として異なるデフォルト値を使用します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「起動モードの指定」を参照してください。
追加の実行キューをコンフィグレーションしてアプリケーションを割り当てない限り、サーバ インスタンスはデフォルトの実行キューに要求を割り当てます。
注意 : ネイティブ パフォーマンス パックがプラットフォームで使用されていない場合は、パフォーマンスを最適化するために、実行キューのスレッドのデフォルト数とソケット リーダーとして機能するスレッドの割合をチューニングする必要があります。詳細については、「ソケット リーダーとしての実行スレッドの割り当て」を参照してください。 |
デフォルト実行キューにスレッドを増やしたからといって、必ずしもより多くの作業を処理できるわけではありません。スレッドを増やした場合でも、依然としてプロセッサの処理能力による制約を受けます。ThreadCount
属性の値を不必要に大きくすると、パフォーマンスが低下する可能性があります。実行スレッドを大きくすると、メモリの使用量が大きくなり、コンテキストの切り替えが増加し、パフォーマンスが低下する可能性があります。
ThreadCount
属性の値は、アプリケーションが実行する処理のタイプによって大きく異なります。たとえば、使用しているクライアント アプリケーションが軽量で、その処理の多くをリモート呼び出しを介して行う場合、そのクライアント アプリケーションが接続に費やす時間は多くの処理をクライアントサイドで行うクライアント アプリケーションより長くなり、その結果としてスレッド数の値をより大きくしなければならなくなります。
デフォルトの 15 (開発モード) または 25 (プロダクション モード) を超えるスレッドを使用する必要がない場合は、この属性の値を変更しないようにします。一般に、アプリケーションが応答に時間のかかるデータベース呼び出しを行う場合は、応答が早く時間のかからない呼び出しを行うアプリケーションより多くの実行スレッドが必要となります。後者のケースでは、実行スレッドの数を減らすとパフォーマンスが向上します。
実行キューの理想的なスレッド数を決めるには、キュー内のすべてのアプリケーションが最大負荷で動作しているときにキューのスループットをモニタします。キューのスレッド数を増やし、キューのスループットが最適になるまで負荷テストを繰り返します。あるポイントまでスレッドの数を増やしていくと、コンテキストの切り替えが増えすぎて、キューのスループットが低下し始めるので注意してください。
注意 : WebLogic Server Administration Console には、サーバのすべての実行キューの累積スループットが表示されます。このスループット値にアクセスするには、「実行キューによるスレッド使用の制御」の手順 1 ~ 6 に従います。 |
表 B-2 に、WebLogic Server ドメインで使用できる CPU 数との関係で使用可能なスレッドを調整するためのデフォルトのシナリオを示します。これらのシナリオも、WebLogic Server が最大負荷で動作し、すべてのスレッド要求がデフォルト実行キューを使用して満たされることを前提としています。追加の実行キューをコンフィグレーションして、特定のキューにアプリケーションを割り当てる場合は、結果をプールごとにモニタします。
表 B-2 デフォルト スレッド数を変更するシナリオ
条件 | 結果 | 対策 |
---|---|---|
スレッド数 < CPU の数 |
CPU の使用率が低いが、実行できる処理がある。 |
スレッド数を増加させる。 |
スレッド数 = CPU の数 |
CPU の使用率が低いが、実行できる処理がある。 |
スレッド数を増加させる。 |
スレッド数 > CPU の数 (スレッド数が適度に多い) |
適度なコンテキストの切り替え数があり、高い CPU 使用率が実現される。 |
スレッド数をさらにチューニングして、パフォーマンスの結果を比較する。 |
スレッド数 > CPU の数 (スレッド数が過度に多い) |
コンテキストの切り替え数が多すぎる。 |
スレッドの数を減らす。 |
WebLogic Server でユーザ定義の実行キューを使用すると、アプリケーションから実行スレッドへのアクセスを微調整できます (したがって、パフォーマンスを最適化または抑制できる)。ただし、未使用のスレッドは、WebLogic Server システムのリソースをかなり消費する点に注意してください。他のキューのタスクがアイドル状態でスレッドが使用可能になるのを待機している間に、コンフィグレーションされた実行キューの使用可能なスレッドが未使用になることがあります。この場合、スレッドを複数のキューに分割したことが原因で、1 つのデフォルト実行キューの場合よりも全体のパフォーマンスが低下する可能性があります。
デフォルトの WebLogic Server にはデフォルトの実行キューがコンフィグレーションされています。この実行キューは、サーバ インスタンスで実行されるすべてのアプリケーションで使用されます。キューは、以下の目的のためにコンフィグレーションして追加できます。
重要度の高いアプリケーションのパフォーマンスの最適化。たとえば、単一のミッションクリティカルなアプリケーションを特定の実行キューに割り当てると、固定数の実行スレッドを確保することができます。サーバの負荷のピーク時には、重要度の低いアプリケーションがデフォルト実行キューで競合することがありますが、ミッションクリティカルなアプリケーションは常に同数のスレッドにアクセスできます。
重要度の低いアプリケーションのパフォーマンスの抑制。大量のメモリを消費する可能性があるアプリケーションについては、指定した実行キューにそのアプリケーションを割り当てると、効果的にメモリの消費量を制限することができます。割り当てた実行キューで使用可能なすべてのスレッドをアプリケーションで使用できますが、他のキューのスレッドの使用には影響しません。
スレッド使用のデッドロックの回避。アプリケーションの設計によっては、実行スレッドがすべて使用中になるとデッドロックが発生することがあります。たとえば、指定した JMS キューからメッセージを読み込むサーブレットがあると仮定します。サーバのすべての実行スレッドがサーブレット要求の処理に使用されると、JMS キューからメッセージを配信するのに使用できるスレッドはなくなってしまいます。デッドロック状態が生じ、処理が続行できなくなります。この場合、別々の実行キューにサーブレットを割り当てると、サーブレットと JMS キューにスレッド リソースの競合が生じないので、デッドロックを回避することができます。
システム全体でスレッドを適切に使用するには、必ず各実行キューをモニタしてください。スレッド数の最適化に関する概要については、「デフォルト スレッド数の変更」を参照してください。
実行キューは、1 つまたは複数の指定されたサーブレット、JSP、EJB、または RMI オブジェクトで利用可能な実行スレッドの名前付きコレクションを表します。
Administration Console で新しい実行キューを作成するには、次の手順に従います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、実行キューをコンフィグレーションするサーバ インスタンスを選択します。
[コンフィグレーション|キュー] タブを選択して、[新規作成] をクリックします。
実行キューの名前を指定して [OK] をクリックします。
[ユーザ定義の実行キュー] ページで、作成した実行キューを選択します。
実行キューの [コンフィグレーション] タブで、以下の属性の値を変更するか、システムのデフォルトをそのまま使用します。
[キューの長さ] - キューの長さは、常にデフォルトの 65536 エントリのままにします。[キューの長さ] では、サーバがキューに保持できる同時要求の最大数を指定します。デフォルトの 65536 は非常に大きな数です。キューの未処理の要求がこの最大値に達することはほとんどありません。
[キューの長さ] の値に達すると、超過分に対応するためにキューのサイズが自動的に 2 倍になります。キューの要求が 65536 を超えた場合、それはキューの長さではなくキューのスレッドに問題があること示します。実行キューでスタック スレッドがないか、またはスレッド数が不十分ではないかを確認してください。
[キューの長さのしきい値比率] - サーバがキューのオーバーフロー条件を示す前に到達する [キューの長さ] のパーセンテージ (1 ~ 99) を入力します。しきい値のパーセンテージ以下の実際のキューの長さはすべて通常と見なされ、しきい値のパーセンテージを超えるサイズはオーバーフローを示します。オーバーフロー条件に達すると、WebLogic Server はエラー メッセージをログに記録し、[スレッド数の増分] 属性の値分だけキューのスレッド数を増やして負荷を軽減します。
デフォルトでは、[キューの長さのしきい値比率] の値は 90% です。ほとんどの場合、この値は 90% のままにするか、その前後の値に設定します。処理要求の突然の増加に対処するために追加スレッドが必要になる可能性のある、現実に起こりそうなあらゆる状況に対応するためです。[キューの長さのしきい値比率] は、自動チューニング パラメータとしては使用しないでください。通常の操作状況では、そのしきい値によってスレッド数の増加が誘発されることはありません。
[スレッド数] - このキューに割り当てられたスレッド数です。デフォルトの 15 を超えるスレッドを使用する必要がない場合は、この属性の値を変更しないようにします。詳細については、「デフォルト スレッド数の変更」を参照してください。
[スレッド数の増分] - WebLogic Server がオーバーフロー条件を検出したときにこの実行キューに追加するスレッドの数を入力します。ゼロ スレッド (デフォルト) を指定した場合、サーバはスレッドのオーバーフロー条件に対して自己の状態を「warning」に変更しますが、追加スレッドを割り当てて負荷を軽減することはありません。
注意 : WebLogic Server がオーバーフロー条件に反応してスレッド数を増やすと、その追加のスレッドはサーバが再起動されるまで実行キューにとどまります。エラー ログをモニタしてオーバーフロー条件の原因を判別し、同様の状況が今後起こらないように必要に応じてスレッド数を再コンフィグレーションします。[スレッド数の増分] と [キューの長さのしきい値比率] の組み合わせを自動チューニング ツールとして使用することはしないでください。そのようにすると、実行キューで必要以上のスレッドが割り当てられ、コンテキストの切り替えが原因でパフォーマンスが低下することになります。 |
[最小スレッド数] - 不要なオーバーフロー条件を防ぐために、WebLogic Server がこの実行キューで保持するスレッドの最小数。デフォルトでは、[最小スレッド数] は 5 に設定されています。
[最大スレッド数] - この実行キューが持つことのできる最大スレッド数を指定します。この値によって、WebLogic Server が継続的なオーバーフロー条件に対してキュー内に過剰な数のスレッドを作成することを防ぎます。デフォルトでは、[最大スレッド数] は 400 に設定されています。
[保存] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。直ちにすべての変更が反映されるわけではなく、一部の変更は再起動するまで適用されません。
スレッドの検出動作に関する新しい値を使用するには、サーバを再起動する必要があります。
Administration Console でデフォルト実行キューのスレッド数を変更するには、次の手順を行います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、スレッドの検出動作をコンフィグレーションするサーバ インスタンスを選択します。
[コンフィグレーション|キュー] タブで、デフォルトのスレッド数を変更する実行キューを選択します。
変更できるのは、サーバのデフォルト実行キューまたはユーザ定義の実行キューだけです。
必要に応じて [スレッド数] の値を増減します。
[保存] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。直ちにすべての変更が反映されるわけではなく、一部の変更は再起動するまで適用されません。
スレッドの検出動作に関する新しい値を使用するには、サーバを再起動する必要があります。
デフォルトの実行キューやユーザ定義の実行キューでオーバーフローになりそうな条件を検出し、必要に応じて対応するように WebLogic Server をコンフィグレーションできます。WebLogic Server は、キューのサイズがユーザ定義の最大サイズにおけるパーセンテージに達した場合、キューにオーバーフロー条件の可能性があることを認識します。しきい値に達すると、サーバは自己の状態を「warning」に変更し、必要に応じて、キュー内の未処理の作業を追加のスレッドに割り当ててそのキューの長さを短くします。
キューのオーバーフロー条件を自動的に検出したり、対処したりするには、以下の項目をコンフィグレーションします。
サーバがオーバーフロー条件を示すしきい値。この値は、コンフィグレーションされた実行キューのサイズのパーセンテージとして設定します (QueueLength
値)。
オーバーフロー条件が検出されたときに実行キューに追加されるスレッドの数。これらの追加スレッドは、キューのサイズを、通常の動作サイズまで減らすよう機能します。
キューに対して使用できる最大および最小スレッド数。特に、スレッドの最大数を設定することで、サーバがオーバーロード条件への対応のために過剰なスレッド数を割り当てることを防ぎます。
WebLogic Server Administration Console を使用して実行キューをチューニングするには、次の手順に従います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、オーバーフロー条件の動作をコンフィグレーションするサーバ インスタンスを選択します。
[コンフィグレーション|キュー] タブで、オーバーフロー条件の動作をコンフィグレーションする実行キューを選択します。
サーバ インスタンスが、選択したキューに対するオーバーフロー条件をどのように検出するかを指定するには、次の属性を変更します。
[キューの長さ] - サーバがキューに保持できる同時要求の最大数を指定します。デフォルトの 65536 は非常に大きな数です。キューの未処理の要求がこの最大値に達することはほとんどありません。[キューの長さ] は常にデフォルトの 65536 エントリのままにします。
[キューの長さのしきい値比率] - サーバがキューのオーバーフロー条件を示す前に到達する [キューの長さ] のパーセンテージ (1 ~ 99) を入力します。しきい値のパーセンテージ以下の実際のキューの長さはすべて通常と見なされ、しきい値のパーセンテージを超えるサイズはオーバーフローを示します。デフォルトでは、[キューの長さのしきい値比率] は 90% に設定されます。
このサーバが、選択したキューに対するオーバーフロー条件にどのように対応するかを指定するには、次の属性を変更します。
[スレッド数の増分] - WebLogic Server がオーバーフロー条件を検出したときにこの実行キューに追加するスレッドの数を入力します。ゼロ スレッド (デフォルト) を指定した場合、サーバは実行キューのオーバーフロー条件に対して自己の状態を「warning」に変更しますが、追加スレッドを割り当てて負荷を軽減することはありません。
この実行キューのスレッド数を微調整するには、以下の属性を変更します。
[最小スレッド数] - 不要なオーバーフロー条件を防ぐために、WebLogic Server がこの実行キューで保持するスレッドの最小数。デフォルトでは、[最小スレッド数] は 5 に設定されています。
[最大スレッド数] - この実行キューが持つことのできる最大スレッド数を指定します。この値によって、WebLogic Server が継続的なオーバーフロー条件に対してキュー内に過剰な数のスレッドを作成することを防ぎます。デフォルトでは、[最大スレッド数] は 400 に設定されています。
[保存] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。直ちにすべての変更が反映されるわけではなく、一部の変更は再起動するまで適用されません。
スレッドの検出動作に関する新しい値を使用するには、サーバを再起動する必要があります。
初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは JSP を割り当てることができます。初期化パラメータは、サーブレットまたは JSP のデプロイメント記述子ファイル web.xml の init-param
要素内で指定されています。実行キューを割り当てるには、次に示すように wl-dispatch-policy
パラメータの値としてキュー名を入力します。
<servlet> <servlet-name>MainServlet</servlet-name> <jsp-file>/myapplication/critical.jsp</jsp-file> <init-param> <param-name>wl-dispatch-policy</param-name> <param-value>CriticalAppQueue</param-value> </init-param> </servlet>
web.xml での初期化パラメータの指定については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「サーブレットの作成とコンフィグレーション」を参照してください。
コンフィグレーションされた実行キューに EJB オブジェクトを割り当てるには、weblogic-ejb-jar.xml で新しい dispatch-policy
要素を使用します。詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
appc
コンパイラの -dispatchPolicy
フラグを使用してディスパッチ ポリシーを設定することもできますが、フラグではなくデプロイメント記述子要素を使用することをお勧めします。この方法により、たとえばデプロイ中に EJB が再コンパイルされる場合でも、設定が失われません。
コンフィグレーションされた実行キューに RMI オブジェクトを割り当てるには、rmic
コンパイラで -dispatchPolicy
オプションを使用します。次に例を示します。
java weblogic.rmic -dispatchPolicy CriticalAppQueue ...
Administration Console を使用して実行スレッドの状態をモニタするには、次の手順に従います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、スレッドの検出動作をコンフィグレーションするサーバ インスタンスを選択します。
[モニタ|スレッド] タブを選択します。
このサーバ インスタンスで使用可能な実行キューのテーブルが表示されます。
スレッド情報を表示する実行キューを選択します。
選択した実行キューの実行スレッドのテーブルが表示されます。
最適なパフォーマンスを得るために、WebLogic Server インスタンスのホストであるマシン上では、pure-Java 実装ではなくネイティブのソケット リーダー実装を使用することをお勧めします (「スレッド管理」を参照)。ただし、ホスト マシンで pure-Java ソケット リーダー実装を使用しなければならない場合でも、サーバ インスタンスごとにソケット リーダー スレッドとして機能する実行スレッドの数を適切にコンフィグレーションすることによって、ソケット通信のパフォーマンスを向上させることができます。
ThreadPoolPercentSocketReaders
属性は、ソケットからメッセージを読み込む実行スレッドの割合の最高値を設定します。この属性の最適値は、アプリケーションによって異なります。デフォルト値は 33、有効範囲は 1 ~ 99 です。
実行スレッドをソケット リーダー スレッドとして割り当てると、サーバがクライアント要求を受け入れる速度と能力が向上します。重要なのは、ソケットからメッセージを読み込む実行スレッドの数と、サーバでタスクを実際に実行するスレッド数のバランスを取ることです。
Administration Console を使用してソケットからメッセージを読み込む実行スレッドの割合の最高値を設定するには、次の手順を行います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、スレッドの検出動作をコンフィグレーションするサーバ インスタンスを選択します。
[コンフィグレーション|チューニング] タブを選択します。
[ソケット リーダー] フィールドで Java リーダー スレッドの割合を指定します。Java ソケット リーダーの数が、合計実行スレッド数の割合として計算されます。合計実行スレッド数は、実行キューの [スレッド数] フィールドに表示されます。
[保存] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。
クライアント マシン上では、クライアントを実行する JVM 内で使用できるソケット リーダー スレッドの数をコンフィグレーションできます。ソケット リーダーを指定するには、クライアントの java
コマンドラインで以下のパラメータを定義します。
-
Dweblogic.ThreadPoolSize=value
-Dweblogic.ThreadPoolPercentSocketReaders=value
WebLogic Server は、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバはスタック スレッドを診断するたびに、メッセージのロギングを行います。
WebLogic Server は、設定した期間、作業状態が継続した (アイドルでない) 場合、スレッドをスタック状態と診断します。サーバのスレッド検出動作は、スレッドがスタック状態と診断されるまでの時間や、サーバがスタック スレッドをチェックする頻度を変更することでチューニングできます。WebLogic Server がスレッドがスタックかどうかを判断するために使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になった場合に「warning」および「critical」状態を設定するデフォルト動作を変更することはできません。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ログ ファイルのコンフィグレーションとログ メッセージのフィルタ処理』の「WebLogic ロギング サービスについて」を参照してください。
スタック スレッドの検出動作をコンフィグレーションするには、次の手順に従います。
まだ行っていない場合、Administration Console のチェンジ センタで [ロックして編集] をクリックします。
Administration Console の左ペインで、[環境|サーバ] を展開します。
[サーバの概要] ページで、スレッドの検出動作をコンフィグレーションするサーバ インスタンスを選択します。
[コンフィグレーション|チューニング] タブで、必要に応じて以下の設定を更新します。
[スタック スレッド最大時間] - このサーバ インスタンスがスレッドをスタック状態であると診断するまでの、スレッドの継続動作時間 (秒単位)。
[スタック スレッド タイマ間隔] - [スタック スレッド最大時間] でコンフィグレーションした期間スレッドが継続動作しているかどうかを、サーバ インスタンスが定期的にスキャンする間隔 (秒単位)。
[保存] をクリックします。
Administration Console のチェンジ センタで [変更のアクティブ化] をクリックしてこれらの変更をアクティブ化します。直ちにすべての変更が反映されるわけではなく、一部の変更は再起動するまで適用されません。
スレッドの検出動作に関する新しい値を使用するには、サーバを再起動する必要があります。