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

UAP(ユーザサーバ)を効率良く使うための機能(マルチサーバ)とUAPのスケジュール方法について説明します。

OpenTP1のシステムサービス,またはユーザサーバを実行するときには,OSの作業領域を使用します。この作業領域の処理をプロセスといいます。ユーザサーバを実行して生成されるプロセスを特にユーザサーバプロセスUAPプロセス,または単にプロセスといいます。OpenTP1では,プロセスが必要以上に増えたり減ったりしないように,使うプロセスの総数を制御しています。

ユーザサーバのプロセスを制御するには,ユーザサーバを事前に開始していることが前提です。OpenTP1と一緒に開始させておくか,dcsvstart -uコマンドで開始させておきます。

<この項の構成>
(1) マルチサーバ
(2) 常駐プロセスと非常駐プロセス
(3) プロセスの設定方法
(4) マルチサーバ負荷バランス
(5) 非常駐UAPプロセスのリフレッシュ機能
(6) スケジュールの優先度
(7) ノード間負荷バランス機能
(8) ノード間負荷バランス拡張機能
(9) マルチスケジューラ機能

(1) マルチサーバ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(a) 非常駐UAPプロセスのリフレッシュ機能を使用しない場合の動作

非常駐UAPプロセスのリフレッシュ機能を使用しない場合の動作を,次の図に示します。図中の番号と以降の説明の番号は対応しています。

図1-24 非常駐UAPプロセスのリフレッシュ機能を使用しない場合の動作

[図データ]

  1. SPPまたはMHPのスケジュールキューにサービス要求が登録されたため,プロセスIDが10のSPPまたはMHPプロセスを起動します。また,一つ目のサービス要求について,サービス関数を実行します。
  2. サービス関数の実行後,SPPまたはMHPのスケジュールキューにサービス要求がある場合は,そのプロセス上で再度サービス関数を実行します。
    以降,スケジュールキューからサービス要求がなくなるまで,処理を繰り返します。
  3. SPPまたはMHPのスケジュールキューにサービス要求がなくなったので,プロセスが終了となります。
(b) 非常駐UAPプロセスのリフレッシュ機能を使用する場合の動作

非常駐UAPプロセスのリフレッシュ機能を使用する場合の動作を,次の図に示します。図中の番号と以降の説明の番号は対応しています。

図1-25 非常駐UAPプロセスのリフレッシュ機能を使用する場合の動作

[図データ]

  1. SPPまたはMHPのスケジュールキューにサービス要求が登録されたため,プロセスIDが10のSPPまたはMHPプロセスを起動します。また,一つ目のサービス要求についてサービス関数を実行したあと,プロセス起動処理を実行して自プロセスは終了します。
  2. プロセスIDが10のSPPまたはMHPで実行したプロセス起動処理によって,prcdはプロセスIDが20のSPPまたはMHPプロセスを起動します。また,二つ目のサービス要求についてサービス関数を実行したあと,プロセス起動処理を実行して自プロセスは終了します。
  3. プロセスIDが20のSPPまたはMHPで実行したプロセス起動処理によって,prcdはプロセスIDが30のSPPまたはMHPプロセスを起動します。また,三つ目のサービス要求についてサービス関数を実行したあと,プロセス起動処理を実行して自プロセスは終了します。
    以降,スケジュールキューからサービス要求がなくなるまで,処理を繰り返します。
(c) 非常駐UAPプロセスのリフレッシュ機能使用時の注意事項

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

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

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

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

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

[図データ]

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

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

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

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

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

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

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

[図データ]

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

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

(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 マルチスケジューラ機能の使用例

[図データ]