ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 9.0 ドキュメント > WebLogic Server 環境のコンフィグレーション > ワーク マネージャを使用したスケジューリング済み作業の最適化

WebLogic Server 環境のコンフィグレーション

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

ワーク マネージャを使用したスケジューリング済み作業の最適化

WebLogic Server では、アプリケーションがどのような優先順位で作業を実行するかをコンフィグレーションできます。ユーザが定義したルールと実際の実行時パフォーマンスのモニタ結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス レベル アグリーメントが維持されます。アプリケーションに適用するルールや制約を定義するには、ワーク マネージャを定義し、これを WebLogic Server ドメインにグローバルに適用するか、特定のアプリケーション コンポーネントに適用します。

 

WebLogic Server でのスレッド プールの使用方法について

以前のバージョンの WebLogic Server では、複数の実行キューで処理を実行していました。クラスの異なる作業を優先順位や順序の要件に基づいて別々のキューで実行することで、デッドロックを回避していました。デフォルトの実行キュー (weblogic.kernel.default) に加え、内部管理トラフィック専用にあらかじめコンフィグレーションされたキュー (weblogic.admin.HTTP、weblogic.admin.RMI など) がありました。

ユーザは、デフォルト キューのスレッドの数を変更することでスレッドの使用状況を制御したり、特定のアプリケーションが全体のシステム負荷に関係なく一定数のスレッドにアクセスできるようカスタム実行キューをコンフィグレーションしたりできました。

WebLogic Server 9.0 では、1 つのスレッド プールですべてのタイプの作業を実行します。作業の優先順位は、ユーザが定義するルールと実行時のメトリックに基づいて決定されます。メトリックとしては、実際に要求を実行するのにかかった時間、要求をプールに出し入れする割合、などがあります。

共通スレッド プールのサイズは、スループットが最大になるように自動的に変更されます。キューは、スループットを長期間にわたってモニタし、その履歴に基づいてスレッド数を調整するかどうかを決定します。たとえば、スループットの統計値の履歴に基づき、スレッド数を増やすことでスループットが向上すると判断されると、スレッド数が自動的に増やされます。同様に、統計値に基づいてスレッドを減らしてもスループットが悪化しないと判断されると、スレッド数が自動的に減らされます。この新しい方式により、管理者は、カスタムの実行キューをコンフィグレーション、モニタ、チューニングする際の手間や複雑さを避けて、より簡単に処理リソースを割り当てたり、パフォーマンスを管理したりできるようになりました。

 

ワーク マネージャについて

WebLogic Server 9.0 では、管理者が定義したパラメータと実行時の実際のパフォーマンスおよびスループットを考慮にいれた実行モデルに基づいて、作業の優先順位が決定されてスレッドが割り当てられます。

管理者は、一連のスケジューリング ガイドラインをコンフィグレーションし、それらを 1 つまたは複数のアプリケーションに関連付けたり、特定のアプリケーション コンポーネントに関連付けたりできます。たとえば、スケジューリング ガイドラインのセットを 1 つのアプリケーションに関連付け、別のガイドラインのセットを別のアプリケーションに関連付けることができます。実行時には、これらのガイドラインに基づいて、保留中の作業やキューに入っている要求が実行スレッドに割り当てられます。

アプリケーション内の作業を管理するには、以下のうち 1 つまたは複数のワーク マネージャ コンポーネントを定義します。

これらのコンポーネントの詳細については、「要求クラス」または「制約」を参照してください。

これらのコンポーネントを使用してアプリケーションのパフォーマンスを制御するには、アプリケーションのデプロイメント記述子でコンポーネントの名前を参照します。また、これらすべてのコンポーネント (コンテキスト要求クラスを除く。「コンテキスト要求クラス」を参照) をカプセル化したワーク マネージャを定義し、このワーク マネージャの名前をアプリケーションのデプロイメント記述子で参照することもできます。複数のワーク マネージャを定義することも可能です。ワーク マネージャの適正数は、WebLogic Server でホストするアプリケーション全体でいくつの個別要求プロファイルが存在するかによって異なります。

ワーク マネージャは、次のいずれかのコンフィグレーション ファイルを使用して、ドメイン レベル、アプリケーション レベル、およびモジュール レベルでコンフィグレーションできます。

コード リスト 2-1 に、ワーク マネージャの定義の例を示します。

コード リスト 2-1 ワーク マネージャ スタンザ

<work-manager>
<name>highpriority_workmanager</name>
   <fair-share-request-class>
      <name>high_priority</name> 
      <fair-share>100</fair-share> 
   </fair-share-request-class>
   <min-threads-constraint>
      <name>MinThreadsCountFive</name>
      <count>5</count>
</work-manager>

コード リスト 2-1 の例で使用されているワーク マネージャを Web アプリケーションのディスパッチ ポリシーで参照するには、コード リスト 2-2 のコードを Web アプリケーションの web.xml ファイルに追加します。

コード リスト 2-2 Web アプリケーションでのワーク マネージャの参照

<init-param>
   <name>dispatch-policy</name>
   <value>highpriority_workmanager</value>
</init-param>

ワーク マネージャで定義および使用できるコンポーネントについては、以降の節で説明します。

要求クラス

要求クラスは、要求へのスレッドの割り当てに使用するスケジューリング ガイドラインを表現します。要求クラスを使用すると、優先順位の高い作業が優先順位の低い作業より後に送信された場合でも、優先順位の高い作業を優先順位の低い作業より前にスケジューリングすることができます。WebLogic Server では、各モジュールが要求を完了するのにかかる時間が考慮されます。

要求クラスにはいくつかのタイプがあり、それぞれ条件の異なったスケジューリング ガイドラインを表現します。1 つのワーク マネージャに、要求クラスを 1 つだけ指定することもできます。

コンテキスト要求クラス

コンテキスト要求クラスを使用すると、アプリケーションのデプロイメント記述子で、ユーザのコンテキストに基づいて要求クラスを定義できます。次に例を示します。

コード リスト 2-3 コンテキスト要求クラス

<work-manager>
  <name>responsetime_workmanager</name>
    <response-time-request-class>
      <name>my_response_time</name>
      <goal-ms>2000</goal-ms>
   </response-time-request-class>
</work-manager>

<work-manager>
  <name>context_workmanager</name>
  <context-request-class>
    <name>test_context</name>
    <context-case>
      <user-name>system</user-name>
      <request-class-name>high_fairshare</request-class-name> 
   </context-case>
   <context-case>
      <group-name>everyone</group-name>
      <request-class-name>low_fairshare</request-class-name> 
    </context-case>
  </context-request-class>
</work-manager>

この例では、同じ要求クラスを使用して別の作業にスケジューリングを関連付けることで、フェア シェアと応答時間に基づいた要求クラスを説明しています。フェア シェア要求クラスと応答時間要求クラスを併用すると、応答時間スケジューリングに著しく偏ったスケジューリングになります。

制約

制約を使用すると、要求を実行するために割り当てられるスレッドの最小数と最大数、および WebLogic Server が要求を拒否し始めるまでにキューに入れたり実行したりできる要求の総数を定義できます。

以下のタイプの制約を定義できます。

スタック スレッドの処理

スタック スレッドに応じて、スタック スレッド ワーク マネージャ コンポーネントを定義できます。このコンポーネントを使用すると、ワーク マネージャを停止したり (結果としてすべてのスレッドが強制停止する)、アプリケーションを管理モードにしたり、サーバ インスタンスを障害が発生したものとしてマークしたりできます。たとえば、コード リスト 2-4 で定義するワーク マネージャは、2 つのスレッドが 30 秒を超えてスタックすると停止します。

コードリスト 2-4 スタック スレッド ワーク マネージャ

<work-manager>
   <name>stuckthread_workmanager</name>
   <work-manager-shutdown-trigger>
      <max-stuck-thread-time>30</max-stuck-thread-time>
      <stuck-thread-count>2</stuck-thread-count>
   </work-manager-shutdown-trigger>
</work-manager>

 

アプリケーションおよびアプリケーション コンポーネントへのワーク マネージャの割り当て

ワーク マネージャは、以下の記述子で指定できます。

ワーク マネージャが割り当てられていないアプリケーションでは、デフォルトのワーク マネージャが使用されます。

ワーク マネージャにメソッドを割り当てるには、デプロイメント記述子で <dispatch-policy> 要素を使用します。下位互換性を維持するため、<dispatch-policy> でカスタム実行キューも指定できるようになっています。例については、コード リスト 2-2 を参照してください。

 

ワーク マネージャ、要求クラス、および制約の使い方

ワーク マネージャ、要求クラス、および制約では、以下が必要になります。

EJB のディスパッチ ポリシー

weblogic-ejb-jar.xml - weblogic-enterprise-bean の既存の dispatch-policy タグの値は、名前付きの dispatch-policy にできます。下位互換性のため、ExecuteQueue を指定することもできます。また、現在の isolation-level タグのように、dispatch-policy、max-threads、または min-threads を使用して、メソッドのリストに名前付きの (または制約が数値で名前がない) ポリシーおよび制約を指定することも可能です。

Web アプリケーションのディスパッチ ポリシー

weblogic.xml - web.xml の filter-mapping と同様のマッピングもサポートされています。名前付きの dispatch-policy、max-threads、または min-threads が、url-pattern またはサーブレット名にマッピングされます。

 

デプロイメント記述子の例

この節では、さまざまなデプロイメント記述子を使用したワーク マネージャの定義例を示します。

必要に応じて、各デプロイメント記述子のスキーマも参照してください。

コードリスト 2-5 ワーク マネージャのエントリを含む weblogic-ejb-jar.xml

<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
   http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">

<weblogic-enterprise-bean>
   <ejb-name>WorkEJB</ejb-name> 
   <jndi-name>core_work_ejb_workbean_WorkEJB</jndi-name> 
   <dispatch-policy>weblogic.kernel.System</dispatch-policy> 
</weblogic-enterprise-bean>

<weblogic-enterprise-bean>
   <ejb-name>NonSystemWorkEJB</ejb-name> 
   <jndi-name>core_work_ejb_workbean_NonSystemWorkEJB</jndi-name>
   <dispatch-policy>workbean_workmanager</dispatch-policy> 
</weblogic-enterprise-bean>

<weblogic-enterprise-bean>
   <ejb-name>MinThreadsWorkEJB</ejb-name> 
   <jndi-name>core_work_ejb_workbean_MinThreadsWorkEJB</jndi-name>
   <dispatch-policy>MinThreadsCountFive</dispatch-policy> 
</weblogic-enterprise-bean>

<work-manager>
   <name>workbean_workmanager</name>
</work-manager>

<work-manager>
   <name>stuckthread_workmanager</name>
   <work-manager-shutdown-trigger>
      <max-stuck-thread-time>30</max-stuck-thread-time>
      <stuck-thread-count>2</stuck-thread-count>
   </work-manager-shutdown-trigger>
</work-manager>

<work-manager>
   <name>minthreads_workmanager</name>
   <min-threads-constraint>
      <name>MinThreadsCountFive</name>
      <count>5</count>
   </min-threads-constraint>
</work-manager>

<work-manager>
   <name>lowpriority_workmanager</name> 
   <fair-share-request-class>
      <name>low_priority</name>
      <fair-share>10</fair-share> 
   </fair-share-request-class>
</work-manager>

<work-manager>
<name>highpriority_workmanager</name>
   <fair-share-request-class>
      <name>high_priority</name> 
      <fair-share>100</fair-share> 
   </fair-share-request-class>
</work-manager>

<work-manager>
<name>veryhighpriority_workmanager</name>
   <fair-share-request-class>
      <name>veryhigh_priority</name> 
      <fair-share>1000</fair-share> 
   </fair-share-request-class>
</work-manager>

コード リスト 2-6 接続プール ベースの最大スレッド数制約を含む weblogic-ejb-jar.xml

これらの EJB は、依存するリソース (接続プールおよびアプリケーション スコープの接続プール) のインスタンスが存在する限り、なるべく多くのスレッドを取得するようにコンフィグレーションされています。

</weblogic-ejb-jar>
<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
   http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">

   <weblogic-enterprise-bean>
     <ejb-name>ResourceConstraintEJB</ejb-name> 
      <jndi-name>core_work_ejb_resource_ResourceConstraintEJB</jndi-name> 
      <dispatch-policy>test_resource</dispatch-policy> 
   </weblogic-enterprise-bean>

   <weblogic-enterprise-bean>
      <ejb-name>AppScopedResourceConstraintEJB</ejb-name> 
      <jndi-name>core_work_ejb_resource_AppScopedResourceConstraintEJB
      </jndi-name>
      <dispatch-policy>test_appscoped_resource</dispatch-policy> 
   </weblogic-enterprise-bean>

<work-manager>
   <name>test_resource</name>
    <max-threads-constraint>
      <name>pool_constraint</name>
      <pool-name>testPool</pool-name>
   </max-threads-constraint>
</work-manager>

<work-manager>
   <name>test_appscoped_resource</name>
   <max-threads-constraint>
      <name>appscoped_pool_constraint</name>
      <pool-name>AppScopedDataSource</pool-name>
   </max-threads-constraint>
</work-manager>
</weblogic-ejb-jar>

コード リスト 2-7 CommonJ ワーク マネージャを含む weblogic-ejb-jar.xml

CommonJ の使い方については、「WebLogic Server での CommonJ ワーク マネージャの使い方」および「CommonJ の Javadoc」を参照してください。

コード リスト 2-8 weblogic-application.xml

<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
   http://www.bea.com/ns/weblogic/90/weblogic-application.xsd">

   <max-threads-constraint>
      <name>j2ee_maxthreads</name> 
      <count>1</count> 
   </max-threads-constraint>

   <min-threads-constraint>
      <name>j2ee_minthreads</name> 
      count>1</count> 
   </min-threads-constraint>

   <work-manager>
      <name>J2EEScopedWorkManager</name> 
      </work-manager>
</weblogic-application>

コード リスト 2-9 Web アプリケーション記述子

この Web アプリケーションは、コード リスト 2-8 で定義したエンタープライズ アプリケーションの一部としてデプロイされます。この Web アプリケーションの記述子では、2 つのワーク マネージャを定義しています。どちらのワーク マネージャも、アプリケーションの weblogic-application.xml ファイルで定義した同じ最大スレッド数制約 (j2ee_maxthreads) を参照しています。応答時間要求クラスは、ワーク マネージャごとに異なっています。

<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
   xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
   http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">

   <work-manager>
      <name>fast_response_time</name> 
      <response-time-request-class>
         <name>fast_response_time</name> 
         <goal-ms>2000</goal-ms> 
      </response-time-request-class>
      <max-threads-constraint-name>j2ee_maxthreads
      </max-threads-constraint-name>
   </work-manager>

   <work-manager>
      <name>slow_response_time</name> 
      <max-threads-constraint-name>j2ee_maxthreads
      </max-threads-constraint-name
      <response-time-request-class>
         <name>slow_response_time</name> 
         <goal-ms>5000</goal-ms> 
      </response-time-request-class>
   </work-manager>

</weblogic-web-app>

コード リスト 2-10 Web アプリケーション記述子

この記述子では、context-request-class を使用してワーク マネージャを定義しています。

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90"
xmlns:j2ee="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/90
http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
 <work-manager>
  <name>foo-servlet-1</name>
  <request-class-name>test-fairshare2</request-class-name>
  <max-threads-constraint>
    <name>foo-mtc</name>
    <pool-name>oraclePool</pool-name>
  </max-threads-constraint>
 </work-manager>

 <work-manager>
  <name>foo-servlet</name>
  <context-request-class>
  <name>test-context</name>
  <context-case>
    <user-name>anonymous</user-name>
    <request-class-name>test-fairshare1</request-class-name> 
  </context-case>
   <context-case>
    <group-name>everyone</group-name>
    <request-class-name>test-fairshare2</request-class-name> 
   </context-case>
  </context-request-class>
 </work-manager>
</weblogic-web-app>

 

WebLogic Server での CommonJ ワーク マネージャの使い方

WebLogic Server 9.0 は、BEA と IBM の共同仕様 (CommonJ) の一部をサポートしています。CommonJ の一般的な情報については、http://www.beasys.co.jp/dev2dev/technologies/commonj/index.html を参照してください。

Work Manager API を使用すると、アプリケーションは、WebLogic Server でコンフィグレーション済みの複数のワーク マネージャを使用して、1 つの要求のタスクを複数の作業項目に分割し、その作業項目を割り当てて、同時に実行することができます (作業項目を同時に実行する必要のないアプリケーションでも、コンフィグレーション済みのワーク マネージャを使用することができます。それには、デプロイメント記述子でワーク マネージャを参照または作成するか、J2EE コネクタの場合は JCA API を使用します)。新しいワーク マネージャのチューニング方式の詳細については、「プロダクション環境でのサーバの自動チューニング」も参照してください。

CommonJ ワーク マネージャへのアクセス

WebLogic Server ワーク マネージャにアプリケーションからアクセスするにはディスパッチ ポリシーを使用する必要がありますが、CommonJ ワーク マネージャはアプリケーションから直接アクセスできます。次のコード例に、JNDI を使用して CommonJ ワーク マネージャをルックアップする方法を示します。

InitialContext ic = new InitialContext();
commonj.work.WorkManager wm = (WorkManager);
ic.lookup(`java:comp/env/wm/myWM');

CommonJ ワーク マネージャの使い方の詳細については、「CommonJ の Javadoc」を参照してください。

WebLogic Server ワーク マネージャへの CommonJ のマッピング

外部定義した CommonJ ワーク マネージャは、WebLogic Server ワーク マネージャにマッピングできます。たとえば、次の例のように、記述子 ejb-jar.xml で定義した CommonJ ワーク マネージャがあるとします。

<resource-ref>
<res-ref-name>minthreads_workmanager</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>

これを WebLogic Server ワーク マネージャにリンクさせるには、WebLogic Server の記述子 (たとえば weblogic-ejb-jar.xml) の name 要素を完全に一致させます。

<work-manager>
<name>minthreads_workmanager</name>
<min-threads-constraint>
<count>5</count>
</min-threads-constraint>
</work-manager>

この手順は、web.xml に定義した resource-ref と同様です。WebLogic Server ワーク マネージャは、モジュール記述子 (たとえばweblogic-ejb-jar.xml や weblogic.xml) またはアプリケーション記述子 (weblogic-application.xml) で定義できます。

 

フッタのナビゲーションのスキップ  ページの先頭 前 次