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