JP2017059030A - 情報処理装置及び情報処理装置の制御方法 - Google Patents

Abstract

【課題】主機能部と従機能部とで構成される情報処理装置において、従機能部の輻輳による性能の低下を抑制する技術を提供する。【解決手段】情報処理装置は、処理メッセージの送信を制御する第１の主機能部と、処理メッセージを解析して解析の結果を第１の主機能部に通知する第２の主機能部と、処理メッセージを第１の主機能部から受信して処理するリソースを含む従機能部群とを備える。第２の主機能部は、第１の主機能部からリソースへ送信される処理メッセージの推定処理時間をリソースごとに累計した推定累計走行時間値に基づいてリソースの負荷量をリソースごとに判定し、負荷量の判定結果に基づいて、リソースにおける輻輳の程度を示す輻輳度を、リソースごとに判定し、輻輳度の判定結果を輻輳度通知として第１の主機能部に通知する。第１の主機能部は、輻輳度通知に含まれる輻輳度の判定結果に基づいて、対応するリソース宛の処理メッセージを処理する。【選択図】図１

Description

本発明は、情報処理装置の輻輳状態を制御する機能を備える情報処理装置及び情報処理装置の制御方法に関する。

ネットワークトラヒックの増加に伴い、ネットワークに接続された情報処理装置に求められる処理能力も増大している。さらに、情報処理装置の処理能力を上回るトラヒックによる通信障害の発生を抑制するために、情報処理装置には輻輳制御機能も必要とされる。

本発明に関連して、特許文献１には、主機能部と従機能部とを備える情報処理装置において、主機能部の処理の輻輳の程度（以下、輻輳の程度を「輻輳度」という。）が非輻輳状態と輻輳状態とのいずれにあるかを判断する機能を備える輻輳制御システムが記載されている。特許文献１に記載された技術は、主機能部が輻輳状態にあると判断された場合には、従機能部から受信された重要度が低い処理メッセージが破棄される。また、特許文献２には、サーバのリソース管理機能を備えたマシン管理システムが記載されている。

特開２００９−２１２８６２号公報 特開２０１４−２２９２５３号公報

特許文献１に記載された情報処理装置において、従機能部の負荷が増大して輻輳度が高まると、従機能部が主機能部から受信した処理メッセージの処理に時間を要するようになる。そして、従機能部あるいは情報処理装置全体の機能が低下あるいは停止してしまう恐れがある。

例えば、従機能部が優先度が異なる複数のタスクＡ、Ｂを含むマルチタスク処理を実行する場合に、処理中であるタスクＢよりも優先度が高いタスクＡが新たに多数発生すると、タスクＡの処理が終了するまでタスクＢの処理が待たされる。すなわち、負荷の増大により、従機能部における優先度の低いタスクの処理が遅延する。

主機能部が処理メッセージを複数の従機能部に分散して配信することにより個々の従機能部の負荷はある程度軽減される。しかし、情報処理装置全体の負荷の上昇とともに１つの従機能部あたりのプロセッサ処理時間の累計値も増大するため、稼働中のタスクの数も増加し、タスクの処理に要する時間も増大する。

このような背景から、主機能部と従機能部とにより構成される情報処理装置において、従機能部における負荷制御を行い、従機能部の輻輳による情報処理装置の性能の低下を抑制するための技術が必要とされている。しかし、特許文献１、２には、従機能部の輻輳を抑制するための技術に関しては記載されていない。

（発明の目的）
本発明は、主機能部と従機能部とで構成される情報処理装置において、従機能部の輻輳による情報処理装置の性能の低下を抑制することが可能な技術を提供することを目的とする。

本発明の情報処理装置は、処理メッセージの送信を制御する第１の主機能部と、処理メッセージを解析して解析の結果を第１の主機能部に通知する、第１の主機能部に併設され第１の主機能部と通信可能な第２の主機能部と、第１及び第２の主機能部と通信可能に接続され、処理メッセージを第１の主機能部から受信して処理するリソースを含む従機能部群と、を備え、第２の主機能部は、第１の主機能部からリソースへ送信される処理メッセージの推定処理時間をリソースごとに累計した推定累計走行時間値に基づいてリソースの負荷量をリソースごとに判定し、負荷量の判定結果に基づいて、リソースにおける輻輳の程度を示す輻輳度を、第１の状態、第１の状態よりも輻輳度が高い第２の状態、及び、第２の状態よりも輻輳度が高い第３の状態のいずれかとしてリソースごとに判定し、輻輳度の判定結果を輻輳度通知として第１の主機能部に通知し、第１の主機能部は、輻輳度通知に含まれる輻輳度の判定結果に基づいて、対応するリソース宛の処理メッセージを処理する。

本発明の情報処理装置の制御方法は、第１の主機能部からリソースへ送信される処理メッセージの推定処理時間をリソースごとに累計した推定累計走行時間値に基づいて、リソースの負荷量をリソースごとに判定し、負荷量に基づいて、リソースにおける輻輳の程度を示す輻輳度を、第１の状態、第１の状態よりも輻輳度が高い第２の状態、及び、第２の状態よりも輻輳度が高い第３の状態のいずれかとしてリソースごとに判定し、輻輳度の判定結果を輻輳度通知として通知し、輻輳度通知に含まれる輻輳度の判定結果に基づいて、対応するリソース宛の処理メッセージを処理する、ことを特徴とする。

本発明の情報処理装置の制御プログラムは、情報処理装置が備えるコンピュータに、第１の主機能部からリソースへ送信される処理メッセージの推定処理時間をリソースごとに累計した推定累計走行時間値に基づいて、リソースの負荷量をリソースごとに判定する手順、負荷量に基づいて、リソースにおける輻輳の程度を示す輻輳度を、第１の状態、第１の状態よりも輻輳度が高い第２の状態、及び、第２の状態よりも輻輳度が高い第３の状態のいずれかとしてリソースごとに判定する手順、輻輳度の判定結果を輻輳度通知として通知する手順、輻輳度通知に含まれる輻輳度の判定結果に基づいて、対応するリソース宛の処理メッセージを処理する手順、を実行させる。

本発明は、主機能部と従機能部とで構成される情報処理装置において、従機能部の輻輳による情報処理装置の性能の低下を抑制することを可能とする。

第１の実施形態の情報処理装置の構成例を示すブロック図である。 輻輳度の判定基準の例を示す図である。 予備主機能部におけるリソースの輻輳度の通知処理の例を示すフローチャートである。 現用主機能部における輻輳保護処理の例を示すフローチャートである。 現用主機能部のリソースの再割り当て手順の例を示すフローチャートである。

（第１の実施形態）
本発明の第１の実施形態について説明する。図１は、第１の実施形態の情報処理装置１０の構成例を示すブロック図である。情報処理装置１０は、主機能部１１及び従機能部群１２〜１４を備える。主機能部１１は、現用主機能部１１−１及び予備主機能部１１−２を備える。情報処理装置１０の機能は、情報処理装置１０に備えられたＣＰＵ（Central Processing Unit、中央処理装置）がプログラムを実行することにより主機能部１１及び従機能部群１２〜１４を含む情報処理装置１０全体を制御することによって実現することができる。プログラムは、例えば、情報処理装置１０が備える半導体メモリや固定磁気ディスク等の記憶部に記録される。

主機能部１１は、情報処理装置１０内における処理の命令やデータのアドレス等を示す処理メッセージを受信し、受信した処理メッセージを処理する。現用主機能部１１−１は、従機能部群１２〜１４に含まれるリソースから受信した処理メッセージに基づいて、情報処理装置１０の機能を実現する。また、現用主機能部１１−１は、従機能部群１２〜１４のリソースに処理メッセージを送信するとともに、従機能部群１２〜１４に対して、リソース単位で機能の割り当て（例えば、処理メッセージの処理の分担）を決定する。従機能部群１２〜１４は、ＣＰＵの周辺装置で生成される処理メッセージやＣＰＵにおけるプログラムの実行に伴い従機能部群１２〜１４において生じる処理メッセージを主機能部１１に対して送信する。

予備主機能部１１−２は、従機能部群１２〜１４の処理状態を監視する。予備主機能部１１−２は、さらに、現用主機能部１１−１の処理状態を監視する機能を備えてもよい。予備主機能部１１−２は、同一ＣＰＵ内で現用主機能部１１−１の周辺機能部として機能する。現用主機能部１１−１と予備主機能部１１−２とは現用−予備構成を備えることもできる。現用−予備構成では、予備主機能部１１−２は、現用主機能部１１−１が正常に動作している間は現用主機能部１１−１の機能に関しては待機状態にある。そして、現用主機能部１１−１の障害時には、予備主機能部１１−２は現用主機能部１１−１の機能の一部又は全部を代替できる。

図１に示すように、従機能部群１２は、１つ以上のリソース１２−１〜１２−ｎを備える。リソースは、従機能部群１２〜１４の機能を実現するための従機能部を構成する要素である。１個以上のリソースが、各従機能部群を構成する。従機能部群１２〜１４と主機能部との間の通信は、より具体的には、従機能部群１２〜１４が備える各リソースと主機能部との間の通信である。図１では従機能部群１２のリソースとして１２−１〜１２−ｎのｎ個（ｎは自然数）のリソースが例示される。従機能部群１２以外の従機能部群も、同様に１個以上のリソースを備える。従機能部群１２〜１４が備えるリソースの数は同一でなくともよい。また、従機能部群１２〜１４の数は３個に限定されない。

現用主機能部１１−１、予備主機能部１１−２及び従機能部群１２〜１４の各リソースの間の通信線は、ワイヤードオアにより、もしくはスイッチを介して接続される。このため、現用主機能部１１−１及び予備主機能部１１−２は、各リソースと相互に通信が可能である。

（現用主機能部の説明）
情報処理装置１０の各部についてさらに詳細に説明する。現用主機能部１１−１は、従機能部群１２〜１４のリソースから処理メッセージを受信する機能、受信した処理メッセージを処理する機能、処理メッセージの送信先のリソースを特定して必要なリソースに処理メッセージを返信する機能、を備える。現用主機能部１１−１は、さらに、予備主機能部１１−２から通知された輻輳度通知に基づいてリソースごとの輻輳度（輻輳の程度）に応じた処理を実行する機能、リソースごとの輻輳度に基づいてリソースの割り当てを管理する機能、を備える。

現用主機能部１１−１は、各リソースから受信した処理メッセージに基づいて、図示されない外部装置へ応答メッセージを送信してもよい。また、現用主機能部１１−１は、外部装置から受信したメッセージに基づいて、各リソースへ送信する処理メッセージを生成してもよい。外部装置は、例えばディスプレイ装置やキーボード等の入出力装置である。

（予備主機能部の説明）
予備主機能部１１−２は、現用主機能部１１−１から受信した処理メッセージを解析する機能、この解析結果に基づいて現用主機能部１１−１から各リソースへ通知された処理メッセージの種別（メッセージ種別）をリソース毎に特定する機能、を備える。予備主機能部１１−２は、上記の機能の実行結果に基づいて、通知された処理メッセージのうち、受信メッセージとしてカウントするメッセージと、カウントしないメッセージとを選別する機能を有していてもよい。

予備主機能部１１−２は、さらに、特定されたメッセージ種別に基づきリソースの負荷量（テンポラリ負荷量）を算出し、テンポラリ負荷量に基づいてリソースの輻輳度を判定する機能を備える。

予備主機能部１１−２は、現用主機能部１１−１から通知された処理メッセージに関する、推定走行時間テーブルを備える。推定走行時間テーブルは、情報処理装置１０において使用される処理メッセージのメッセージ種別と、各リソースにおいてＣＰＵが当該種別の処理メッセージの実行処理にかかる時間の推定値（以下「走行時間」という。）とが対応付けられたリストである。これにより、予備主機能部１１−２は、各リソースの処理メッセージに対する処理時間を、走行時間として迅速に取得することができる。

予備主機能部１１−２は、周期タイマと受信カウンタを備える。周期タイマは、各リソースが処理メッセージに対して行う処理の周期を、予め設定された測定周期に基づきリソースごとに計測する。受信カウンタは、現用主機能部１１−１がリソースに送信した処理メッセージの数をリソースごとにカウントする。これにより、上記測定周期内のリソースごとの走行時間を推定できる。

予備主機能部１１−２は、処理メッセージの種別をリソース毎に特定する機能により特定されたメッセージ種別に対応した走行時間を、推定走行時間テーブルを参照して読み出す。そして、予備主機能部１１−２は、読み出された走行時間を、上記測定周期内で加算して、リソースごとに推定走行時間累計値を算出する。さらに、予備主機能部１１−２は、累計カウンタを備える。累計カウンタは、推定走行時間累計値に走行時間が加算された処理メッセージの数をカウントする。

予備主機能部１１−２は、走行時間を推定走行時間累計値に対して加算するごとに累計カウンタの数値を１増やし、累計カウンタと受信カウンタの数を比較する。受信カウンタの値と累計カウンタの値が等しいか否かを判定することにより、受信カウンタにカウントされた処理メッセージ全てについてリソースごとの走行時間が算出され、それらの走行時間が累計カウンタに加算されたか否かを判定できる。

予備主機能部１１−２は、上記の手順で算出された走行時間累計値に基づいて、上記の測定周期内でリソースにかかると推定される負荷量（以下「テンポラリ負荷量」という。）をリソースごとに算出する。そして、予備主機能部１１−２は、算出されたテンポラリ負荷量に基づき、従機能部における処理負荷が、低負荷、中負荷、又は高負荷の何れの状況であるかを判定する。リソースが低負荷、中負荷、及び高負荷のいずれであるかの判定は、推定走行時間累計値を相異なる２つの閾値Ｐ、Ｑ（０＜Ｐ＜Ｑ）と比較し、比較結果に基づいてテンポラリ負荷量を３段階に区分することで判定されてもよい。例えば、推定走行時間累計値＜Ｐであればリソースは低負荷と判定される。Ｐ≦推定走行時間累計値≦Ｑであればリソースは中負荷と判定される。Ｑ＜推定走行時間累計値であればリソースは高負荷と判定される。

（輻輳度の判定手順の説明）
予備主機能部１１−２は、テンポラリ負荷量に基づいて各リソースの輻輳度を判定する。以下では、輻輳度の判定手順について説明する。図２は、輻輳度の判定基準の例を示す図である。リソースの輻輳度の判定は、一つ前の測定周期で求められた輻輳度（前状態）及び後の測定周期の負荷状況（後状態）に基づき行われる。輻輳度は、リソースの処理負荷が最も高い「輻輳状態」と、リソースの処理負荷が比較的低い「非輻輳状態」に大別される。そして、「非輻輳状態」は、さらに、「非輻輳状態（低輻輳）」と「非輻輳状態（準輻輳）」とに区分される。非輻輳状態（準輻輳）は、リソースの処理負荷が輻輳度が輻輳状態と非輻輳状態（低輻輳）との間にある輻輳度である。前状態が存在しない場合（例えば情報処理装置１０の起動直後）においては、テンポラリ負荷量の「低負荷」、「中負荷」、「高負荷」のみに基づいて、輻輳度をそれぞれ「非輻輳状態（低輻輳）」、「非輻輳状態（準輻輳）」、「輻輳状態」と判定してもよい。

（１）前状態でリソースが「非輻輳状態（低輻輳）」の場合
前の測定周期（前状態）において、従機能部群１２〜１４に含まれる、あるリソース（ここでは「リソースＡ」とする）が「非輻輳状態（低輻輳）」であった場合は、後状態でリソースＡが低負荷又は中負荷であれば、輻輳度は「非輻輳状態（低輻輳）」であると判定される。前状態においてリソースＡが「非輻輳状態（低輻輳）」であった場合に、後の測定周期でリソースＡが高負荷であり、かつ、高負荷状態の保護段数のカウント値が予め設定された閾値以上である場合（すなわち、所定の回数以上連続して高負荷である場合）には、リソースＡは「非輻輳状態（準輻輳）」と判定される。保護段数のカウント値が閾値未満であれば、リソースＡは「非輻輳状態（低輻輳）」のままと判定される。

（２）前状態でリソースが「非輻輳状態（準輻輳）」の場合
前状態でリソースＡが「非輻輳状態（準輻輳）」であった場合は、後の測定周期でリソースＡが低負荷である場合、低負荷状態の保護段数のカウント値が予め設定された閾値以上である場合（すなわち、所定の回数以上連続して低負荷である場合）は、リソースＡは「非輻輳状態（低輻輳）」と判定される。保護段数のカウント値が閾値未満であれば、リソースＡは「非輻輳状態（準輻輳）」と判定される。後の測定周期でリソースＡが中負荷であれば、リソースＡは「非輻輳状態（準輻輳）」と判定される。後の測定周期でリソースＡが高負荷であり、かつ、高負荷状態の保護段数のカウント値が予め設定された閾値以上である場合には、リソースＡは「輻輳状態」と判定される。保護段数のカウント値が閾値未満であれば、リソースＡは「非輻輳状態（準輻輳）」と判定される。

（３）前状態でリソースが「輻輳状態」の場合
前状態でリソースＡが「輻輳状態」であった場合は、後の周期でリソースＡが低負荷であり、かつ、低負荷状態の保護段数のカウント値が予め設定された閾値以上である場合には、リソースＡは「非輻輳状態（準輻輳）」と判定される。保護段数のカウント値が閾値未満であれば、リソースＡは「輻輳状態」と判定される。前状態でリソースＡが「輻輳状態」であった場合に、後の測定周期でリソースＡが中負荷または高負荷であると判定された場合は、いずれの場合も「輻輳状態」と判定される。

上記のように、輻輳度の状態遷移に保護段数を設けることで、連続する測定周期で「非輻輳状態（低輻輳）」と「非輻輳状態（準輻輳）」と「輻輳状態」との間で状態遷移が行われる場合に、輻輳度が頻繁に遷移することを抑制できる。なお、上述のように保護段数を用いて状態遷移の判断を行う場合、輻輳度の低い状態から輻輳度がより高い状態への遷移が保護によって遅れることにより、高い負荷が長い時間継続し、リソースＡの安定動作に支障をきたす恐れがある。このため、輻輳度がより大きくなる方向への遷移に用いる保護段数は比較的小さく設定されてもよい。

輻輳度は、全てのリソースに対して並行して判定されてもよい。判定された輻輳度は、輻輳度通知として現用主機能部１１−１に通知される。予備主機能部１１−２は、各リソースに輻輳度を通知してもよい。現用主機能部１１−１は、通知された輻輳度通知に含まれる輻輳度に基づいて、リソースごとに適切な輻輳保護動作あるいはリソースの割り当てを実行できる。

以上のように、予備主機能部１１−２は、現用主機能部１１−１から従機能部群１２〜１４のリソースへ送信された処理メッセージの種別に基づいて推定走行時間を算出する。そして、予備主機能部１１−２は、リソースごとの推定走行時間を累計した走行時間累計値に基づいて、テンポラリ負荷量をリソースごとに算出する。そして、予備主機能部１１−２は、テンポラリ負荷量及び以前の輻輳度の判定結果に基づいて、現在の輻輳度をリソースごとに３段階のいずれかに判定する。

（従機能部群の説明）
従機能部群１２〜１４及びこれらが備えるリソースについて説明する。以下の説明は、特記されない限り、全ての従機能部群及びそれらが備えるリソースに関して共通である。

リソースは、情報処理装置１０内に設けられたＣＰＵにおいてプログラムが実行されることにより機能するＣＰＵ機能部である。各リソースは、主機能部１１（すなわち、現用主機能部１１−１及び予備主機能部１１−２）から処理メッセージを受信して、受信した処理メッセージの内容を実行する。各リソースは、処理メッセージが実行された結果を主機能部１１に返信する。各リソースは、処理メッセージを複製するとともに、複製された処理メッセージを現用主機能部１１−１及び予備主機能部１１−２に対して送信してもよい。このような構成より、予備主機能部１１−２は、従機能部群１２〜１４と現用主機能部１１−１との間で送受信される全ての処理メッセージを受信できる。

従機能部群１２〜１４及びそれらのリソースは、具体的には、着脱可能なハードウェア・パッケージでもよい。例えば、従機能部群１２は情報処理装置１０に実装されたカードであり、リソース１２−１〜１２−ｎはカード上のメモリ及びその制御デバイスである。このようなカード（すなわち、従機能部群）が情報処理装置１０に１枚以上搭載される。

このような主機能部１１及び従機能部群１２〜１４を備える情報処理装置１０は、マルチタスク処理を行い、入出力装置等の外部装置とのメッセージ通信をリアルタイムかつ並列に実行する。

（輻輳保護処理の説明）
現用主機能部１１−１は、予備主機能部１１−２から通知された輻輳度通知を確認する。輻輳度通知は、リソースごとの輻輳度の判定結果（すなわち、「非輻輳状態（低輻輳）」、「非輻輳状態（準輻輳）」、「輻輳状態」）を含む。

現用主機能部１１−１は、「非輻輳状態（準輻輳）」または「非輻輳状態（低輻輳）」にあるリソースに対しては、現用主機能部１１−１が当該リソースへ送信する処理メッセージに対して通常処理を行う。通常処理では、処理メッセージはリソースに送信される。

一方、現用主機能部１１−１は、「輻輳状態」にあるリソースに対しては、メッセージ判別機能により、当該リソースへ送信しようとする処理メッセージの種別及びその重要度を予め設定された基準に基づき判別する。そして、現用主機能部１１−１は、「輻輳状態」にあるリソースあてのメッセージについて、重要度が高いと判別された処理メッセージと、重要度が低いと判別された処理メッセージとで異なる処理（輻輳保護処理）を行う。

具体的には、現用主機能部１１−１は、重要度の低い処理メッセージを破棄、又は異常終了とする。これにより、「輻輳状態」にあるリソースにおける実行処理にかかる負荷を軽減できる。現用主機能部１１−１は、新たな通信リンクの確立要求に属する処理メッセージを、重要度が低いと判別してもよい。

一方、現用主機能部１１−１は、輻輳保護処理において、重要度が高いと判定された処理メッセージに対しては、リソースの輻輳度にかかわらず、通常の処理を行う。例えば、通信中の通信リンクの解放要求や保守監視要求に属する処理メッセージを、重要度が高いと判別してもよい。すなわち、リソースが「輻輳状態」にあっても、現用主機能部１１−１は、重要度が高い処理メッセージを通常通りリソースに送信する。これにより、重要なメッセージが廃棄されることを防ぎつつ、従機能部群が備えるリソースにおける輻輳保護制御が実現される。

なお、現用主機能部１１−１は、処理メッセージを重要度の高低で２種類に区別するのではなく、例えば高・中・低の３種類に判別してもよい。そして、３つの輻輳度に応じてリソースに送信する処理メッセージの重要度を３段階に区分してもよい。例えば、「非輻輳状態（低輻輳）」のリソースへは、全てのメッセージが送信される。「非輻輳状態（準輻輳）」のリソースへは、重要度が「高」及び「中」の処理メッセージのみが送信される。「輻輳状態」のリソースへは、重要度が「高」の処理メッセージのみが送信される。

このように、リソースの輻輳度及びメッセージの重要度を細分化して、リソースの輻輳度に応じてリソースへ送信されるメッセージを制限することで、リソースの輻輳度に応じた、よりきめ細かい輻輳保護制御が実現される。

（リソース再割り当て処理の説明）
現用主機能部１１−１は、リソースごとの輻輳度に基づいてリソースの割り当てを管理する機能を備える。具体的には、現用主機能部１１−１は、リソースごとに、輻輳度の継続性を確認し、「輻輳状態」が継続するリソースに対して割り当てられた処理を、「非輻輳状態（低輻輳）」が継続するリソースに割り当てる、リソース再割り当て処理を行う。

現用主機能部１１−１は、予備主機能部１１−２から通知される輻輳度通知の最新の内容（すなわち、リソースごとの輻輳度）を期間Ｔ１ごとに確認し、確認された輻輳度をリソースごとにカウントする。そして、現用主機能部１１−１は、所定の期間Ｔ２（Ｔ２＞Ｔ１）の間に輻輳状態と判定されたカウント値と、第１の輻輳状態継続閾値とを比較する。「輻輳状態」と判定されたカウント値が第１の輻輳状態継続閾値より大きい場合には、当該リソースは「輻輳継続」と判定される。例えば、現用主機能部１１−１は、期間Ｔ２の間に全てのリソースの輻輳度を１０回確認し、「輻輳状態」が３回以上あったリソースを「輻輳継続」と判定する。同様に、「非輻輳状態（低輻輳）」と判定されたカウント値が、第２の輻輳状態継続閾値と比較される。「非輻輳状態（低輻輳）」と判定されたカウント値が第２の輻輳状態継続閾値より大きな場合は、当該リソースは「非輻輳継続」と判定される。例えば、現用主機能部１１−１は、期間Ｔ２の間に全てのリソースの輻輳度を１０回確認し、「非輻輳状態（低輻輳）」が５回以上あったリソースを「非輻輳継続」と判定する。「輻輳継続」及び「非輻輳継続」の両者の条件が満たされた場合には、現用主機能部１１−１は、「輻輳継続」及び「非輻輳継続」のいずれの判定も行わなくともよい。

現用主機能部１１−１は、「輻輳継続」と判定されたリソースが検出されると、当該リソースを含まない従機能部群の中から、「非輻輳継続」と判定されたリソースを探す。「非輻輳継続」と判定されたリソースが他に存在する場合は、現用主機能部１１−１は、「輻輳継続」と判定されたリソースの処理を「非輻輳継続」と判定されたリソースに割り当てる。現用主機能部１１−１は、それまで「輻輳継続」のリソース宛に送信していた処理メッセージの宛先を変更し、新たに割り当てられた「非輻輳継続」のリソースに当該処理メッセージを送信する。

このような処理により、輻輳状態が継続しているリソースの負荷を低減することで従機能部の輻輳を抑制し、情報処理装置１０全体の処理の効率化を図ることができる。

なお、「非輻輳状態（準輻輳）」のリソースは、「非輻輳状態（低輻輳）」のリソースと比較して負荷が高いため、「輻輳継続」のリソースの処理が割り当てられることで輻輳状態に陥る可能性が「非輻輳状態（低輻輳）」のリソースよりも高い。このため、上記の手順ではあるリソースについて「非輻輳状態（準輻輳）」が継続していることを、「輻輳継続」と判定されたリソースの処理の再割り当ての対象とする判断に用いていない。このように、輻輳度を３段階に区分して「非輻輳状態（準輻輳）」のリソースを再割り当ての対象とすることを抑制することで、「非輻輳状態（準輻輳）」のリソースが「輻輳継続」のリソースに代わって処理を行うことで輻輳状態に陥ることを抑制できる。

なお、「非輻輳状態（準輻輳）」が継続しているリソースを再割り当ての対象としないことを確実にするために、「非輻輳状態（準輻輳）」の継続数をカウントし、「非輻輳状態（準輻輳）」と判定されたカウント値が第３の輻輳状態継続閾値より大きい場合には、当該リソースを「準輻輳継続」と判定してもよい。「準輻輳継続」と判定されたリソースは、リソースの処理の再割り当ての対象からは除外される。

さらに、処理メッセージの重要度の高低により異なる処理を行う輻輳保護処理と、「輻輳継続」とされたリソースの処理を「非輻輳継続」とされたリソースに割り当てるリソース再割り当て処理とは、どちらか一方のみ、あるいは、両者の併用のいずれによってもリソースの輻輳度を改善できる。例えば、輻輳保護処理によって重要度の比較的高い処理メッセージのみが「輻輳状態」のリソースに送信されるようになっても当該リソースの輻輳度が低下しない場合、リソースの再割り当て処理によって当該リソースが「輻輳継続」と判定されると、リソースの負荷が分散される。その結果、輻輳保護処理のみでは負荷低減の効果が低いリソースが「輻輳継続」と判定されることで、負荷をさらに低減させることができる。

（フローチャートによる動作説明）
上述した第１の実施形態の動作を、図３〜図５のフローチャートに基づいて説明する。まず、予備主機能部１１−２におけるリソースの輻輳度の通知処理の例について図３のフローチャートに基づき説明する。現用主機能部１１−１における輻輳保護処理及びリソース再割り当て処理については、図４及び図５のフローチャートに基づき説明する。

図３の各ステップは、リソースごとに並行して行われる。以下のフローチャートの説明では、説明の対象となるリソースを例として「リソースＢ」と記載する。リソースＢに関する説明は、情報処理装置１０が備える全てのリソースに共通である。

図３において、予備主機能部１１−２は、予め設定された周期タイマを起動して（ステップＳ１０１：「周期タイマ割り込み」）、累計カウンタ及び推定走行時間累計値を初期化する（ステップＳ１０２）。

予備主機能部１１−２は、現用主機能部１１−１からリソースＢへ通知された処理メッセージの数をリソースごとに受信カウンタに登録するとともに、リソースＢへ通知された処理メッセージをそれぞれ解析して処理メッセージの種別（メッセージ種別）を特定する（ステップＳ１０３）。予備主機能部１１−２は、特定されたメッセージ種別を、処理メッセージ及びその重要度と対応づけて現用主機能部１１−１に通知してもよい。

予備主機能部１１−２は、予め設定された推定走行時間テーブルに基づき、メッセージ種別が特定された処理メッセージの推定走行時間値を読み出す（ステップＳ１０４）とともに、推定走行時間累計値に上記で読み出された推定走行時間値を加算する（ステップＳ１０５）。

予備主機能部１１−２は、推定走行時間値を加算すると、累計カウンタの値を１増やす（ステップＳ１０６）。ここで、受信カウンタと累計カウンタの値が等しいか否かが判定される（ステップＳ１０７）。両カウンタの値が異なる場合（ステップＳ１０７：ＮＯ）は、予備主機能部１１−２は受信された他の処理メッセージを解析する（ステップＳ１０３へ）。受信カウンタと累計カウンタの値が等しい場合（ステップＳ１０７：ＹＥＳ）は、受信された処理メッセージ全ての推定走行時間値が設定されたと判定される。

予備主機能部１１−２は、推定走行時間累計値に基づき、テンポラリ負荷量を算出するとともに、当該テンポラリ負荷量が、低負荷、中負荷、もしくは高負荷のいずれに該当するかを判定する（ステップＳ１０８）。低負荷、中負荷、及び高負荷は、既述のように、推定走行時間累計値を相異なる２つの閾値と比較し、比較結果に基づいてテンポラリ負荷量を３段階に区分することで判定されてもよい。

次に、予備主機能部１１−２は、上記判定結果、および現用主機能部１１−１の前状態等に基づいて、リソースＢの輻輳度を判定する（ステップＳ１０９：「輻輳度判定処理」）。ステップＳ１０９の処理は、既述の図２の基準により行われる。予備主機能部１１−２は、ステップＳ１０９で判定されたリソースごとの輻輳度を、現用主機能部１１−１に通知する（ステップＳ１１０：「輻輳度通知処理」）。

予備主機能部１１−２は、現用主機能部１１−１の周辺機能部であり、情報処理装置１０の処理のボトルネックとはならない。このため、予備主機能部１１−２が図３で説明した処理を実行しても、主機能部１１全体としての処理能力は低下しない。

次に、現用主機能部１１−１における輻輳保護処理について、図４のフローチャートに基づき説明する。図４は、現用主機能部１１−１における輻輳保護処理の例を示すフローチャートである。図４は、図３のステップＳ１１０において、予備主機能部１１−２から輻輳状態が通知された後の、現用主機能部１１−１における処理の例を示すフローチャートである。

現用主機能部１１−１は、リソースＢへの処理メッセージの送信処理が発生すると（Ｓ２０１）、予備主機能部１１−２から通知された輻輳度通知に基づいて、リソースＢの輻輳度を判断する（ステップＳ２０２）。輻輳度は、図２に示したように、「輻輳状態」、「非輻輳状態（準輻輳）」、及び「非輻輳状態（低輻輳）」の３段階であり、この順に輻輳度（すなわちリソースＢの負荷）が低い。

ステップＳ２０２において、リソースＢの輻輳度が「輻輳状態」以外（すなわち、「非輻輳状態（準輻輳）」又は「非輻輳状態（低輻輳））」と判断された場合には（ステップＳ２０２：ＮＯ）、処理メッセージには通常の処理が実行される（ステップＳ２０５）。通常処理では、処理メッセージは通常通りリソースＢに送信される。

リソースＢの輻輳度が「輻輳状態」と判断された場合には（ステップＳ２０２：ＹＥＳ）、現用主機能部１１−１は、リソースＢに送信される処理メッセージについて、予め設定されたメッセージ種別の重要度に応じて重要度の高低を判定する（ステップＳ２０３：メッセージ種別判定）。ここで、当該処理メッセージの重要度の情報が過去に予備主機能部１１−２から通知されていた場合には、現用主機能部１１−１は、当該情報に基づいて処理メッセージの重要度を判定してもよい。

ステップＳ２０３において、新たな通信リンクの確立要求など重要度が低いと判断された処理メッセージに対しては、破棄処理又は異常終了処理（輻輳保護処理）が実行される（ステップＳ２０３：重要以外〜Ｓ２０４）。一方、重要度が高いと判断された処理メッセージは、通常通りリソースＢに送信される（ステップＳ２０３：重要〜Ｓ２０５）。既述のように、ステップＳ２０２における輻輳状態の判定は２段階ではなく例えば３段階で行われてもよく、メッセージの重要度の判定も３段階以上で行われてもよい。これにより、よりきめ細かい輻輳保護処理が行われる。

続いて、図５を用いて「輻輳継続」のリソースが検出された場合の現用主機能部１１−１の動作について説明する。図５は、現用主機能部１１−１のリソースの再割り当て手順の例を示すフローチャートである。「輻輳継続」のリソースが検出されない場合は、現用主機能部１１−１は、図５に示されたリソースの再割り当てを行わない。

現用主機能部１１−１は、「輻輳継続」と判定されたリソース（従機能部ｘ１、対応するリソースｙ１）が検出されると（図５のステップＳ３０１）、リソースｙ１が属する従機能部群ｘ１を除く従機能部群の中から、「非輻輳継続」と判定されたリソースを探す（ステップＳ３０２）。「非輻輳継続」と判定されたリソースが存在する場合は（ステップＳ３０２：ＹＥＳ）、現用主機能部１１−１は、「非輻輳継続」と判定されたリソース（従機能部ｘ２、リソースｙ２）を特定し（ステップＳ３０３）、リソースｙ２の運用を停止する（ステップＳ３０４）。現用主機能部１１−１は、リソースｙ２の運用停止を確認後、「輻輳継続」と判定されたリソースｙ１の処理をリソースｙ２に割り当てる。そして、リソースｙ２に、リソースｙ１の機能による運用開始を指示する（ステップＳ３０５）。ここで、現用主機能部１１−１は、それまでリソースｙ１宛に送信していた処理メッセージを、新たに割り当てられたリソースｙ２に送信する。

図５に示す手順により、「輻輳継続」と判定されたリソースの負荷を低減することで従機能部の輻輳を抑制し、情報処理装置１０全体の処理の効率化を図ることができる。また、図５の手順は「非輻輳状態（準輻輳）」の継続については、「輻輳継続」のリソースの処理の再割り当ての対象とする判断には用いられない。

以上説明した図４及び図５の処理はいずれか一方のみが実施されてもよく、いずれもが実施されてもよい。どちらの場合においても、第１の実施形態の情報処理装置１０は、主機能部と従機能部とで構成される情報処理装置において、従機能部の輻輳による情報処理装置の性能の低下を抑制することが可能という効果を奏する。

また、第１の実施形態の情報処理装置１０は、プログラムによるリソース単位での負荷の低減が可能である。このため、情報処理装置１０は、従機能部の処理能力増強のためのハードウェア・リソースの増設に時間を要する場合でも、従機能部の輻輳を迅速かつ低コストで改善することができる。

（第２の実施形態）
第１の実施形態の情報処理装置１０は、第２の実施形態の情報処理装置として以下のようにも表現できる。すなわち、情報処理装置は、第１の主機能部と、第２の主機能部と、リソースを含む従機能部群と、を備える。第１の実施形態との対比において、第１の主機能部は現用主機能部１１−１に対応し、第２の主機能部は予備主機能部１１−２に対応し、リソースを含む従機能部群は、従機能部群１２〜１４に対応する。

第１の主機能部は、処理メッセージの送信を制御する。第２の主機能部は、第１の主機能部に併設され、処理メッセージを解析してその解析結果を第１の主機能部に通知する。第１の主機能部と、第２の主機能部と、リソースとは通信可能に接続される。リソースは、処理メッセージを第１の主機能部から受信して処理する。

このような構成において、第２の主機能部は、第１の主機能部からリソースへ送信される処理メッセージの推定処理時間をリソースごとに累計した推定累計走行時間値に基づいて、リソースの負荷量をリソースごとに判定する。そして、第２の主機能部は、判定された負荷量に基づいて、リソースにおける輻輳の程度を示す輻輳度を、第１の状態、第１の状態よりも輻輳度が高い第２の状態、及び、第２の状態よりも輻輳度が高い第３の状態のいずれかとして前記リソースごとに判定する。第１の実施形態との対比において、第１の状態は「非輻輳状態（低輻輳）」、第２の状態は「非輻輳状態（準輻輳）」、第３の状態は「輻輳状態」にそれぞれ対応する。第２の主機能部は、輻輳度の判定結果を輻輳度通知として第１の主機能部に通知する。そして、第１の主機能部は、輻輳度通知に含まれる輻輳度の判定結果に基づいて、対応するリソース宛の処理メッセージを処理する。ここで、第１の主機能部における、輻輳度の判定結果に基づく処理メッセージの処理には、例えば、処理メッセージの重要度に基づく破棄処理や、輻輳継続状態の判定結果に基づく処理メッセージの送信先のリソースの変更（すなわち、リソースの再割り当て）が含まれる。

このような構成を備える第２の実施形態の情報処理装置も、輻輳度の判定結果に基づいて処理メッセージを処理することで、輻輳度が高い従機能部群のリソースの負荷を低減し、情報処理装置全体の処理の効率化を図ることができる。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１０ 情報処理装置
１１ 主機能部
１１−１ 現用主機能部
１１−２ 予備主機能部
１２〜１４ 従機能部群
１２−１〜１２−ｎ リソース

Claims (7)

1. 処理メッセージの送信を制御する第１の主機能部と、
   前記処理メッセージを解析して前記解析の結果を前記第１の主機能部に通知する、前記第１の主機能部に併設され前記第１の主機能部と通信可能な第２の主機能部と、
   前記第１及び第２の主機能部と通信可能に接続され、前記処理メッセージを前記第１の主機能部から受信して処理するリソースを含む従機能部群と、を備え、
   前記第２の主機能部は、
   前記第１の主機能部から前記リソースへ送信される前記処理メッセージの推定処理時間を前記リソースごとに累計した推定累計走行時間値に基づいて前記リソースの負荷量を前記リソースごとに判定し、
   前記負荷量の判定結果に基づいて、前記リソースにおける輻輳の程度を示す輻輳度を、第１の状態、前記第１の状態よりも輻輳度が高い第２の状態、及び、前記第２の状態よりも輻輳度が高い第３の状態のいずれかとして前記リソースごとに判定し、
   前記輻輳度の判定結果を輻輳度通知として前記第１の主機能部に通知し、
   前記第１の主機能部は、
   前記輻輳度通知に含まれる前記輻輳度の判定結果に基づいて、対応する前記リソース宛の前記処理メッセージを処理する、
   情報処理装置。
2. 前記第１の主機能部は、前記輻輳度通知に含まれる前記輻輳度の判定結果に基づいて前記リソースの輻輳度の前記第１の状態の継続状態及び前記第３の状態の継続状態を前記リソースごとに判定し、前記第３の状態が継続していると判定された前記リソースと前記第１の状態が継続していると判定された前記リソースとが存在する場合には前記第３の状態が継続していると判定された前記リソースの処理を前記第１の状態が継続していると判定された前記リソースに割り当てる、請求項１に記載された情報処理装置。
3. 前記第１の主機能部は、さらに、前記第２の状態の継続状態を前記リソースごとに判定し、前記第２の状態が継続していると判定された前記リソースを前記第３の状態が継続していると判定された前記リソースの処理の割り当てから除外する、請求項２に記載された情報処理装置。
4. 前記第１の主機能部は、前記処理メッセージの重要度を複数の段階で判定し、前記輻輳度通知に含まれる前記輻輳度が所定の状態よりも高い場合に、前記重要度が所定の段階よりも低いと判定された前記処理メッセージを破棄する、請求項１乃至３のいずれかに記載された情報処理装置。
5. 前記第２の主機能部は、
   前記負荷量を、前記推定累計走行時間値の大きさに基づいて第１の負荷量、前記第１の負荷量よりも負荷が高い第２の負荷量、及び、前記第２の負荷量よりも負荷が高い第３の負荷量のいずれかとして前記リソースごとに判定し、
   前記輻輳度を、現在の前記負荷量と過去に判定された前記輻輳度とに基づいて前記リソースごとに判定する、
   請求項１乃至４のいずれかに記載された情報処理装置。
6. 第１の主機能部からリソースへ送信される処理メッセージの推定処理時間を前記リソースごとに累計した推定累計走行時間値に基づいて、前記リソースの負荷量を前記リソースごとに判定し、
   前記負荷量に基づいて、前記リソースにおける輻輳の程度を示す輻輳度を、第１の状態、前記第１の状態よりも輻輳度が高い第２の状態、及び、前記第２の状態よりも輻輳度が高い第３の状態のいずれかとして前記リソースごとに判定し、
   前記輻輳度の判定結果を輻輳度通知として通知し、
   前記輻輳度通知に含まれる前記輻輳度の判定結果に基づいて、対応する前記リソース宛の前記処理メッセージを処理する、
   ことを特徴とする情報処理装置の制御方法。
7. 情報処理装置が備えるコンピュータに、
   第１の主機能部からリソースへ送信される処理メッセージの推定処理時間を前記リソースごとに累計した推定累計走行時間値に基づいて、前記リソースの負荷量を前記リソースごとに判定する手順、
   前記負荷量に基づいて、前記リソースにおける輻輳の程度を示す輻輳度を、第１の状態、前記第１の状態よりも輻輳度が高い第２の状態、及び、前記第２の状態よりも輻輳度が高い第３の状態のいずれかとして前記リソースごとに判定する手順、
   前記輻輳度の判定結果を輻輳度通知として通知する手順、
   前記輻輳度通知に含まれる前記輻輳度の判定結果に基づいて、対応する前記リソース宛の前記処理メッセージを処理する手順、
   を実行させるための情報処理装置の制御プログラム。

Images