(57)【特許請求の範囲】
【請求項１】
各タスクの制御ブロックをキューに管理してスケジューリングを行うタスクスケジューリング機能部と，
ＣＰＵに負荷を与えるペースメーカとなるタスクの制御ブロックを前記キューに投入し，該タスクの処理の実行により自モジュールの処理性能を調整する処理性能調整機能部とを備え，
前記処理性能調整機能部は，他のモジュールに対して依頼したデータの処理の応答時間があらかじめ定められた閾値を超えた場合，または自モジュールの単位時間あたりの処理量があらかじめ定められた閾値を超えた場合に，前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する
ことを特徴とする処理性能調整機能を有するモジュール。
【請求項２】
前記処理性能調整機能部は，他のモジュールに対して依頼したデータの処理の応答時間があらかじめ定められた閾値を下回った場合，または前記ペースメーカとなるタスクがキューに投入されてから規定の時間が経過した場合に，前記ペースメーカとなるタスクの制御ブロックを前記キューから削除する
ことを特徴とする請求項１に記載の処理性能調整機能を有するモジュール。
【請求項３】
前記処理性能調整機能部は，前記制御ブロックの投入数を変えることにより，または前記ペースメーカとなるタスクの処理量を変えることにより，前記ＣＰＵに与える負荷の量を調整する
ことを特徴とする請求項１または請求項２に記載の処理性能調整機能を有するモジュール。
【請求項４】
各タスクの制御ブロックをキューに管理してスケジューリングを行うタスクスケジューリング機能部を備えるモジュールのコンピュータが，
ＣＰＵに負荷を与えるペースメーカとなるタスクの制御ブロックを前記キューに投入する処理と，
前記ペースメーカとなるタスクの処理の実行により，自モジュールの処理性能を調整する処理とを実行し，
前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する処理では，他のモジュールに対して依頼したデータの処理の応答時間があらかじめ定められた閾値を超えた場合，または自モジュールの単位時間あたりの処理量があらかじめ定められた閾値を超えた場合に，前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する
ことを特徴とする処理性能調整方法。
【請求項５】
各タスクの制御ブロックをキューに管理してスケジューリングを行うタスクスケジューリング機能部を備えるモジュールのコンピュータに，
ＣＰＵに負荷を与えるペースメーカとなるタスクの制御ブロックを前記キューに投入する処理と，
前記ペースメーカとなるタスクの処理の実行により，自モジュールの処理性能を調整する処理とを実行させ，
前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する処理では，他のモジュールに対して依頼したデータの処理の応答時間があらかじめ定められた閾値を超えた場合，または自モジュールの単位時間あたりの処理量があらかじめ定められた閾値を超えた場合に，前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する
ことを特徴とする処理性能調整プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，タスクスケジューリング機能を有するモジュールの処理性能を調整する技術に関するものであり，特に，ペースメーカとなるタスクを投入することにより処理性能を調整する処理性能調整機能を有するモジュール，処理性能調整方法および処理性能調整プログラムに関するものである。
【背景技術】
【０００２】
図６は，従来技術とその課題を説明するためのシステム構成の例を示す図である。図６に示すシステムでは，モジュールＡ５００がホスト５２０からの処理要求を受け，モジュールＢ５１０がモジュールＡ５００から仕事を請け負うという関係にある。図６において，各モジュールは，それぞれが独立にＣＰＵを備えた情報処理装置である。
【０００３】
ホスト５２０からのＩ／Ｏ負荷が低いときには，モジュールＡ５００はホスト５２０から依頼された処理を滞りなく逐次こなし，モジュールＢ５１０に必要な処理を依頼する。モジュールＡ５００とモジュールＢ５１０との負荷バランスが保たれているものとすると，モジュールＢ５１０もモジュールＡ５００から請け負った仕事を遅延なくこなす。
【０００４】
ホスト５２０からのＩ／Ｏ負荷が高いときには，モジュールＡ５００は，ホスト５２０からの処理依頼を受けるが，内部リソースの枯渇などで処理が追いつかず，ホスト５２０に対してビジー応答する。そのため，モジュールＢ５１０に依頼される仕事はモジュールＡ５００の処理能力に応じて絞られるため，結果的にモジュールＢ５１０の仕事量も適当な量となり，図６に示すシステムは全体として安定している。
【０００５】
なお，モジュールＡ５００，モジュールＢ５１０は，それぞれタスクスケジューリング機能を備え，複数の処理要求を請け負うことが可能である。タスクスケジューリングに関する技術が記載された先行技術文献として，例えば特許文献１などがある。特許文献１には，複数のプロセッサ間で資源の使い回しを行うことによる性能低下を防ぐために，資源またはキャッシュのウォーム度を考慮し，複数プロセッサで効率よく多くのプロセスを実行できるようにスケジューリングを行う技術が記載されている。
【特許文献１】特開平６−９６０３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
図６において，モジュールＡ５００のハードウェアが変更され，モジュールＡ５００の処理性能が上がった場合について考える。ホスト５２０からのＩ／Ｏ負荷が低いときには，上述のハードウェア変更前のときと同様に，モジュールＡ５００，モジュールＢ５１０ともに滞りなく処理が行われる。
【０００７】
ホスト５２０からのＩ／Ｏ負荷が高いときには，上述のハードウェア変更前の場合とは，状況が異なってくる。モジュールＡ５００は，処理性能が上がり，ホスト５２０からの処理依頼をすべて受けれるようになったため，ホスト５２０から依頼された処理に対してビジー応答せずに逐次実行することができるようになる。それにともない，モジュールＡ５００がモジュールＢ５１０に依頼する処理の量も増加する。
【０００８】
ところが，モジュールＢ５１０では，処理性能がもとのままであるので，モジュールＡ５００からの処理依頼の増加によりリソースが枯渇となり，内部的に処理が停滞する。そのため，モジュールＢ５１０からモジュールＡ５００への応答に遅延が発生する。
【０００９】
モジュールＢ５１０からモジュールＡ５００への応答が遅延するのにともなって，モジュールＡ５００からホスト５２０への応答にも遅れが発生するため，ホスト５２０側から見た場合にＩ／Ｏ処理の完了遅延またはタイムアウト（ホストの監視時間内に完了報告がなかった）となってしまう可能性があり，ひどい場合にはタイムアウトが多発し，ジョブの異常終了となってしまう可能性もある。
【００１０】
このように，ハードウェア変更前は，モジュールＡ５００とモジュールＢ５１０との負荷バランスは保たれていたが，モジュールＡ５００のハードウェア変更を行うことによりモジュールＡ５００とモジュールＢ５１０との負荷バランスが崩れてしまう。このことによって，システム全体として見た場合に性能的に不整合が生じてしまう可能性があり，その結果として，システム性能の低下などが危惧される。
【００１１】
本発明は，上記の問題点の解決を図り，複数のモジュールから構成されるシステムにおいて，モジュール間の負荷バランスを保つことにより，システム全体として安定した状態や性能を保持することが可能となる技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記の課題を解決するために，システムを構成する各モジュールが，ＣＰＵ性能によらずにある一定の処理性能を保つために，内部にペースメーカとなるタスクを置き，そのペースメーカのタスクによって自らの仕事量を調整できるようにする。これにより，システムを構成する個々のモジュールが，他のモジュールとの間の性能差を自ら調整し，結果，システム全体として安定した状態や性能を保つことができるようになる。
【００１３】
具体的には，処理性能調整機能を有するモジュールは，各タスクの制御ブロックをキューに管理してスケジューリングを行うタスクスケジューリング機能部と，ＣＰＵに負荷を与えるペースメーカとなるタスクの制御ブロックを前記キューに投入し，該タスクの処理の実行により自モジュールの処理性能を調整する処理性能調整機能部とを備え，前記処理性能調整機能部は，他のモジュールに対して依頼したデータの処理の応答時間があらかじめ定められた閾値を超えた場合，または自モジュールの単位時間あたりの処理量があらかじめ定められた閾値を超えた場合に，前記ペースメーカとなるタスクの制御ブロックを前記キューに投入する。
【００１４】
モジュールが備えるタスクスケジューリング機能部は，各タスクの制御ブロックをキュー管理しており，基本的にはキューに並べられた制御ブロックの順にタスクの処理がディスパッチされる。タスクスケジューリング機能部によりペースメーカとなるタスクがディスパッチされると，そのペースメーカとなるタスクの処理の実行による負荷がＣＰＵに与えられる。これにより，他の通常の処理を実行するためのリソースが減ることとなり，結果として，そのモジュールの見かけ上の流量（単位時間当たりの処理量）を減らすことができる。
【００１６】
また，ペースメーカとなるタスクが不要であると判定するためのあらかじめ定められた条件としては，例えば，自モジュールが他のモジュールに依頼した処理に対する応答時間があらかじめ定められた閾値を下回ったかや，ペースメーカとなるタスクが投入されてから規定の時間が経過したかなど，様々な条件が考えられる。
【００１７】
また，ペースメーカとなるタスクがＣＰＵに負荷を与えるために実行する処理としては，例えば，他の処理に遅延以外の影響を与えない無意味なループ処理など，様々な処理が考えられる。
【００１８】
また，モジュールに備えられた処理性能調整機能部は，ペースメーカとなるタスクのスケジュールに用いる制御ブロックの投入数を変えたり，ペースメーカとなるタスクの処理量を変えたりすることにより，ＣＰＵに与える負荷の量を調整する。ペースメーカとなるタスクが，自身の処理量を変化させる処理を実行するようにしてもよい。
【００１９】
ペースメーカとなるタスクの動作を管理する制御ブロックの投入数を増やす，すなわちペースメーカとなるタスクの数を増やすことにより，ＣＰＵの負荷量を増やすことができる。また，ペースメーカとなるタスクの処理量を増やす（ループ回数を増やすなど）ことにより，ＣＰＵの負荷量を増やすことができる。このように，ペースメーカとなるタスクの投入数やペースメーカとなるタスクの処理量を変化させることにより，ＣＰＵに与える負荷の量を自在に調整することができる。
【００２０】
以上のような処理性能調整機能部によって投入されるペースメーカとなるタスクやその制御ブロックは，他の通常の処理のタスクや制御ブロックと基本的に同じ仕組みであり，通常のタスク管理を行うタスクスケジューリング機能部によって動作するものである。よって，処理性能調整機能部の導入にあたって，もとからモジュールが有していたタスクスケジューリング機能部などのファームウェアの構造を変更する必要はなく，基本的には現行のリソースをそのままの構造で使用することができる。また，ペースメーカとなるタスクもタスクスケジューリング機能部を介して実行される１つのタスクでしかないので，割り込み処理なども従来と同様に行われ，割り込み処理などの反応が遅延するということもない。
【発明の効果】
【００２１】
本発明により，複数のモジュールから構成されるシステムにおいて，独立に処理を行うモジュールの処理性能を調整することができるようになるため，各モジュール間の負荷バランスを保持することが可能となり，システム全体として安定した状態や性能を保持することが可能となる。
【発明を実施するための最良の形態】
【００２２】
以下，本発明の実施の形態について，図面を用いて説明する。
【００２３】
図１は，本実施の形態による情報処理システムの例を示す図である。図１に示す情報処理システムは，モジュールＡ１０，モジュールＢ２０，ホスト３０から構成される。モジュールＡ１０，モジュールＢ２０は，それぞれがＣＰＵを有し，独立に処理を実行する情報機器である。ホスト３０からの処理要求をモジュールＡ１０が受け，モジュールＢ２０はモジュールＡ１０からの処理を請け負う。なお，モジュールＡ１０，モジュールＢ２０は，それぞれが別々の筐体に収められた情報処理装置であってもよいし，１つの筐体に収められながらもそれぞれが独立に処理を行うボードのようなものであってもよい。
【００２４】
モジュールＡ１０は，処理性能調整機能部１００，スケジューラ１１０を備える。
【００２５】
スケジューラ１１０は，モジュールＡ１０において並行的に実行される複数の処理（タスク）のスケジュール管理を行う。スケジューラ１１０では，タスクを動かすための制御ブロック（以下，ＴＣＢ（Task Control Block）と呼ぶ）をキュー管理している。以下では，ホスト処理のタスクを実行させるためのＴＣＢをホストＴＣＢと呼び，自機器（図１ではモジュールＡ１０）の処理性能を調整するペースメーカ処理のタスクを実行させるためのＴＣＢをペースメーカＴＣＢと呼ぶものとする。
【００２６】
ＴＣＢのフォーマットは，大きく分けて，共通域と処理種別固有域の２つの領域に分かれる。共通域は，処理の種別（ホスト処理，ペースメーカ処理など）によらない，共通の領域である。処理種別固有域は，処理の種別によって，一部フォーマットや格納される情報が異なる領域である。
【００２７】
共通域には，
・スケジューラ１１０が必要とする情報，
・ＴＣＢ情報（ＴＣＢが格納されているメモリアドレスなどの情報），
・ＴＣＢ管理情報
などの情報が格納される。
【００２８】
処理種別固有域には，ホスト処理の場合，
・オペレーション種別（リード／ライトなどの種別），
・処理対象アドレス，
・処理対象データサイズ
などの情報が格納され，ペースメーカ処理の場合，
・予定処理内容（例えば，ループ処理を１０００回など），
・実績処理回数（実際にペースメーカのタスクが起動された回数）
などの情報が格納される。
【００２９】
処理性能調整機能部１００は，自機器の処理性能を調整する機能であり，状態監視部１０１，ペースメーカ要不要判定部１０２，ペースメーカＴＣＢ処理部１０３，ホストＴＣＢ監視情報１０４，ペースメーカＴＣＢ監視情報１０５を備える。
【００３０】
状態監視部１０１は，ホストＴＣＢ監視情報１０４やペースメーカＴＣＢ監視情報１０５などを監視することにより，自機器の状態や自機器に接続された他機器の状態などを監視する。図１に示す情報処理システムにおいて，例えばモジュールＢ２０に処理を依頼してから応答が返ってくるまでの時間などを監視する。
【００３１】
ペースメーカ要不要判定部１０２は，自機器の処理性能を調整するためのペースメーカのタスクの要不要の判定，すなわちペースメーカＴＣＢの投入や回収の判定を行う。図１に示す情報処理システムにおいて，ペースメーカ要不要判定部１０２は，例えばモジュールＢ２０の応答時間やペースメーカＴＣＢの投入状況を判断し，ペースメーカＴＣＢを投入するか回収するかを判定する。
【００３２】
ペースメーカＴＣＢ処理部１０３は，ペースメーカＴＣＢの作成，投入，回収を行う手段であり，ペースメーカのタスクを動作させるためのペースメーカＴＣＢを作成するペースメーカＴＣＢ作成部１０６，スケジューラ１１０にペースメーカＴＣＢを投入するペースメーカＴＣＢ投入部１０７，スケジューラ１１０からペースメーカＴＣＢを回収するペースメーカＴＣＢ回収部１０８を備える。
【００３３】
ホストＴＣＢ監視情報１０４は，ホストＴＣＢを管理する情報である。ホストＴＣＢ監視情報１０４には，
・閾値情報（相手モジュール規定応答時間，規定単位時間ホスト処理数などのペースメーカＴＣＢ投入のための閾値情報），
・相手モジュール応答時間（累積），
・相手モジュール応答時間（単位時間），
・ホスト処理数（累積），
・ホスト処理数（現在），
・ホスト処理回数（累積），
・ホスト処理時間（累積），
・ホスト処理データサイズ（累積），
・相手モジュール情報，
・相手モジュールへの処理依頼開始ＴＯＤ（Time Of Day ）情報（時刻情報）
などの情報が格納される。相手モジュール情報と，相手モジュールへの処理依頼開始ＴＯＤ情報とについては，スケジューラ１１０で管理されているホストＴＣＢ数分の情報が格納される。
【００３４】
ペースメーカＴＣＢ監視情報１０５は，ペースメーカＴＣＢを管理する情報である。ペースメーカＴＣＢ監視情報１０５には，
・投入条件（例えば，相手モジュール応答時間，単位時間ホスト処理数など，ペースメーカＴＣＢの投入を判断するための条件），
・回収条件（例えば，相手モジュール応答時間が閾値を下回ったら，回数など，ペースメーカＴＣＢの回収を判断するための条件），
・投入個数（累積），
・投入個数（現在），
・投入回数（累積）
などの情報が格納される。
【００３５】
図１に示す情報処理システムのモジュールＡ１０における基本処理の例と，高負荷時の処理の例とを説明する。
【００３６】
＜基本処理＞
モジュールＡ１０は，ホスト３０から処理要求を受けると，ホストＴＣＢを用意し，処理対象アドレスの判定や，処理すべきデータの準備，ホストとのデータ転送などの一連の処理を行う。ここでは，ホスト３０からの処理要求が，リード要求またはライト要求であるものとする。
【００３７】
このとき，これら一連の処理は，
（１）処理対象アドレスの判定を行うタスク
（２）処理すべきデータの準備を行うタスク
（３）ホスト３０とのデータ転送を行うタスク
の３つのタスクに分割される。ホスト３０から要求された処理を分割する目的は，ホスト３０から複数のリード（またはライト）要求があったときに，それらの複数の処理に対して同時にサービスすることを可能とするためである。モジュールＡ１０内では，スケジューラ１１０を介して，順次処理が進められる。
【００３８】
ここで，ホスト３０から３つの処理要求（処理＃１〜＃３）を受けると，モジュールＡ１０では，必要なホストＴＣＢ（ホストＴＣＢ＃１〜＃３）が用意され，スケジューラ１１０に順番にキューイングされる。スケジューラ１１０は，キューに並べられたホストＴＣＢの順に処理を進めていく。
【００３９】
図２は，ＣＰＵ処理とキューの状態との例を示す図である。図２において，〔〕はホストＴＣＢを表し，例えば〔ＴＣＢ＃１−２〕は，処理＃１の２回目のタスク処理のホストＴＣＢであることを意味する。ＳＴＥＰは，処理が進んでいく段階を表す。各ＳＴＥＰにおいて，ＣＰＵ処理欄に記載されたＴＣＢは，まさにＣＰＵ処理が行われているタスクのＴＣＢを示し，キューの状態欄に記載されたＴＣＢは，順番待ちのためにキューに並べられたＴＣＢを示す。
【００４０】
図２において，ＳＴＥＰ−０１では，処理＃１〜＃３のタスクのホストＴＣＢが順にキューイングされた状態である。ＳＴＥＰ−０２では，先頭にキューイングされていた〔ＴＣＢ＃１−１〕のタスクの処理が実行される。ＳＴＥＰ−０３では，〔ＴＣＢ＃１−１〕のタスクの処理が終了し，その次にキューイングされていた〔ＴＣＢ＃２−１〕のタスクの処理が実行されている状態である。ＳＴＥＰ−０３では，１回目のタスク処理が終了した処理＃１における２回目のタスク処理のホストＴＣＢ（〔ＴＣＢ＃１−２〕）が，最後尾にキューイングされている。このような処理が，順次繰り返される。
【００４１】
モジュールＡ１０は，モジュールＢ２０に対して必要な処理依頼を行いながら，上記の処理＃１〜＃３を実行する。ここでは，処理＃１〜＃３のすべてでモジュールＢ２０との通信が行われる。モジュールＡ１０で実行される処理の中には，モジュールＢ２０からの応答を受けないと実行できない処理もある。
【００４２】
モジュールＢ２０は，モジュールＡ１０からの処理依頼を受けると，モジュールＡ１０と同様にＴＣＢを用意し，同様にスケジューラ（図示省略）を介して，ある単位で必要な処理を行う。モジュールＢ２０は，一通りの処理が終了すると，モジュールＡ１０に対して応答を返し，不要となったＴＣＢを消去する。
【００４３】
このようなモジュールＡ１０とモジュールＢ２０との関係があるため，モジュールＡ１０の処理能力によって，モジュールＢ２０の負荷（忙しさ）が変わってくる。つまり，モジュールＡ１０の処理能力が高いほど，すなわちモジュールＡ１０の単位時間当たりの仕事量が多いほど，モジュールＡ１０からモジュールＢ２０への単位時間当たりの処理依頼量も増えるため，モジュールＢ２０の負荷が高い状況となる。
【００４４】
＜高負荷時の処理＞
ホストからの処理要求が増え，高負荷の状態となるものとする。モジュールＡ１０の処理性能が高ければ，モジュールＡ１０はホストからの処理要求に対してほとんどビジー応答せず多くの仕事量をこなすことができ，それにともないモジュールＡ１０からモジュールＢ２０への処理依頼も増加する。モジュールＢ２０の処理性能がモジュールＡ１０からの処理依頼の増加に耐えうるものでなければ，モジュールＢ２０にはモジュールＡ１０から依頼された処理がどんどん溜まっていき，モジュールＢ２０からモジュールＡ１０への応答に遅延が発生するようになる。
【００４５】
モジュールＡ１０では，このような状況の悪化を監視し，情報処理システム全体としての安定化を図るために，処理性能調整機能部１００により自機器の処理性能を調整する。以下，ペースメーカＴＣＢの作成／投入処理，ペースメーカＴＣＢの回収処理，ペースメーカのタスクによる処理など，ペースメーカのタスクによって処理性能の調整を行う例について説明する。
【００４６】
［ペースメーカＴＣＢの作成／投入処理の例］
モジュールＡ１０は，処理性能調整機能部１００により，モジュールＢ２０からの応答時間を監視し，所定の閾値以上の応答遅延が発生しているようであれば，自機器内部でペースメーカのタスクを動作させるためのペースメーカＴＣＢを作成し，それを投入することにより自機器の処理量を抑制する。
【００４７】
ここでは，モジュールＢ２０からの応答時間を監視し，ペースメーカＴＣＢの作成／投入を判断しているが，ペースメーカＴＣＢの作成／投入のトリガとしてはさまざまなものが考えられる。例えば，ホスト３０からの処理要求に対する自機器からのレスポンス時間を監視したり，自機器の処理量そのものを監視するなどの方法も考えられる。
【００４８】
図３は，ペースメーカＴＣＢ作成／投入処理フローチャートである。ここでは，モジュールＡ１０がモジュールＢ２０からの応答時間を監視することにより，ペースメーカＴＣＢの作成／投入を判断する場合を例として，ペースメーカＴＣＢ作成／投入処理を説明する。
【００４９】
モジュールＡ１０の処理性能調整機能部１００は，モジュールＢ２０からの応答時間を監視し，モジュールＢ２０からの応答時間が所定の閾値を超えているかを判定する（ステップＳ１０）。例えば，ホストＴＣＢ監視情報１０４の相手モジュールへの処理依頼開始ＴＯＤ情報を監視し，その相手モジュールへの処理依頼開始ＴＯＤ情報からモジュールＢ２０の応答時間を計算し，算出された応答時間がホストＴＣＢ監視情報１０４の閾値情報（この場合には，相手モジュール規定応答時間）を超えているかを判定する。
【００５０】
モジュールＢ２０からの応答時間が所定の閾値を超えていれば，ペースメーカＴＣＢが投入可能かを判定する（ステップＳ１１）。ＴＣＢを格納するメモリ領域などは有限であるので，投入可能なＴＣＢの数も有限となる。そのため，新たにペースメーカＴＣＢを投入することが可能であるかを確認する必要がある。
【００５１】
ペースメーカＴＣＢの投入が可能であれば，ペースメーカＴＣＢの投入数をインクリメント（＋１）する（ステップＳ１２）。例えば，ペースメーカＴＣＢ監視情報１０５の投入個数（現在）をインクリメント（＋１）する。
【００５２】
ペースメーカＴＣＢを作成し，投入する（ステップＳ１３）。投入されたペースメーカＴＣＢは，スケジューラ１１０のキューに並べられ，以降スケジューラ１１０によってペースメーカのタスクがディスパッチされる。
【００５３】
［ペースメーカＴＣＢの回収処理の例］
モジュールＡ１０は，ペースメーカ投入後も引き続きモジュールＢ２０からの応答時間を監視し，応答時間が所定の閾値を下回ったところで，投入されているペースメーカＴＣＢを回収（スケジューラ１１０から削除）する。ペースメーカＴＣＢ回収後は，ペースメーカＴＣＢ投入前の状態に戻る。
【００５４】
ここでは，モジュールＢ２０からの応答時間を監視し，ペースメーカＴＣＢの回収を判断しているが，ペースメーカＴＣＢ作成／投入の場合と同様にペースメーカＴＣＢ回収のトリガとしてはさまざまなものが考えられる。例えば，ホスト３０からの処理要求に対する自機器からのレスポンス時間を監視したり，自機器の処理量そのものを監視するなどの方法も考えられる。
【００５５】
また，ペースメーカＴＣＢの回収を所定の閾値で判断するのではなく，ペースメーカＴＣＢを一定時間投入するという考え方もある。例えば，ペースメーカＴＣＢに投入開始時間（ＴＯＤ情報）と投入期間とを記録しておき，ペースメーカのタスク自身が投入期間を監視し，時間が経過したらペースメーカのタスク自身で回収処理を行うようにしてもよい。その後も高負荷状態が続き，モジュールＢ２０の応答遅延が発生するようであれば，上述の処理にしたがって，再度ペースメーカＴＣＢの作成／投入を行う。
【００５６】
図４は，ペースメーカＴＣＢ回収処理フローチャートである。ここでは，モジュールＡ１０がモジュールＢ２０からの応答時間を監視することにより，ペースメーカＴＣＢの回収を判断する場合を例として，ペースメーカＴＣＢ回収処理を説明する。
【００５７】
モジュールＡ１０の処理性能調整機能部１００は，現在，ペースメーカＴＣＢが投入された状態であるかを判定する（ステップＳ２０）。例えば，ペースメーカＴＣＢ監視情報１０５の投入個数（現在）が１以上であるかを確認する。
【００５８】
ペースメーカＴＣＢが投入された状態であれば，モジュールＢ２０からの応答時間を監視し，モジュールＢ２０からの応答時間が所定の閾値未満であるかを判定する（ステップＳ２１）。例えば，ホストＴＣＢ監視情報１０４の相手モジュールへの処理依頼開始ＴＯＤ情報を監視し，その相手モジュールへの処理依頼開始ＴＯＤ情報からモジュールＢ２０の応答時間を計算し，算出された応答時間がホストＴＣＢ監視情報１０４の閾値情報（この場合には，相手モジュール規定応答時間）を下回っているかを判定する。
【００５９】
モジュールＢ２０からの応答時間が所定の閾値未満であれば，ペースメーカＴＣＢの投入数をデクリメント（−１）する（ステップＳ２２）。例えば，ペースメーカＴＣＢ監視情報１０５の投入個数（現在）をデクリメント（−１）する。
【００６０】
ペースメーカＴＣＢを１つ回収する（ステップＳ２３）。回収されたペースメーカＴＣＢは，スケジューラ１１０のキューから削除される。
【００６１】
以上説明した図４に示すペースメーカＴＣＢ回収処理は，処理性能調整機能部１００によって実行される処理の例である。ペースメーカＴＣＢ回収処理は，ペースメーカのタスクの処理内で実行することも可能である。
【００６２】
［ペースメーカのタスクによる処理の例］
スケジューラ１１０においてペースメーカＴＣＢの順番が回ってくると，ペースメーカのタスクの処理が実行される。ペースメーカのタスクでは，他の処理に遅延以外の影響を与えない無意味な処理を，ＣＰＵに実行させる。ここでは，ペースメーカのタスクによる処理の一例を説明する。なお，ペースメーカのタスクの処理を実行するためのプログラムは，他のタスクの処理を実行するためのプログラムと同様に，モジュールＡ１０内に保持されている。また，ペースメーカのタスクも，他のタスクと同様にスケジューラ１１０を介して実行されるタスクの１つでしかないので，割り込み処理などが他のタスクと同様に行われ，ペースメーカのタスクにより割り込み処理の反応が遅延したりはしない。
【００６３】
ペースメーカＴＣＢは，投入された時間（ＴＯＤ情報）や，ＣＰＵによって処理された回数のカウンタ（実績処理回数）などの情報を持つ。ペースメーカのタスクがＣＰＵ処理に回されたところで，そのペースメーカのタスクにおいて，ペースメーカＴＣＢのＴＯＤ情報などをもとにモジュールＡ１０の流量（仕事量）を計算するなどの処理を行う。例えば，ＴＯＤ情報をもとにペースメーカＴＣＢ投入後の経過時間を算出し，また実績処理回数によりそのペースメーカのタスクがＣＰＵ処理された回数を取得し，単位時間あたりのそのペースメーカのタスクの処理回数などを求めることにより，モジュールＡ１０の流量を概算することができる。
【００６４】
さらに，ペースメーカのタスクでは，モジュールＡ１０の流量をコントロールするために，必要に応じて本ペースメーカのタスクをその場で必要な時間スリープさせ，他のタスクがＣＰＵ処理に回されないように調整する。例えば，先に求められたモジュールＡ１０の流量をもとにＣＰＵに実行させるループ処理の回数を決定し，決定された回数のループ処理をＣＰＵに実行させる。
【００６５】
なお，ペースメーカのタスクによる処理量は，固定であってもよいし，可変であってもよい。例えば，ペースメーカのタスクによる処理量を固定とし，投入するペースメーカＴＣＢの個数を調整することによってＣＰＵへの負荷量を調整してもよいし，ペースメーカのタスクによる処理量を可変とし，ペースメーカのタスクによる処理量を調整することよってＣＰＵへの負荷量を調整してもよい。当然，ペースメーカＴＣＢの投入個数と処理量とを同時に調整するようにしてもよい。
【００６６】
図５は，ペースメーカＴＣＢ投入時のＣＰＵ処理とキューの状態との例を示す図である。図５の記載は，基本的に図２の記載と同様である。ただし，図５において≪≫はペースメーカＴＣＢを表し，例えば≪ＴＣＢ＃４−２≫は，ペースメーカのタスクである処理＃４における２回目の処理であることを意味する。図５の例では，１個のペースメーカのタスクによる処理量を調整する（例えば，ＣＰＵに行われるループ処理の回数を調整する）ことにより，ホスト３０から要求された処理に割り当てられる単位時間当たりの処理量を調整する。
【００６７】
図５において，ＳＴＥＰ−０１では，処理＃１〜＃３のホストＴＣＢと処理＃４のペースメーカＴＣＢとが順にキューイングされた状態である。ＳＴＥＰ−０２では，先頭にキューイングされていた〔ＴＣＢ＃１−１〕のタスクの処理が実行される。ＳＴＥＰ−０３では，〔ＴＣＢ＃１−１〕のタスクの処理が終了し，その次にキューイングされていた〔ＴＣＢ＃２−１〕のタスクの処理が実行されている状態である。ＳＴＥＰ−０３では，１回目のタスク処理が終了した処理＃１における２回目のタスク処理のホストＴＣＢ（〔ＴＣＢ＃１−２〕）が，最後尾にキューイングされている。以下，このような処理が，順次繰り返される。
【００６８】
ＳＴＥＰ−０５では，ペースメーカＴＣＢである≪ＴＣＢ＃４−１≫のタスクの処理が実行され，例えばＣＰＵにループ処理を行わせるなどにより，モジュールＡ１０の流量を調整する。ペースメーカのタスクの処理終了時に，ペースメーカＴＣＢの実績処理回数をインクリメント（＋１）し，スケジューラ１１０により，そのペースメーカＴＣＢ（≪ＴＣＢ＃４−２≫）のキューイングを行う。このような処理が，順次繰り返される。
【００６９】
なお，ペースメーカのタスクの処理でモジュールＢ２０の応答時間の監視等を行い，ペースメーカＴＣＢの回収の判断を行うようにしてもよい。この場合，ペースメーカのタスクの処理によりペースメーカＴＣＢの回収が判断されれば，その処理によってスケジューラ１１０からペースメーカＴＣＢが回収され，スケジューラ１１０のキューにペースメーカＴＣＢが並ばない状態となる。
【００７０】
図２に示すペースメーカＴＣＢを投入していない場合と，図５に示すペースメーカＴＣＢを投入している場合とを比較すると，図２ではホストＴＣＢ（〔ＴＣＢ＃３−３〕）のタスクの処理がＳＴＥＰ−１０で実行されているのに対して，図５ではホストＴＣＢ（〔ＴＣＢ＃３−３〕）のタスクの処理がＳＴＥＰ−１２で実行されている。
【００７１】
すなわち，ペースメーカＴＣＢ（≪ＴＣＢ＃４−１≫）とペースメーカＴＣＢ（≪ＴＣＢ＃４−２≫）のタスクの処理をＣＰＵに実行させた分だけ，モジュールＡ１０の処理に遅延が発生し，見た目上のモジュールＡ１０の処理性能を低下させることができる。
【００７２】
このように，ペースメーカＴＣＢを投入してモジュールＡ１０の処理性能を調整することにより，モジュールＡ１０とモジュールＢ２０との間の負荷バランスを保つことが可能となり，結果，情報処理システム全体の安定した状態や性能を保持することが可能となる。
【００７３】
ここで，ペースメーカＴＣＢの投入から回収までの具体的な流れを簡単にまとめておく。まず，事前に，ホストＴＣＢ監視情報１０４の閾値情報を設定しておく必要がある。
【００７４】
モジュールＡ１０がホスト３０から処理要求を受けると，モジュールＡ１０では，ホストＴＣＢが作成され，処理が開始される。モジュールＡ１０は，ホスト３０から要求された処理の流れに従って，必要な処理をモジュールＢ２０に依頼する。
【００７５】
モジュールＢ２０に処理依頼を行ったことを，ホストＴＣＢ監視情報１０４に格納する。具体的には，ホストＴＣＢ監視情報１０４に，相手モジュール情報，相手モジュールへの処理依頼開始ＴＯＤ情報を格納する。
【００７６】
定期的に，ホストＴＣＢ監視情報１０４を監視する。具体的には，現在の時刻情報と相手モジュールへの処理依頼開始ＴＯＤ情報とを比較し，モジュールＢ２０の応答時間をチェックする。
【００７７】
モジュールＢ２０の応答時間とホストＴＣＢ監視情報１０４の閾値情報とを比較し，モジュールＢ２０の応答時間が閾値を超えていたら，ペースメーカＴＣＢを作成し，投入する。このとき，ペースメーカＴＣＢに必要な情報（例えば，処理内容＝ループ処理を１０００回など）を格納する。また，ペースメーカＴＣＢ監視情報１０５にも，必要な情報（例えば，回収条件＝応答時間が閾値を下回ったなど）を格納する。
【００７８】
投入されたペースメーカＴＣＢにより動作されるペースメーカのタスクは，順番がくるとスケジューラ１１０により起動される。起動されたペースメーカのタスクは，ペースメーカＴＣＢの処理内容を認識し，ループ処理を実行する。さらに，ペースメーカＴＣＢの実績処理回数を＋１する。また，ペースメーカＴＣＢ監視情報１０５の回収条件を参照し，その回収条件に合致した状態であるかをチェックする。ペースメーカＴＣＢ監視情報１０５の回収条件にまだ合致した状態でない場合には，ペースメーカＴＣＢが再度スケジューラ１１０によりキューイングされる。
【００７９】
その後，モジュールＢ２０の応答時間が短縮された後に，再度ペースメーカのタスクがスケジューラ１１０により起動されると，起動されたペースメーカのタスクは，ペースメーカＴＣＢ監視情報１０５の回収条件を参照し，すでにモジュールＢ２０の応答時間が閾値を下回っていることを認識する。よって，ループ処理などを行わずに，またスケジューラ１１０によりペースメーカＴＣＢが再度キューイングされずに，ペースメーカのタスクの処理が終結される。このとき，ペースメーカＴＣＢ監視情報１０４の投入個数（現在）をデクリメント（−１）する。これがペースメーカＴＣＢの回収となる。
【００８０】
以上説明した処理性能調整機能部１００による処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。
【図面の簡単な説明】
【００８１】
【図１】本実施の形態による情報処理システムの例を示す図である。
【図２】ＣＰＵ処理とキューの状態との例を示す図である。
【図３】ペースメーカＴＣＢ作成／投入処理フローチャートである。
【図４】ペースメーカＴＣＢ回収処理フローチャートである。
【図５】ペースメーカＴＣＢ投入時のＣＰＵ処理とキューの状態との例を示す図である。
【図６】従来技術とその課題を説明するためのシステム構成の例を示す図である。
【符号の説明】
【００８２】
１０  モジュールＡ
１００  処理性能調整機能部
１０１  状態監視部
１０２  ペースメーカ要不要判定部
１０３  ペースメーカＴＣＢ処理部
１０４  ホストＴＣＢ監視情報
１０５  ペースメーカＴＣＢ監視情報
１０６  ペースメーカＴＣＢ作成部
１０７  ペースメーカＴＣＢ投入部
１０８  ペースメーカＴＣＢ回収部
１１０  スケジューラ
２０  モジュールＢ
３０  ホスト
【図１】
0005115122.tif 000002
【図２】
0005115122.tif 000003
【図３】
0005115122.tif 000004
【図４】
0005115122.tif 000005
【図５】
0005115122.tif 000006
【図６】
0005115122.tif 000007