![[z/OS]](../images/ngzos.gif)
z/OS でのメッセージ駆動型 Bean の MDB スロットル設定
「MDB スロットル」のさまざまな設定を調整して、 サーバーが所定時刻に処理する MDB 作業の量を制御することができます。
MDB スロットル - しきい値の上限と下限
MDB スロットル・サポートは、各リスナー・ポートの現在処理されているメッセージ数のカウントを維持します。
- 処理中のカウントが上限しきい値以下である場合、作業レコードは WLM キューに入れられます。
- 処理中のカウントが上限しきい値を超えると、MRH を実行しているキュー・エージェント・スレッドがブロックされ、待ち状態に入ります。すなわち、スロットルは「ブロッキング」しています。
処理中のカウントは、(アプリケーション・トランザクションがコミットされたかどうかにかかわらず) コントローラーが、このリスナー・ポートの作業レコードが完了したという通知を受けるたびに、1 ずつ減少します。 減少した後、処理中のカウントがこのリスナー・ポートの下限しきい値に照らし合わせて確認されます。 処理中のカウントが下限しきい値まで低下すると、以前にブロックされたキュー・エージェント・スレッドが喚起 (通知) されます。 その時点で、新規の作業レコードを WLM キューに入れることができます。 すなわち、スロットルは「解放」されました。
下限しきい値と上限しきい値は、リスナー・ポートの最大セッション数パラメーターという 1 つの設定で、外部で設定されます。 上限しきい値は、内部では、外部で定義された最大セッション数と等しい値に設定されます。 下限しきい値は、内部では、次の公式によって計算および設定されます。 下限しきい値 = (上限しきい値 / 2) この場合、値は最も近い整数に切り捨てられます。
- コントローラーが別のメッセージの処理を開始します。 処理中のカウントが 3 に設定され、上限しきい値を超えるため、下限しきい値に達するまでコントローラーのスレッドは休止します。
- 最初のメッセージのサーバントの MDB が戻り、処理中のカウントが 3 から 2 に減りますが、下限しきい値には達していません。
- 2 番目のメッセージのサーバントの MDB が戻り、処理中のカウントが 2 から 1 に減ります。 下限しきい値に達したため、メッセージの処理と SR へのディスパッチが続行します。
ただし、メッセージ・リスナー・サービスがカスタム・プロパティー MDB.THROTTLE.THRESHOLD.LOW.EQUALS.HIGH (値は「true」に設定) を定義 して構成されている場合、下限しきい値は内部で上限しきい値 (外部で設定されたリスナー・ポートの最大セッション数プロパティー) に設定されます。
MDB スロットル - チューニング
リスナー・ポートの"「最大セッション数」"値を、スケーラブル・サーバー内のすべてのサーバントで使用可能なワーカー・スレッド数の 2 倍に設定 (2*WT) してください。こうすると、一部のサーバントで使用可能なワーカー・スレッドがあった場合に、MDB スロットルがブロックされているために、そのスレッドがアイドルのままになるという状態が避けられます。 つまり、WLM キューが空で、サーバントのワーカー・スレッドが使用可能で、さらにスロットルがブロック状態にあるのは好 ましい状態ではありません。
- 空いているサーバント・ワーカー・スレッドが 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) に設定します。