Hitachi

OpenTP1 Version 7 分散トランザクション処理機能 OpenTP1 運用と操作


3.2.7 スケジュールキューの滞留監視

クライアントからのサービス要求がサービス処理の段階で遅れ始めると,スケジュールキューからサービス要求を取り出せないため,スケジュールキューにサービス要求が滞留する場合があります。

このとき,スケジュールキューに滞留するサービス要求を一定の時間間隔でユーザサーバ単位に監視する機能を,スケジュールキューの滞留監視機能といいます。このスケジュールキューの滞留監視機能はユーザサーバ(SPP)だけで有効です。スケジュールキューにサービス要求が滞留する様子を次の図に示します。

図3‒3 スケジュールキューにサービス要求が滞留する様子

[図データ]

  1. 何らかの理由によってサービス要求の処理が遅れる。

  2. スケジュールキューからのサービス要求の取り出しが遅れる。

  3. サービス要求がスケジュールキューに滞留する。

スケジュールキューの滞留監視時にスケジュールキューに滞留しているサービス要求数が,システム定義のオペランドに指定した値を超えた場合は,KFCA00833-Wメッセージが出力されます。さらに,オペランドの指定によっては,そのあとKFCA00834-Eメッセージが出力されOpenTP1をシステムダウン(強制停止)させます。

〈この項の構成〉

(1) 指定するオペランド

スケジュールキューの滞留監視機能を使用するには,次に示すユーザサービス定義またはユーザサービスデフォルト定義のオペランドを指定します。個々のオペランドの詳細についてはマニュアル「OpenTP1 システム定義」を参照してください。

  1. stay_watch_queue_count

    スケジュールキューの滞留監視判定を開始する際の判断になるサービス要求滞留数を指定します。

  2. stay_watch_check_rate

    スケジュールキューの滞留監視判定で使用する,サーバが処理できるサービス要求の処理率を指定します。

  3. stay_watch_abort

    スケジュールキューの滞留監視判定式を満たした場合に,OpenTP1をシステムダウンさせるかどうかを指定します。

  4. stay_watch_start_interval

    スケジュールキューに滞留しているサービス要求数を監視するインタバル時間を指定します。

  5. stay_watch_check_interval

    スケジュール滞留監視判定式を基に判定処理を行うインタバル時間を指定します。

上記のオペランドを指定できるユーザサーバはSPPだけです。これらのオペランドをrapサーバ,MHPサーバに指定してもスケジュールキューの滞留監視機能は有効になりません。また,stay_watch_queue_countオペランドの指定を省略,またはstay_watch_queue_countオペランドに0を指定した場合,上記2.〜5.のオペランドの指定値は無効になるので注意してください。

(2) 処理の流れ

スケジュールキューの滞留監視の処理の流れを説明します。なお,ユーザサーバ(SPP)はすでに起動されている状態とします。

  1. stay_watch_start_intervalオペランドで指定した値を基に,一定の時間間隔でスケジュールキューの監視を開始します。

  2. スケジュールキューに滞留しているサービスの要求数がstay_watch_queue_countオペランドの指定値を超えた時点でスケジュールキューの滞留監視判定区間に入り,滞留監視判定が開始されます。

    スケジュールキューの滞留監視判定が開始されると,スケジュールキューの滞留監視判定式によってスケジュールキューの滞留状況が判定されます。

    スケジュールキューの滞留監視判定式

    [図データ]

    判定後の処理を次に示します。

    • スケジュールキューの滞留監視判定式が成立しない場合

      処理が続行されます。

    • スケジュールキューの滞留監視判定式が成立し,stay_watch_abortオペランドにNを指定している場合

      KFCA00833-Wメッセージが出力され,処理が続行されます。

    • スケジュールキューの滞留監視判定式が成立し,stay_watch_abortオペランドにYを指定している場合

      KFCA00833-Wメッセージ,およびKFCA00834-Eメッセージが出力され,OpenTP1をシステムダウンさせます。

  3. スケジュールキューの滞留監視判定処理はstay_watch_check_intervalオペランドで指定したインタバル時間で,ユーザサーバ単位の監視を行います。

    スケジュールキューに滞留しているサービスの要求数がstay_watch_queue_countオペランドで指定した値よりも少なくなった場合は,1.に戻ります。

(3) 処理の流れの例

ユーザサービス定義の各オペランドで次のように指定した場合のスケジュールキューの滞留監視機能の処理の例を説明します。

ユーザサービス定義

set stay_watch_queue_count=30(個)

set stay_watch_check_rate=70(%)

set stay_watch_abort=Y

set stay_watch_start_interval=5(秒)

set stay_watch_check_interval=10(秒)

図3‒4 スケジュールキューの滞留監視機能の処理の例

[図データ]

stay_watch_queue_count=30と指定しているため,この図のC2からC5の区間およびC8以降の区間で,スケジュールキューの滞留監視判定が行われます。スケジュールキューの滞留監視判定区間では,stay_watch_check_intervalオペランドの指定値の間隔による監視が行われます。この一定時間間隔の監視で,サービス要求の処理件数とサービス要求の処理率を基にスケジュールキューの滞留監視判定式による判定が行われます。

スケジュールキューの滞留監視判定式

[図データ]

図3-4の例を判定式で表すと次のようになります。

Pn-1 - Bn < m1 × Pn-1
(凡例)

n:0または正の整数

Pn-1 - Bn:該当区間のサービス要求の処理件数

m1:サービス要求の処理率(set stay_watch_check_rateオペランドの指定値)

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:0または正の整数を示します。

−:該当しません。

上記の表でn=1またはn=7の場合,スケジュールキューの滞留監視判定式が成立しますが,スケジュールキューの滞留監視判定中ではないため,OpenTP1システムはダウンしません。また,n=2またはn=8の場合,スケジュールキューの滞留監視判定の開始時であるため,OpenTP1システムはダウンしません。

n=9の場合は,スケジュールキューの滞留監視判定中で,スケジュールキューの滞留監視判定式が成立し,かつstay_watch_abort=Yであるため,OpenTP1をシステムダウンさせます。