WebLogic Server 9.0におけるワークロード（作業負荷）管理
Pages: 1, 2, 3, 4, 5

実行時におけるワークマネージャの解決方法

前のセクションで述べたとおり、アプリケーションはディスパッチポリシーを設定して、要求のエントリポイントと、指名されたWebLogicワーク マネージャとを関連付けます。デプロイ中に、各モジュールは設定されているディスパッチポリシーを見つけて、サーブレットまたはEJBメソッド呼び出しを 特定のワークマネージャインスタンスにマップします。複数のメソッド呼び出しを、1つのワークマネージャインスタンスにマップすることもできます。特定の メソッド呼び出しやサーブレット呼び出しに対して作成されたユーザ要求はすべて、それに関連付けられたワークマネージャに自動的にディスパッチされます。 そして、それらの要求は、そのワークマネージャのプロパティを取得します。ディスパッチポリシーを新しくして、アプリケーションを再デプロイすることもで きます。

WebLogic Server 9.1では、デプロイをサポートする予定です。この計画は変更される場合があります。WebLogic Server 9.1が利用できるようになったときに、リリースノートを確認してください。

ワークマネージャの代わりに実行キューを使用する

WebLogic Server 9.0のワークマネージャと自動チューニングモードをオフにして、実行キューを使用することもできます。それには、 -Dweblogic.Use81StyleExecuteQueues=trueオプション付きでサーバを起動するか、または config.xmlで KernelMBeanプロパティを設定します。システムプロパティを使用するよりも、 config.xmlの属性を設定する方をお勧めします。それは、管理コンソール内で実行キューのコンフィグレーションや監視をオンにできるからです。以下に、 config.xmlの一部の例を示します。

<server>
  <name>myserver</name>
  <use81-style-execute-queues>true</use81-style-execute-queues>
  <listen-address/>
</server>

このプロパティをオンにすると、すべてのワークマネージャコンフィグレーションと、自動スレッドチューニングモードが無効になります。ユーザは、 WebLogic Server 8.1と全く同じ実行キュー動作を得ることができます。このプロパティを有効にすると、ワークマネージャのコンフィグレーションは、次の手順を使用して実 行キューに変換されます。

1. ワークマネージャが最小スレッド制約または最大スレッド制約を持つ場合、そのワークマネージャと同じ名前を持つ専用の実行キューが作成されます。実行キューのスレッド数は、制約に基づいて決定されます。
2. ワークマネージャが制約を持たない場合は、グローバルなデフォルトの実行キューが使われます。専用の実行キューは作成されません。

このフラグは、自動チューニングスレッドプールとワークマネージャの恩恵を受けられないバージョン8.1からアプリケーションを移行する際に役立ちます。おそらく、ワークマネージャを調査している間に、アプリケーションを実運用環境に移したいと考える人もいるでしょう。

このフラグが有効になっている場合は、サーバログに次のようなエントリが作成されます。

<Sep 30, 2005 11:02:52 AM PDT>
 <Notice> <Kernel> <BEA-000805> <Self-tuning thread pool
 is disabled. An execute queue will be created for 
 each WorkManager definition.>

WebLogic Server 8.1からWebLogic Server 9.0への移行

WebLogic Server 8.1からWebLogic Server 9.0へ移行されたアプリケーションは、移行前に実行キューが存在していた場合は、依然としてサーバコンフィグレーション内に実行キューを持っています。 実行キューからワークマネージャへの自動変換はできません。それは、ワークマネージャが必要でない場合もあるからです。実行キューを持つWebLogic Server 8.1アプリケーションが、WebLogic Server 9.0サーバにデプロイされると、同じ設定を持つ実行キューが作成されて、要求によって使われます。ディスパッチポリシーを持たない要求は、自動チューニ ングスレッドプールを使い続ける点に注意してください。実行キューにマップされたディスパッチポリシーを持つ要求だけが、設定された実行キューを使用しま す。

実行時監視のサポート

広範囲な監視サポートは、RuntimeMBeansによって提供されます。管理者は、個々のワークマネージャ、制約、要求クラス、および共通の自 動チューニングスレッドプールパラメータを監視できます。WebLogicコンソールの適切なタブの下にも、この情報がたくさん表示されます。管理者は、 特定のアプリケーションに移動して、そのアプリケーションに関連するすべてのワークマネージャコンポーネントを監視できます。共通スレッドプールパラメー タは、コンソールタブを監視しているサーバの下で監視されます。以下に、負荷管理についての情報を提供するRuntimeMBeansをいくつか示しま す。

1. ServerRuntimeMBeanの下のThreadPoolRuntimeMBean： 自動チューニングスレッドプールについての情報を監視します。
2. ApplicationRuntimeMBeanの下のWorkManagerRuntimeMBeans： アプリケーション内の個々のワークマネージャについての情報を含みます。ApplicationRuntimeMBeanは、 ServerRuntimeMBeanの子です。
3. ApplicationRuntimeMBeanの下のRequestClassRuntimeMBeans、 MinThreadsConstraintRuntimeMBeans、および MaxThreadsConstraintRuntimeMBeans：複数のワークマネージャで共有されているワークマネージャコンポーネントについて の情報を提供します。

スレッドダンプの変更

WebLogic Server 8.1以前のリリースでは、実行キューに属するスレッドは、スレッドダンプの中ではその実行キューの名前を使用して識別できました。WebLogic Server 9.0では、これが変更になっています。すべてのワークマネージャが共通のスレッドプールを使用するため、スレッドダンプでは、どのスレッドがどのワーク マネージャに所属するかを識別できません。これは、スレッドがすべてのワークマネージャで共有されているからです。すべての実行スレッドの名前には、 「self-tuning」という用語が含まれています。これは、この実行スレッドが共通の自動チューニングプールに属しているこを表しています。スレッ ド名の前には、そのスレッドの状態が付加されています。スレッド名に付加される状態には、次の3種類があります。

1. ACTIVE：スレッドがアクティブで作業を実行中であるか、または作業が到着したらすぐにピックアップできる状態。
2. STANDBY：このスレッドは、アクティブなスレッドプールから削除されていて、作業をピックアップしていない状態。最小スレッド制約付きの作 業セットにおいて、制約が満たされていない場合は、その作業セットからの作業をこのスレッドで実行することができます。スループットの改善に役立たないた め、自動チューニング実装がこのスレッドをアクティブなプールから削除しました。後で必要になれば、アクティブなスレッドプールに戻される可能性もありま す。
3. STUCK：予め設定されたスタックスレッド間隔を超えても、スレッドが作業の実行を行わない状態。このスレッドは、デッドロック、または応答の遅いバックエンド接続のために動かなくなっている可能性があります。

タイマーおよびワークマネージャ仕様のサポート

<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>WorkEJB</ejb-name>
      ...  
      <resource-ref>
        <res-ref-name>MyAppScopedWorkManager-1</res-ref-name>
        <res-type>commonj.work.WorkManager</res-type>
        <res-auth>Container</res-auth>
        <res-sharing-scope>Shareable</res-sharing-scope>
      </resource-ref>
      ...
</ejb-jar>

InitialContext ic = new InitialContext();


commonj.work.WorkManager mgr =
              (commonj.work.WorkManager)
              ic.lookup("java:comp/env/MyAppScopedWorkManager-1");
mgr.schedule(myWork);