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