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

ワークマネージャの最小スレッド制約

最小スレッド制約は、要求クラスと同様に、ワークマネージャのもう1つのコンポーネントです。この制約は非常に特殊なケースで使われます。実行キューのスレッド数パラメータと混同 しないよ うにしてください。最小スレッド制約は、スレッド数を示す整数値を持ちます。このスレッド数は、サーバ間のデッドロックを防止するように、この制約に割り 当てる必要があります。通常、すべてのワークマネージャは、共通のスレッドプールからのスレッドを使用します。ワークマネージャごとのスレッド使用率は、 前のセクションで定義した要求クラスコンポーネントによって決まります。スレッドは、サーバ全体のスループットが最大になるように、共通スレッドプールに 動的に追加されます。

ワークマネージャが最小限のスレッド数を取得できない場合に、2つのサーバがデッドロックを起こすという特殊な状況が発生します。たとえば、サーバ AがサーバBにEJB呼び出しを行い、次に、その要求の処理の一部として、サーバBがサーバAにコールバックを行う場合を考えます。この場合、サーバAが サーバBからのコールバックに応答するまでは、サーバBへの元々の要求は処理されません。このシナリオは、2つの方法で対処できます。サーバAのワークマ ネージャを、サーバBからのコールバック要求用に高いフェアシェアに設定します。これにより、コールバック要求は、クライアントからサーバAに届く新しい 要求よりも高い優先度を持つことを保証できます。さらに、最小スレッド制約の節をワークマネージャに追加することによって、すべてのスレッドがビジーまた はデッドロックになっていても、サーバA内の少なくとも数スレッドは、確実にサーバBからのコールバック要求をピックアップできます。

最小スレッド制約は次のように指定します。

<work-manager>
  <name>MyWorkManager</name>
  <min-threads-constraint>
    <name>minthreads</name>
    <count>3</count>
  </min-threads-constraint>
</work-manager>

ワークマネージャの最大スレッド制約

最大スレッド制約は、その制約を共有するすべてのワークマネージャに与えられる同時実行スレッド数の最大値を制限するために使用します。最小スレッ ド制約と同様に、最大スレッド制約も特殊な状況でのみ使用します。通常、要求クラスは、スレッドリソースのフェアシェアを取得します。共通スレッドプール の最大スレッド数は、スループットを考慮することによって制限されます。サーバ全体のスループットにメリットがない場合、スレッドは追加されません。管理 者またはデプロイ担当が、同時実行スレッド数の最大値は、JDBC接続プールの最大容量によって制限されることを知っている場合があります。たとえば、共 通のJDBC接続プールを使用するすべてのサーブレットやEJB要求は、そのJDBC接続プールの最大サイズによって制限されます。このような状況の場合 は、JDBC接続プールを参照するように最大スレッド制約を定義することができます。そして、この最大スレッド制約を接続プールサイズの影響を受けるすべ てのワークマネージャで共有します。JDBC接続プールを使用する最大スレッド制約の例を以下に示します。

<work-manager>
  <name>MyDataSourceBoundWorkManager</name>
  <max-threads-constraint>
    <name>pool_constraint</name>
    <pool-name>AppScopedDataSource</pool-name>
  </max-threads-constraint>
</work-manager>

AppScopedDataSourceは、アプリケーションスコープを持つか、またはサーバレベルで定義されたデータソースの名前です。この最大スレッド制約は、最大接続プールサイズが変化すると動的に変わります。

最大スレッド制約は、数値で指定することもできます。

<work-manager>
  <name>MyWorkManager</name>
  <max-threads-constraint>
    <name>ejb_maxthreads</name>
    <count>5</count>
  </max-threads-constraint>
</work-manager>

ワークマネージャの容量制約

容量制約は、任意の時点でキューに入れるか、または実行できる要求の最大数を定義したものです。スレッド待ちの要求、または現在実行中の要求のみを カウントします。容量は、複数のワークマネージャで共有できます。これは、容量を共有するすべてのワークマネージャが、共通の上限を持つことを意味しま す。容量が上限に達すると、過負荷アクションが取られます。たとえば、よく知られているHTTP応答コード503や、クラスタのフェイルオーバを許可する RMI呼び出しにおけるRemoteExceptionが発生すると、作業が拒否されます。WebLogic Server 9.0の過負荷保護については、今後のdev2dev記事で説明します。容量は以下のように指定します。

<work-manager>
  <name>MyWorkManager</name>
  <capacity>
    <name>MyCapacity</name>
    <count>10</count>
  </capacity>
</work-manager>

異なる種類の要求クラスや制約間の相互作用

前のセクションでは、フェアシェアや応答時間などのポリシーに基づくスケジューリングについて、同じポリシーを持つ他の作業に対するスケジューリン グと関連させて説明しました。このセクションでは、要求クラスや制約などの種類の異なるポリシーが、お互いにどう相互作用するかについて説明します。

  1. フェアシェアポリシーと応答時間ポリシーを組み合わせると、応答時間スケジューリングに近い傾向を持つスケジューリングになります。
  2. 最小スレッド制約は、フェアシェアを上昇させる場合があります。最小スレッド制約が満たされていないために、その作業セットに属する要求が保留に なっている場合は、最小スレッド制約付きの作業セットから要求がスケジュールされます。たとえ、その要求クラスのフェアシェアが、以前より高い値になって いたとしてもです。その意味で、最小スレッド制約は、フェアシェアよりも優先されます。このため、フェアシェアを上昇させることがないように、最小スレッ ド制約は注意深く使用することが重要です。この動作は、今後変更になる可能性があります。将来のバージョンでは、最小スレッド制約が、フェアシェアを上昇 させることはなくなるかもしれません。ただし、サーバがデッドロック状態で、処理がほとんど進まない場合は、確実に最小スレッド制約が尊重されます。
  3. 最大スレッド制約が、必ずしも、要求クラスがフェアシェアを取得したり、応答時間目標を達成するのを妨げるとは限りません。一旦最大スレッド制約 に達すると、サーバは、同時実行数が上限より下がるまでは、その制約タイプを持つ要求をスケジュールしません。サーバは、フェアシェアや応答時間目標に基 づいて作業をスケジュールします。

Pages: 1, 2, 3, 4, 5

Next Page »