WebSphere Application Server for z/OS, Version 6.0.x   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

z/OS でのメッセージ駆動型 Bean の MDB スロットル設定

「MDB スロットル」のさまざまな設定を調整して、 サーバーが所定時刻に処理する MDB 作業の量を制御することができます。

このトピックでは、使用する MDB スロットル設定の選択に影響する、以下の概念と考慮事項について説明します。

MDB スロットル - しきい値の上限と下限

注: このトピックの情報は、単一のリスナー・ポートを 指定された宛先にマッピングすることが前提となっています。 スロットルしきい値は、 各リスナー・ポートごとに個別に計算されますが、 キュー・エージェント・スレッドは、 リスナー・ポートの数に関係なく、 宛先ごとに 1 つだけ存在します。 例えば、リスナー・ポート A と B をキュー Q にマップした場合、 リスナー・ポート B が下限しきい値に達すると、 リスナー・ポート A が上限しきい値に達していても、 リスナー・ポート B は、 キュー Q の単一キュー・エージェント・スレッド上に スロットルをリリースします (リスナー・ポートがマップされた場合には、 宛先を分離するためにブロックします。) 具体的に説明すると、 各リスナー・ポート上のメッセージ駆動型 Bean で シリアル処理を実行した場合、 複数のリスナー・ポートを単一の宛先にマップして、 各リスナー・ポートに上限しきい値 1 を設定することはできない、 ということです。 このような制限があるため、 単一のリスナー・ポートを、 各宛先にのみマップすることを強くお勧めします。

MDB スロットル・サポートは、各リスナー・ポートの現在処理されているメッセージ数のカウントを維持します。

「コントローラー内で listen する」基本メッセージング・フローで説明されるようにメッセージ参照が MRH に送信されると、 処理中のカウントは 1 ずつ増加します。 次に、このリスナー・ポートの上限しきい値と処理中のカウントが比較されます。
  • 処理中のカウントが上限しきい値以下である場合、 作業レコードは WLM キューに入れられます。
  • 処理中のカウントが上限しきい値を超えると、MRH を実行しているキュー・エージェント・スレッドがブロックされ、 待機状態に入ります。 これを、スロットルが「ブロックしている」といいます。

処理中のカウントは、コントローラーが、 このリスナー・ポートの作業レコードが完了した (アプリケーションのトランザクションがコミットされたかどうかにかかわらず) という通知を受けるたびに、 1 ずつ減少します。 減少した後、処理中のカウントがこのリスナー・ポートの下限しきい値に照らし合わせて確認されます。 処理中のカウントが下限しきい値まで低下すると、以前にブロックされたキュー・エージェント・スレッドが喚起 (通知) されます。 その時点で、新規作業レコードを WLM キューに入れることができます。 これを、スロットルが「解放」されたといいます。

下限しきい値と上限しきい値は、リスナー・ポートの最大セッション数パラメーターという 1 つの設定で、 外部に設定されます。 上限しきい値は、内部では、外部で定義された最大セッション数と等しい値に設定されます。 下限しきい値は、内部では、次の公式によって計算および設定されます。 下限しきい値 = (上限しきい値 / 2) この場合、値は最も近い整数に切り捨てられます。

ただし、 メッセージ・リスナー・サービスがカスタム・プロパティー MDB.THROTTLE.THRESHOLD.LOW.EQUALS.HIGH (値は「true」に設定) を定義 して構成されている場合、下限しきい値は内部で上限しきい値 (外部で設定されたリスナー・ポートの最大セッション数プロパティー) に設定されます。

注: 以下の情報を考慮してください。ただし、内容はほとんどのユーザーに影響はありません。 キュー・エージェント・スレッドは、リスナー・ポートごとではなく、宛先ごとに確立されます。 したがって、2 つのリスナー・ポートが同じキューにマップされている場合、 1 つ目のリスナー・ポートでスロットルのブロック状態が発生すると、 2 つ目のリスナー・ポートの作業レコードのキューイングもブロックします。 2 つ目のリスナー・ポートは、上限しきい値に到達していない場合であってもブロックされます。 分かりやすくするために、複数のリスナー・ポート全体で宛先を共用しないことをお勧めします。

MDB スロットル - チューニングの考慮事項

リスナー・ポートの「最大セッション数」値を、 スケーラブル・サーバー内のすべてのサーバントで使用可能なワーカー・スレッド数の 2 倍に設定 (2*WT) する ことが推奨される理由を考慮してください。 理由は、いずれかのサーバントに使用可能なワーカー・スレッドがある場合、MDB スロットルがブロックされているた めに、それをアイドル状態のままにするのは望ましくないからです。 つまり、WLM キューが空で、サーバントのワーカー・スレッドが使用可能で、さらにスロットルがブロック状態にあるのは好 ましい状態ではありません。

基本として推奨される 2*WT 値を使用することにより、 次の条件が当てはまる場合にブロックしたスロットルが解放されます。
  • 空いているサーバント・ワーカー・スレッドが 1 つあります
  • WLM キューに何も入っていません
  • 1 つのメッセージ参照が参照されているが、 それに対する作業要求が WLM キューに追加されませんでした (代わりにスロットルがブロックされています)

さらに、上限しきい値を 2*(WT+N) に設定することにより、 サーバントのワーカー・スレッドが空いてスロットルを解放したときに、 前処理されてディスパッチ可能な状態で WLM キューに入っている N 個のメッセージのバックログが存在することが確実 になります。 値が非常に高いと、WLM キューの過負荷という問題が起きます。 スロットルではこの問題が回避されますが、ここでは、推奨される特定の上限はありません。 (これらのチューニング考慮事項では、 キュー (またはトピック) が処理されるメッセージとともに完全にロードされていることが前提となります。)

したがって、上限しきい値を上げると、 ワークロードが急上昇した場合に、サーバーが作成する、 WLM キューに入っている前処理されたメッセージのバックログが小さくなります。 上限しきい値を上げることの欠点、つまり否定的な側面は、 所定のメッセージとともにアプリケーションをディスパッチする前に、 所定のメッセージの作業レコードがタイムアウトする可能性が高くなることです。 (つまり、サーバーが MDB タイムアウトの限度に達する可能性があります。) 所定のメッセージは最終的にサーバーに再送信されますが、 それは後のことなので、その時点までの処理が無駄になる場合があります。 また、上限しきい値が非常に高いと、MDB スロットル機能が迂回されます。 この場合、WLM キューは過負荷になる可能性があり、これはサーバー障害の原因となります。

MDB スロットル - 代替チューニングの考慮事項

スケーラブル・サーバーは、スループットを最大化するという目標で設計されていますが、 リスナー・ポート設定を使用して、ワークフロー管理の目標を達成することができます。

例えば、上限しきい値の設定を「1」にすると、 宛先で受信される順序でメッセージが処理されることが保証されます。

特定のリスナー・ポートの並行性の制限を、サーバーがサポートするよりもはるかに少なくするための、容 量や他の要素に基づいた、その他のビジネス上の理由もあります。 この構成は確かにサポートされていますが、 使用可能なアイドル状態のワーカー・スレッドがある場合、スロットルがブロックする原因になることがあります。

MDB スロットルの例

サーバーが、最大サーバー・インスタンスの値が 3 に設定され、ワークロード・プロファイルが IOBOUND に設定されて、構成されているとします。 2 つの CPU があるので、WebSphere Application Server は各サーバント内に 6 つのワーカー・スレッドを作成します。 アプリケーション (キューにマップされた単一の MDB) は、 各メッセージを比較的高速に処理します (タイムアウトのリスクを減らすため)。 所定のメッセージが MDB キューに到着してから、このメッセージの MDB ディスパッチ終了までの合計時間をで きるだけ短くします。

作業が増加した場合に応答時間を短くするには、 バックログを大きくするようにします。 リスナー・ポートの最大セッション数の値を 100 = 2 * (3 * 6 + 32) に設定します。

注: 値が 36 = 2 * 3 * 6 以上になると、 すべての使用可能なサーバントのワーカー・スレッドが使用中になります。 実際には、恐らく、最良の「バックログの要素」を選ぶ価値はありません。 したがって、状況を考慮した上で推定し、概数が 100 となる値を選択します。



関連情報
z/OS での MDB 設定の概念および考慮事項
MDB スロットル
「コントローラー内で listen する」基本メッセージング・フロー
z/OS でのメッセージ駆動型 Bean の接続ファクトリー設定
z/OS でのメッセージ駆動型 Bean、異種ワークロード、およびワークロード管理
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:52:11 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cprf_tunezmdb_throttle.html