クライアントからのサービス要求がサービス処理の段階で遅れ始めると,スケジュールキューからサービス要求を取り出せないため,スケジュールキューにサービス要求が滞留する場合があります。
このとき,スケジュールキューに滞留するサービス要求を一定の時間間隔でユーザサーバ単位に監視する機能を,スケジュールキューの滞留監視機能といいます。このスケジュールキューの滞留監視機能はユーザサーバ(SPP)だけで有効です。スケジュールキューにサービス要求が滞留する様子を次の図に示します。
図3-3 スケジュールキューにサービス要求が滞留する様子
スケジュールキューの滞留監視時にスケジュールキューに滞留しているサービス要求数が,システム定義のオペランドに指定した値を超えた場合は,KFCA00833-Wメッセージが出力されます。さらに,オペランドの指定によっては,そのあとKFCA00834-Eメッセージが出力されOpenTP1をシステムダウン(強制停止)させます。
スケジュールキューの滞留監視機能を使用するには,次に示すユーザサービス定義またはユーザサービスデフォルト定義のオペランドを指定します。個々のオペランドの詳細についてはマニュアル「OpenTP1 システム定義」を参照してください。
上記のオペランドを指定できるユーザサーバはSPPだけです。これらのオペランドをrapサーバ,MHPサーバに指定してもスケジュールキューの滞留監視機能は有効になりません。また,stay_watch_queue_countオペランドの指定を省略,またはstay_watch_queue_countオペランドに0を指定した場合,上記2.~5.のオペランドの指定値は無効になるので注意してください。
スケジュールキューの滞留監視の処理の流れを説明します。なお,ユーザサーバ(SPP)はすでに起動されている状態とします。
ユーザサービス定義の各オペランドで次のように指定した場合のスケジュールキューの滞留監視機能の処理の例を説明します。
図3-4 スケジュールキューの滞留監視機能の処理の例
stay_watch_queue_count=30と指定しているため,図3-4でC2からC5の区間およびC8以降の区間で,スケジュールキューの滞留監視判定が行われます。スケジュールキューの滞留監視判定区間では,stay_watch_check_intervalオペランドの指定値の間隔による監視が行われます。この一定時間間隔の監視で,サービス要求の処理件数とサービス要求の処理率を基にスケジュールキューの滞留監視判定式による判定が行われます。
Pn-1 - Bn < m1 × Pn-1
次の表は,図3-4でのサービス要求の処理件数,およびスケジュールキューの滞留監視判定式の判定結果をまとめたものです。
n | サービス要求の処理件数 (Pn-1 - Bn) | 期待するサービス要求の処理件数 (m1×Pn-1) | スケジュールキューの滞留監視判定式の判定結果 (Pn-1-Bn<m1×Pn-1) |
---|---|---|---|
0 | - | - | 滞留監視判定の対象外 |
1 | 18-9=9 | 0.7×18=12.6 | 滞留監視判定の対象外 |
2 | 28-25=3 | 0.7×28=19.2 | 滞留監視判定の開始 |
3 | 32-8=24 | 0.7×32=22.4 | OpenTP1オンライン続行 |
4 | 45-13=32 | 0.7×45=31.5 | OpenTP1オンライン続行 |
5 | 35-0=35 | 0.7×35=24.5 | OpenTP1オンライン続行 |
6 | 30-3=27 | 0.7×30=21 | 滞留監視判定の対象外 |
7 | 11-5=6 | 0.7×11=7.7 | 滞留監視判定の対象外 |
8 | 17-15=2 | 0.7×17=11.9 | 滞留監視判定の開始 |
9 | 32-29=3 | 0.7×32=22.4 | OpenTP1システムダウン |
上記の表でn=1またはn=7の場合,スケジュールキューの滞留監視判定式が成立しますが,スケジュールキューの滞留監視判定中ではないため,OpenTP1システムはダウンしません。また,n=2またはn=8の場合,スケジュールキューの滞留監視判定の開始時であるため,OpenTP1システムはダウンしません。
n=9の場合は,スケジュールキューの滞留監視判定中で,スケジュールキューの滞留監視判定式が成立し,かつstay_watch_abort=Yであるため,OpenTP1をシステムダウンさせます。