1.3.6　ユーザサーバの負荷分散とスケジュール

(1)　マルチサーバ

実行中のユーザサーバに対して，さらにサービス要求が来た場合でも，ユーザサーバの処理を新しい別のプロセスで実行できます。このように，一つのユーザサーバの処理を，別のプロセスで並行して実行する機能をマルチサーバといいます。

マルチサーバを使えるのは，スケジュールキューを使うSPP（キュー受信型サーバ）です。ソケット受信型サーバの場合はマルチサーバを使えません。ソケット受信型サーバには，使うプロセスは一つだけと指定してください。

ページの先頭へ

(2)　常駐プロセスと非常駐プロセス

マルチサーバを指定したUAPのプロセスを，OpenTP1の稼働中にいつも確保しておくことも，動的に確保することもできます。いつも確保されているプロセスを常駐プロセスといいます。また，稼働中には確保されていなくて，必要に応じて起動されるプロセスを非常駐プロセスといいます。

プロセスを非常駐プロセスと設定しておくと，OpenTP1システム内のメモリ領域を効率良く使えます。また，プロセスを常駐プロセスと設定しておくと，そのユーザサーバの処理は非常駐プロセスに比べて速くなります。

システムのメモリに空きがない場合，非常駐プロセスは稼働中の非常駐プロセスが終了してから実行されます。

非常駐プロセスを使用すると，一時的^※に最大でユーザサービス定義のparallel_countオペランドの指定値の2倍のプロセス数が起動されることがあります。

注※

終了しようとしているプロセスが，dc_rpc_mainloop関数またはdc_mcf_mainloop関数の終了後からdc_rpc_close関数終了までの区間にある場合で，新たなサービス要求を受け付けたタイミングです。

また，非常駐プロセスであってもプロセス起動による性能への影響を最小限にとどめるため，同一プロセスで続けてサービス要求を処理する場合があります。そのため，ユーザサーバはリエントラントできるプログラム構造で作成する必要があります。

ページの先頭へ

(3)　プロセスの設定方法

プロセスを常駐とするか非常駐とするかは，ユーザサーバの起動プロセス数で，事前に設定しておきます。設定したプロセスの数だけ，並行にプロセスを起動できます。設定する方法を次に示します。

• TP1/Server Baseの場合

  ユーザサービス定義のparallel_countオペランドで，使うプロセスの合計（常駐プロセス数と非常駐プロセス数）を設定します。

• TP1/LiNKの場合

  UAPの実行環境を設定するときに，使うプロセスの数（常駐プロセス数と非常駐プロセス数）を設定します。

常駐プロセスを複数個指定していれば，指定した数だけ並行してプロセスが起動されます。また，非常駐プロセスを複数個指定していれば，指定した数だけ動的にプロセスが起動されます。

ページの先頭へ

(4)　マルチサーバ負荷バランス

スケジュールキューにあるサービスの要求数に応じて，非常駐プロセスの数を増やしたり減らしたりする機能をマルチサーバ負荷バランス機能といいます。

非常駐プロセスをいつ起動するかは，ユーザサービス定義のbalance_countオペランドに指定する値で決まります。（balance_countオペランドに指定した値×起動中のプロセス）の数を超えてサービス要求が滞留したときに，OpenTP1は非常駐プロセスを起動します。スケジュールキューに滞留しているサービス要求の数が0になると，OpenTP1は非常駐プロセスを終了させます。

非常駐プロセスを起動するタイミングの値を指定する方法を次に示します。

• TP1/Server Baseの場合

  ユーザサービス定義のbalance_countオペランドに設定します。

• TP1/LiNKの場合

  UAPの実行環境を設定するときのサービスの最大滞留数が，上記のbalance_countオペランドの値になります。

ページの先頭へ

(5)　非常駐UAPプロセスのリフレッシュ機能

非常駐プロセスを使用する場合，一つのサービス要求ごとに実行プロセスを起動し直すことができます。この機能を，非常駐UAPプロセスのリフレッシュ機能といいます。この機能を使用することで，リエントラント構造ではないUAPの実行もできるようになります。

この機能を使用するためには，ユーザサービス定義またはユーザサービスデフォルト定義に，scd_refresh_processオペランドを指定します。また，この機能は1プロセスが処理するサービス要求数（ユーザサービス定義のbalance_countオペランドの指定値）が0の場合にだけ使用できます。

非常駐UAPプロセスのリフレッシュ機能を使用しない場合と使用する場合の動作，およびこの機能を使用する場合の注意事項について説明します。

ページの先頭へ

(6)　スケジュールの優先度

一つ一つのユーザサーバには，スケジュールの優先度（スケジュールプライオリティ）を付けられます。優先度が高いユーザサーバの非常駐プロセスは，ほかの非常駐プロセスに比べて優先的にスケジュールされます。

スケジュールの優先度は，ユーザサーバで使うプロセスを設定するときに，一緒に設定します。

プロセスの負荷分散を次の図に示します。

図1‒26　プロセスの負荷分散

ページの先頭へ

(7)　ノード間負荷バランス機能

同じサービスグループ名のユーザサーバを複数のノードに配置しておくと，サービスを要求されたときに，どのノードのユーザサーバでも処理できます。これによって，ノード間で負荷分散できます。これをノード間負荷バランス機能といいます。ノード間負荷バランス機能を使うための環境設定は必要ありません。複数のノードで同じサービスグループ名のユーザサーバを開始しておけば，OpenTP1で自動的に振り分けます。

OpenTP1システム内の同一サービスグループに，マルチスケジューラ機能を使用しているユーザサーバと，マルチスケジューラ機能を使用していないユーザサーバが混在する場合，マルチスケジューラ機能を使用しているユーザサーバが高負荷状態でも，マルチスケジューラ機能を使用していないユーザサーバには負荷分散されません。マルチスケジューラ機能を使用していないユーザサーバに負荷分散するには，スケジュールサービス定義のscdmulti定義コマンドに-tオプションを指定してください。scdmulti定義コマンドの詳細については，マニュアル「OpenTP1 システム定義」のスケジュールサービス定義を参照してください。

ノード間負荷バランス機能で負荷を分散できるノードの数は，最大128です。

ノード間負荷バランス機能では，ノードのスケジュール状態に応じて，より効率的に処理できるノードへ負荷を分散させます。ノード間負荷バランス機能の環境で，サービスを要求したUAPと同じノードにあるユーザサーバを優先的にスケジュールしたい場合には，そのノードのスケジュールサービス定義にscd_this_node_firstオペランドにYを指定しておいてください。

ノード間負荷バランス機能の概要を次の図に示します。

図1‒27　ノード間負荷バランス機能の概要

ページの先頭へ

(8)　ノード間負荷バランス拡張機能

ユーザは次に示す指定ができます。

• LEVEL0のノードへのスケジュール比率の指定

  スケジュールサービス定義のschedule_rateオペランドを指定することによって，負荷レベルがLEVEL0のノードにスケジュールする比率（%）を指定できます。

• 負荷監視インターバル時間の指定

  ユーザサービス定義およびユーザサービスデフォルト定義のloadcheck_intervalオペランドを指定することによって，サービスグループごとに負荷監視インターバル時間を指定できます。

• 負荷レベルのしきい値の指定

  ユーザサービス定義およびユーザサービスデフォルト定義のlevelup_queue_countオペランドおよびleveldown_queue_countオペランドを指定することによって，サービスグループごとにサービス要求滞留数によって負荷レベルを決定するしきい値を指定できます。

• 通信障害時のリトライ回数の指定

  通常，サービス要求のスケジューリング時に通信障害が発生すると，再スケジュールしないでエラーリターンします。スケジュールサービス定義のscd_retry_of_comm_errorオペランドを指定することによって，通信障害が発生したノード以外へスケジュールするリトライ回数を指定できます。

  なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

ページの先頭へ

(9)　マルチスケジューラ機能

クライアントUAPから，他ノードのキュー受信型サーバ（スケジュールキューを使うSPP）にサービスを要求した場合，要求先サーバが存在するノードのスケジューラデーモンが，いったんサービス要求メッセージを受信し，該当するキュー受信型サーバのスケジュールキューに格納します。スケジューラデーモンは，スケジュールサービスを提供するシステムデーモンのことです。

スケジューラデーモンは，OpenTP1システムごとに1プロセスです。そのため，システムの大規模化，マシンやネットワークの高性能化などに伴って，従来のスケジューラデーモンだけでは効率良くスケジューリングできないことがあります。従来のスケジューラデーモンだけでは効率良くスケジューリングできない場合については，「付録C　マルチスケジューラ機能の検討が必要なシステム構成例」を参照してください。

従来のスケジューラデーモン（これ以降マスタスケジューラデーモンといいます）とは別に，サービス要求受信専用デーモン（これ以降マルチスケジューラデーモンといいます）を複数プロセス起動し，サービス要求メッセージ受信処理を並行動作させることによって，受信処理の競合によるスケジューリング遅延を回避できます。この機能をマルチスケジューラ機能といいます。

なお，この機能は，TP1/Extension 1をインストールしていることが前提です。TP1/Extension 1をインストールしていない場合の動作は保証できませんので，ご了承ください。

マルチスケジューラ機能を使用するには，次の定義を指定する必要があります。

RPC受信側

スケジュールサービス定義　scdmulti

ユーザサービス定義　scdmulti

RPC送信側

ユーザサービス定義　multi_schedule

また，幾つかのマルチスケジューラデーモンをキュー受信型サーバごとにグループ化できます。これによって，異なるサーバ間でサービス要求メッセージの受信処理が競合するのを回避できます。マルチスケジューラデーモンをグループ化して使用する場合，サーバ側でユーザサービス定義 scdmultiに-gオプションを指定する必要があります。

OpenTP1起動時に，スケジュールサービスを提供するシステムデーモンとして，マスタスケジューラデーモンに加え，定義に指定したマルチスケジューラデーモンをウェルノウンポート番号で起動します。なお，TP1/Clientからマルチスケジューラ機能を使用してサービスを要求する場合については，マニュアル「OpenTP1 クライアント使用の手引 TP1/Client/W，TP1/Client/P編」を参照してください。

マルチスケジューラ機能を使用したRPCについては「2.1.16　マルチスケジューラ機能を使用したRPC」を参照してください。

マルチスケジューラ機能の使用例を次の図に示します。

図1‒28　マルチスケジューラ機能の使用例

• SPP1は，短いサービス要求メッセージを扱うため，マルチスケジューラ機能を使用しないで，マスタスケジューラデーモンにスケジューリングさせます（図の1.）。

• SPP2は，長大サービス要求メッセージを扱うため，OpenTP1のノード1とノード2に分散させ，ノード1にあるグループ1のマルチスケジューラデーモン1，またはノード2にあるグループ1のマルチスケジューラデーモン1，2にスケジューリングさせます（図の2.）。

• SPP3は，短いサービス要求メッセージを扱いますが，サービス要求数が多いため，OpenTP1のノード1とノード2に分散させ，ノード1にあるグループ2のマルチスケジューラデーモン2，3，またはノード2にあるグループ2のマルチスケジューラデーモン3にスケジューリングさせます（図の3.）。

ページの先頭へ