JP5691749B2 - リソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システム - Google Patents

Description

本発明は、リソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムに関する。

従来、複数のコンピュータから構成されるシステムにおいて、ＣＰＵ（Central Processing Unit）やネットワーク帯域などのリソースの負荷を制限し、ＱｏＳ（Quality of Service）やＳＬＡ（Service Level Agreement）を維持、管理する技術がある。

例えば、ロードバランサー等の負荷分散装置は、ラウンドロビン方式でシステム内のコンピュータに処理を分散させる。また、分散先コンピュータにエージェントプログラムを配備させ、コンピュータのＣＰＵ利用率を計測し、ＣＰＵの利用状況に応じて処理を分散させる方式がある。これらいずれの分散方式においても、分散先となるコンピュータは、処理が実行される前に決定される。

分散先となるコンピュータにて処理が開始されると、コンピュータの保有するリソース以上に負荷が発生するケースがある。また、ネットワーク帯域などの複数のコンピュータがリソースを共有する場合、処理を分散した後に過負荷がかかりシステムとしてリソース不足になる場合がある。このようなことから、処理を分散した後にリソースが不足した場合、リソースの需要を予測し、予測した需要に基づき分散先となるコンピュータを管理する技術が知られている。また、仮想化技術を利用したコンピュータシステムにおいて、別の仮想コンピュータが有するリソースの余剰分を回収して、不足したリソースを補填する技術も知られている。

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

しかしながら、上述した従来の技術では、処理動作中に利用するリソース量を外部から抑制することができないという課題があった。

近年はマルチメディアなどの大量なデータを高速に処理し、多数のクライアントにサービスを提供することが求められている。例えば、映像の形式を変換するメディア処理のプログラムは、大量なデータを長時間取り扱うので、１トランザクションあたりのスループットを高めるために、ＣＰＵリソースを最大限に利用する。このため、メディア処理のプログラムによってＣＰＵリソースが使い切られてしまい、通信のためのプロセスなどの他のプロセスは、十分な性能で動作することができなくなる。

また、仮想化技術を利用したコンピュータリソースの効率的な運用方法として、異なるユーザを同居させたマルチテナントで物理的なリソースを共有するクラウドコンピューティングがある。クラウドコンピューティングでは、異なるユーザＡとユーザＢとでハードディスクを共有するが、互いのユーザは、相手のディスクにはアクセスできないようにセキュリティが保証されている。また、互いのユーザは、相互にアクセスを調停することもできない。

このため、例えば、ユーザＡがハードディスクを長時間利用中に、ユーザＢもハードディスクにアクセスした場合、ユーザＢは、ユーザＡがアクセスを終了するまでハードディスクへアクセスできない。この結果、ユーザＢのＣＰＵは、ユーザＡがハードディスクへのアクセスを終了するまで動作できなくなり、他のプロセスを処理できなくなる。このようなことから、ユーザＡによるハードディスクへのアクセスを抑制することが望まれる。

また、クラウドコンピューティングでは、ネットワークの組み替えを論理的に行うためにＶＬＡＮ（Virtual Local Area Network）を用いて同じ物理ケーブル内で他のネットワークセグメントを共有することが多い。このため、ゲストマシンＡがネットワーク帯域に余裕があると判定しても、既に他のゲストマシＢンが物理帯域を使い切っており、リソースが枯渇していることがある。このような場合、ゲストマシンＡは、ネットワーク帯域を利用できなくなる。

開示の技術は、上記に鑑みてなされたものであって、処理動作中に利用するリソース量を外部から抑制することができるリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムを提供することを目的とする。

本願の開示するリソース抑制プログラムは、一つの態様において、自装置のリソースの容量とリソースの利用量とを取得する。また、リソース抑制プログラムは、取得されたリソースの容量とリソースの利用量とを監視装置に送信する。また、リソース抑制プログラムは、送信されたリソースの容量とリソースの利用量とに基づいて、監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、リソースの利用量を抑制することを示す抑制通知を監視装置から受信する。また、リソース抑制プログラムは、受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する。また、リソース抑制プログラムは、リソースの利用を管理する管理装置を送信先としたリソースの利用要求のうち、特定したプロセスからの利用要求を取得する。そして、リソース抑制プログラムは、取得した利用要求を保持し、利用要求を保持する時間が所定時間経過した後に、保持する利用要求を管理装置に出力する。

本願の開示するリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムの一つの態様によれば、処理動作中に利用するリソース量を外部から抑制することができるという効果を奏する。

図１は、コンピュータシステムの構成例を示す図である。 図２は、マスターノードの構成を示すブロック図である。 図３は、リソース識別テーブルの一例を示す図である。 図４は、リソース利用状況テーブルの一例を示す図である。 図５は、スレーブノードの構成を示すブロック図である。 図６は、マスターノードによる処理の処理手順を示すフローチャートである。 図７は、スレーブノードによる処理の処理手順を示すフローチャートである。 図８は、スレーブノードによる抑制通知受信処理の処理手順を示すフローチャートである。 図９は、スレーブノードによる抑制処理の処理手順を示すフローチャートである。 図１０は、Ｓｕｓｐｅｎｄ／Ｒｅｓｕｍｅ ＴｈｒｅａｄによるＣＰＵ負荷抑制処理の処理手順を示すフローチャートである。 図１１は、ＡＰＩによるＩ／Ｏ利用抑制処理を示すシーケンス図である。 図１２は、ＫｅｒｎｅｌフックによるＩ／Ｏ利用抑制処理を示すシーケンス図である。 図１３は、実施例２に係るマスターノードによる処理の処理手順を示すフローチャートである。 図１４は、実施例２に係るスレーブノードによる処理の処理手順を示すフローチャートであるである。 図１５は、リソース監視プログラムを実行するコンピュータを示す図である。 図１６は、リソース抑制プログラムを実行するコンピュータを示す図である。

以下に、本願の開示するリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

実施例１では、図１から図１２を用いて、コンピュータシステムの全体構成、マスターノードの構成、スレーブノードの構成、処理の処理手順、実施例１による効果を順に説明する。

［コンピュータシステムの全体構成］
図１は、コンピュータシステムの構成例を示す図である。図１に示すように、コンピュータシステム１は、マスターノード２０とスレーブノード３０〜５０とを有する。ここで、マスターノード２０は、システムに１台存在するコンピュータであり、監視装置の一例である。スレーブノード３０〜５０は、システムに１台以上存在するコンピュータであり、情報処理装置の一例である。マスターノード２０と、スレーブノード３０〜５０とは、ハブ・スポーク型ネットワーク２で互いに通信可能に接続されている。なお、マスターノード２０と、スレーブノード３０〜５０との接続は、ハブ・スポーク型ネットワーク２に限定されるものではなく、ＩＰ（Internet Protocol）ネットワークに接続されていれば他の接続形態であってもよい。

このようなコンピュータシステム１において、スレーブノード３０〜５０は、自装置のリソースの容量とリソースの利用量とを取得し、取得したリソースの容量とリソースの利用量とをマスターノード２０に送信する。

マスターノード２０は、自装置と接続された複数のスレーブノード３０〜５０それぞれから複数のスレーブノード３０〜５０それぞれが有するリソースの容量とリソースの利用量とを取得する。マスターノード２０は、取得した複数のスレーブノード３０〜５０が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する。マスターノード２０は、リソースの総利用量が所定の閾値を超えたと判定した場合、リソースの利用量を抑制することを示す抑制通知を生成する。マスターノード２０は、より多くリソースを利用しているスレーブノード３０〜５０に生成した抑制通知を送信する。

そして、スレーブノード３０〜５０は、送信したリソースの容量とリソースの利用量とに基づいて、マスターノード２０によって自装置が利用するリソースが抑制対象であると判定された場合に、抑制通知をマスターノード２０から受信する。そして、スレーブノード３０〜５０は、リソースの利用量を抑制する。このように、コンピュータシステム１は、処理動作中に利用するリソース量を外部から抑制する。

［マスターノードの構成］
次に、図２を用いて、マスターノードの構成を説明する。図２は、マスターノードの構成を示すブロック図である。マスターノードは、記憶部２１と通信部２２と制御部２３とを有する。

記憶部２１は、例えば、半導体メモリ素子などの記憶装置であり、リソース識別テーブル２１ａ、リソース利用状況テーブル２１ｂを有する。図３はリソース識別テーブルの一例を示す図である。図３に示すように、リソース識別テーブル２１ａは、「リソースＩＤ」と「リソース名」とを対応付けた情報を記憶する。

ここで、リソース識別テーブル２１ａとして記憶される「リソースＩＤ」は、リソースを識別する識別子を示す。例えば、「リソースＩＤ」には、「１」、「２」、「３」などが格納される。また、「リソース名」は、リソースの名称を示す。例えば、「リソース名」には、「ＣＰＵ負荷 ユーザ［％］」、「ＣＰＵ負荷 カーネル［％］」、「ＣＰＵ負荷 Ｉ／Ｏ待ち［％］」などが格納される。

図３に示す例では、リソース識別テーブル２１ａは、「リソースＩＤ」が「１」で識別されるリソースがユーザモードのＣＰＵ負荷であることを示し、「リソースＩＤ」が「２」で識別されるリソースがカーネルモードのＣＰＵ負荷であることを示す。なお、リソース識別テーブル２１ａが記憶する情報は、ユーザによって予め設定される。

リソース利用状況テーブル２１ｂは、スレーブノード単位のリソース利用状況を示す情報を記憶する。図４を用いてリソース利用状況テーブル２１ｂとして記憶される情報を説明する。図４は、リソース利用状況テーブルの一例を示す図である。なお、リソース利用状況テーブル２１ｂとして記憶される情報は、全体監視部２４によって格納される。

図４に示すように、例えば、リソース利用状況テーブル２１ｂは、「スレーブノードＩＤ」ごとの「リソースＩＤ」の情報を記憶する。ここで、リソース利用状況テーブル２１ｂに記憶される「リソースＩＤ」は、リソース識別テーブル２１ａとして記憶される「リソースＩＤ」と同様に、リソースを識別する識別子を示す。また、「スレーブノードＩＤ」は、スレーブノードの識別子である。例えば、「スレーブノードＩＤ」には、「１９２．１６８．２．１」、「１９２．１６８．２．２」、「１９２．１６８．２．３」などが格納される。なお、以下の説明では、スレーブノード３０のスレーブノードＩＤを「１９２．１６８．２．１」、スレーブノード４０のスレーブノードＩＤを「１９２．１６８．２．２」、スレーブノード５０のスレーブノードＩＤを「１９２．１６８．２．３」として説明する。

図４に示す例では、リソース利用状況テーブル２１ｂは、「リソースＩＤ」が「１」であるユーザモードのＣＰＵ負荷は、スレーブノード３０で「７％」、スレーブノード４０で「６５％」、スレーブノード５０で「３９％」であることを示す。同様に、リソース利用状況テーブル２１ｂは、「リソースＩＤ」が「２」であるカーネルモードのＣＰＵ負荷は、スレーブノード３０で「２％」、スレーブノード４０で「２３％」、スレーブノード５０で「１４％」であることを示す。

図２に戻り、通信部２２は、スレーブノード３０〜５０と情報のやり取りを制御する。例えば、通信部２２は、スレーブノード３０〜５０からリソース容量とリソース利用量とを受信する。通信部２２は、受信したリソース容量とリソース利用量とを全体監視部２４に出力する。また、通信部２２は、特定部２５によって生成されたリソース抑制通知を受付け、受付けたリソース抑制通知をリソース抑制対象であるスレーブノードに送信する。

制御部２３は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路であり、全体監視部２４と特定部２５とを有する。

全体監視部２４は、通信部２２を介して取得したスレーブノード３０〜５０の稼動状態をリソース利用状況テーブル２１ｂに格納する。例えば、全体監視部２４は、スレーブノード３０〜５０からのリソース容量とリソース利用量とを取得し、取得したリソース容量とリソース利用量とをリソース利用状況テーブル２１ｂに格納する。

一例を挙げると、全体監視部２４は、スレーブノード４０からＮＩＣ性能が１００００００［ＫＢ／秒］、送信パケット量が２５００［ＫＢ／秒］、受信パケット量が４０００［ＫＢ／秒］であることを取得した場合、以下の処理を実行する。すなわち、全体監視部２４は、リソース利用状況テーブル２１ｂのノードＩＤ「１９２．１６８．２．２」の「リソースＩＤ３１」に「１００００００」、「リソースＩＤ３２」に「２５００」、「リソースＩＤ３３」に「４０００」を格納する。

また、全体監視部２４は、リソース利用状況テーブル２１ｂをもとに、各スレーブノードのリソース容量の総和からシステムのリソース総容量を算出する。例えば、全体監視部２４は、図４に示したリソース利用状況テーブルにおいて、リソースＩＤが３１であるＮＩＣ性能が、スレーブノード３０〜５０それぞれで「１００００００［ＫＢ／秒］」である場合、以下の処理を実行する。すなわち、全体監視部２４は、システムのＮＩＣ性能は、「３００００００［ＫＢ／秒］」であると算出する。

また、全体監視部２４は、リソース利用状況テーブル２１ｂをもとに、各スレーブのリソース利用量の総和から、システムのリソース総利用量を算出する。例えば、全体監視部２４は、図４に示したリソース利用状況テーブルにおいて、リソースＩＤが３２とリソースＩＤ３３とからシステムのＮＩＣリソース総利用量を算出する。すなわち、全体監視部２４は、システムのＮＩＣ性能は、「６８００［ＫＢ／秒］」であると算出する。

また、全体監視部２４は、算出したシステムのリソース総容量、総利用量をリソース利用状況テーブル２１ｂに格納し、リソース容量とリソース利用量とをリソース利用状況テーブル２１ｂに格納したことを特定部２５に通知する。

特定部２５は、システム全体のリソース容量と各スレーブノードのリソース利用量の総和を比較し、システムリソースが枯渇傾向にあるか否かを判定する。特定部２５は、システムのリソースが枯渇傾向であると判定した場合、抑制フラグをたてる。例えば、特定部２５は、システム全体のリソース利用量が所定の閾値を超えたと判定した場合に、リソースが枯渇していると判定する。一例を挙げると、特定部２５は、ＤＩＳＫ Ｉ／Ｏの利用量が９０％を超えた場合、システム全体のリソースが枯渇していると判定する。なお、閾値の値はこれに限定されるものではなく、任意に変更可能である。

また、特定部２５は、通知のあったスレーブノードと他のスレーブノード間で比較してリソースの利用量に偏りがあるか否かを判定する。特定部２５は、リソースの利用量に偏りがあると判定した場合、抑制フラグをたてる。例えば、特定部２５は、システム全体のリソース利用量が所定の閾値を超えていないと判定した場合に、リソースの利用量に偏りがあるか否かを判定する。一例を挙げると、特定部２５は、送信パケット量及び受信パケット量が所定の閾値、「９０％」を超えていないが、スレーブノード４０が「８５％」もネットワークリソースを利用していた場合には、リソースの利用量に偏りがあると判定する。なお、閾値の値はこれらに限定されるものではなく、任意に変更可能である。

そして、特定部２５は、抑制フラグが真である場合、スレーブノードＩＤとリソースＩＤとを含んだリソース抑制通知を生成し、生成したリソース抑制通知を通信部２２に出力する。例えば、特定部２５は、リソース利用量の高いスレーブノードＩＤもしくは偏りのあるスレーブノードＩＤと、リソースＩＤとをリソース利用状況テーブル２１ｂから特定する。

［スレーブノードの構成］
次に、図５を用いて、スレーブノードの構成を説明する。図５は、スレーブノードの構成を示すブロック図である。スレーブノード３０は、記憶部３１と通信部３２と制御部３３とを有する。なお、スレーブノード３０〜５０の構成は同様であるので、ここでは、スレーブノード３０の構成についてのみ説明し、スレーブノード４０〜５０の構成についての説明は省略する。

記憶部３１は、例えば、半導体メモリ素子などの記憶装置であり、リソース識別テーブル３１ａ、リソース利用状況テーブル３１ｂを有する。なお、リソース識別テーブル３１ａとして記憶される情報は、リソース識別テーブル２１ａとして記憶される情報と同様であるので、ここでは、リソース識別テーブル３１ａについての説明を省略する。また、リソース利用状況テーブル３１ｂとして記憶される情報は、リソース利用状況テーブル２１ｂとして記憶される情報と同様であるので、ここでは、リソース利用状況テーブル３１ｂについての説明を省略する。

通信部３２は、マスターノード２０及びスレーブノード４０〜５０と情報のやり取りを制御する。例えば、通信部３２は、稼動監視部３８から自装置のリソース容量とリソース利用量とを受付け、受付けたリソース容量とリソース利用量とをマスターノード２０に送信する。また、通信部３２は、マスターノード２０からリソース抑制通知を受信する。通信部３２は、受信したリソース抑制通知をリソース抑制部３９に出力する。

制御部３３は、ＣＰＵやＭＰＵなどの電子回路であり、プロセス群３４とＡＰＩ処理部３５とカーネル部３６とドライバ部３７と稼動監視部３８とリソース抑制部３９とを有する。

プロセス群３４は、スレーブノード３０が有するリソースを利用するプログラムの実体である。プロセス群３４は、リソースを利用する場合、ＡＰＩ処理部３５にリソースの利用を要求する。なお、プロセス群３４には、抑制対象となるリソースを利用するプロセスが含まれる。

ＡＰＩ処理部３５は、プロセス群３４からリソースの利用要求を受け付け、受け付けた利用要求をカーネル部３６に出力する。例えば、ＡＰＩ処理部３５は、プロセス群３４からリソースの利用の要求を受け付けた場合、ＡＰＩ（Application Programming Interface）を提供し、提供したＡＰＩを介してプロセス群３４からリソースの利用要求を受け付ける。

カーネル部３６は、メモリ、ＣＰＵ、Ｉ／Ｏ(Input Output)などのシステムのリソースを管理し、プロセス群３４とドライバ部３７とのやりとりを制御する。すなわち、カーネル部３６は、オペレーティングシステムの基本コンポーネントとして、ハードウェアとソフトウェアがやり取りできるようにする。例えば、カーネル部３６は、ＡＰＩ処理部３５からリソースの利用要求を受け付けた場合、リソースの利用を要求するプロセス群３４に対してリソースを割り当てる。

ドライバ部３７は、カーネル部３６からリソースの割り当て指示を受け付け、受け付けた指示に基づきハードウェアを制御する。例えば、ドライブ部３７は、Ｉ／Ｏリソースやネットワークリソースを制御する。

稼動監視部３８は、自ノードの保有するリソース容量と、自ノード内で稼働中のプロセス群のリソース利用量を取得する。そして、稼動監視部３８は、取得したリソース利用量からプロセス毎のリソース利用量の総和を算出する。

また、稼動監視部３８は、取得したリソース容量とリソース利用量とを比較し、ノード内のリソースが枯渇傾向にあるか否かを判定する。そして、稼動監視部３８は、ノード内のリソースが枯渇していると判定した場合、枯渇しているリソースのリソースＩＤを特定し、特定したリソースＩＤをリソース抑制部３９に出力する。例えば、稼動監視部３８は、リソース利用量が所定の閾値を超えたと判定した場合に、リソースが枯渇していると判定する。一例を挙げると、稼動監視部３８は、ＣＰＵの利用量が８５％を超えた場合、リソースが枯渇していると判定する。なお、閾値の値はこれに限定されるものではなく、任意に変更可能である。

また、稼動監視部３８は、リソース容量と、リソース利用量とをマスターノード２０に通信部３２を介して送信する。例えば、稼動監視部３８は、自装置の「スレーブノードＩＤ」と、「リソース容量」と、「リソース利用量」とを含んだ情報をマスターノード２０に送信する。

リソース抑制部３９は、稼動監視部３８から枯渇しているリソースのリソースＩＤを受け付ける。あるいは、リソース抑制部３９は、マスターノード２０から受信したリソース抑制通知からリソースＩＤを抽出する。

続いて、リソース抑制部３９は、指定されたリソースＩＤをもとに、最もリソースを消費しているプロセスを稼動監視部３８から取得する。そして、リソース抑制部３９は、利用を抑制すべきリソースＩＤをキーに、リソースを消費しているプロセスの全スレッドに影響してリソース利用を一定期間抑制する。例えば、リソース抑制部３９は、ＡＰＩ処理部３５、カーネル部３６及びドライバ部３７のいずれかに介在して、プロセスがリソースを利用することを抑制する。

次に、リソース抑制部３９によるリソースを抑制する処理を詳細に説明する。リソース抑制部３９は、処理プログラムの変更を行わず、またＯＳ（Operating System）のタイムシェアリングシステムなどの処理優先部分に影響を与えずに、抑制対象である処理プロセスとＯＳとの間に介在する。リソース抑制部３９による介在方式は、実装するＯＳによって異なる。ここではサービス系処理を行う代表的なＯＳである、Ｗｉｎｄｏｗｓ（登録商標）とＬｉｎｕｘ（登録商標）とを例に挙げて説明する。

（Ｗｉｎｄｏｗｓの処理）
例えば、リソース抑制部３９は、ＯｐｅｎＴｈｒｅａｄ関数を用いて、リソース消費の高いプロセスのスレッド状態を把握し、スレッド単位に短期間のサスペンドとレジュームとを繰り返し実行する。リソース抑制部３９は、抑制対象プロセスのサスペンドを実行するので、必ず当該プロセスに対する単位時間あたりのリソース利用負荷は１００％未満になる。例えば１秒間のうち１０ｍｓの間介在すると１％のリソース抑制になる。

また、リソース抑制部３９は、全てのプロセスのＡＰＩの利用をフックする。例えば、リソース抑制部３９は、ＳｅｔＷｉｎｄｏｗｓＨｏｏｋＥｘなどで全てのプロセスのＷｉｎｄｏｗｓ ＡＰＩの利用をフックする。一例を挙げると、リソース抑制部３９は、プロセス群３４がＡＰＩ処理部３５に要求した利用要求を取得して保持する。そして、リソース抑制部３９は、リソースＩＤのリソースを消費するＷｉｎｄｏｗｓ ＡＰＩ毎の代替ＡＰＩ関数処理を実行する。すなわち、リソース抑制部３９は、抑制係数×Ｎミリ秒スリープしてから、ＡＰＩ処理部３５に制御を引き渡す。

（Ｌｉｎｕｘの処理）
リソース抑制部３９は、フックモジュールを用いて、リソースを消費するｏｐｅｎ、ｃｌｏｓｅ、ｒｅａｄ、ｗｒｉｔｅ、ｆｏｒｋ、ｍｍａｐなどのシステムコールを監視し、該当するプロセスのシステムコール毎に短期間のスリープを行う。一例を挙げると、リソース抑制部３９は、ＡＰＩ処理部３５がカーネル部３６に要求したシステムコールを取得して保持する。リソース抑制部３９は、抑制対象プロセスのスリープを実行するので、必ず当該プロセスに対する単位時間あたりのリソース利用負荷は１００％未満になる。例えば、リソース抑制部３９は、１秒間のうち１０ｍｓの間介在すると１％のリソースを抑制することになる。リソース抑制部３９は、所定時間スリープした後に、カーネル部３６にシステムコールの制御を引き渡す。

［処理手順］
次に図６〜１２を用いて、処理の処理手順を説明する。ここでは、図６を用いて、マスターノードによる処理の処理手順を説明し、図７〜図１２を用いてスレーブノードによる処理の処理手順を説明する。

（マスターノードによる処理の処理手順）
図６を用いて、マスターノードによる処理の処理手順を説明する。図６は、マスターノードによる処理の処理手順を説明するフローチャートである。図６に示すように、マスターノード２０は、スレーブノード３０〜５０からリソース容量とリソース利用量とを取得したことを契機に処理を実行する。

通信部２２は、スレーブノード３０〜５０からリソース容量とリソース利用量とを受信する（ステップＳ１０１）。そして、全体監視部２４は、通信部２２によって受信された各スレーブノード３０〜５０のリソース容量から、システムのリソース総容量を算出する（ステップＳ１０２）。また、全体監視部２４は、通信部２２によって受信された各スレーブノード３０〜５０のリソース利用量から、システムのリソース利用量を算出する（ステップＳ１０３）。

全体監視部２４は、算出したシステムのリソース総容量とリソース利用量とをリソース利用状況テーブル２１ｂに格納する（ステップＳ１０４）。特定部２５は、抑制フラグをおろし（ステップＳ１０５）、あるリソースについてシステムのリソース総容量が枯渇傾向にあるか否かを判定する（ステップＳ１０６）。

ここで、特定部２５は、あるリソースについてシステムのリソース総容量が枯渇傾向にあると判定した場合（ステップＳ１０６、Ｙｅｓ）、抑制フラグをたて（ステップＳ１０７）、ステップＳ１０８の処理に移行する。一方、特定部２５は、あるリソースについてシステムのリソース総容量が枯渇傾向にないと判定した場合（ステップＳ１０６、Ｎｏ）、ステップＳ１０８の処理に移行する。

特定部２５は、リソースの利用量についてスレーブノード間で偏りがあるか否かを判定する（ステップＳ１０８）。ここで、特定部２５は、リソースの利用量についてスレーブノード間で偏りがあると判定した場合（ステップＳ１０８、Ｙｅｓ）、抑制フラグをたて（ステップＳ１０９）、ステップＳ１１０の処理に移行する。一方、特定部２５は、リソースの利用量についてスレーブノード間で偏りがないと判定した場合（ステップＳ１０８、Ｎｏ）、ステップＳ１１０の処理に移行する。

特定部２５は、抑制フラグがたっているか否かを判定する（ステップＳ１１０）。ここで、特定部２５は、抑制フラグがたっていると判定した場合（ステップＳ１１０、Ｙｅｓ）、より多くリソースを消費しているスレーブノードに対してリソース抑制通知を発行し、通信部２２を介して送信し（ステップＳ１１１）、ステップＳ１０１に移行する。一方、特定部２５は、抑制フラグがたっていないと判定した場合（ステップＳ１１０、Ｎｏ）、ステップＳ１０１に移行する。

（スレーブノードによる処理の処理手順）
図７は、スレーブノードによる処理の処理手順を説明するフローチャートである。例えば、スレーブノード３０〜５０は、所定の時間が経過したことを契機に処理を実行する。なお、スレーブノード３０〜５０による処理手順は同様であるので、ここでは、スレーブノード３０を例にして処理手順を説明する。

図７に示すように、稼動監視部３８は、自ノードが保有するリソース容量を取得し（ステップＳ２０１）、全プロセスのリソース利用量を取得する（ステップＳ２０２）。そして、稼動監視部３８は、自ノード内のリソース容量が枯渇傾向にあるか否かを判定する（ステップＳ２０３）。

ここで、稼動制御部３４は、自ノード内のリソース容量が枯渇傾向にあると判定した場合（ステップＳ２０３、Ｙｅｓ）、枯渇しているリソースのリソースＩＤをリソース抑制部に通知する（ステップＳ２０４）。リソース抑制部３９は、通知されたリソースＩＤを利用するプロセスに対して、一定量のリソース利用を抑制する処理を実行する（ステップＳ２０５）。なお、この処理の詳細は後述する。

ステップＳ２０５の処理が終了後、または、稼動制御部３４によって自ノード内のリソース容量が枯渇傾向にないと判定された場合（ステップＳ２０３、Ｎｏ）、通信部３２は、リソース容量とリソース利用量とをマスターノード２０へ送信する（ステップＳ２０６）。ステップＳ２０６が終了後、スレーブノード３０はステップＳ２０１に移行し、以降の処理を継続して実行する。

（スレーブノードによる抑制処理の処理手順）
次に、図８を用いて、スレーブノードによる抑制通知受信処理の処理手順を説明する。図８は、スレーブノードによる抑制処理の処理手順を示すフローチャートである。図８に示すように、スレーブノード２０からリソース抑制通知を受信したことを契機に処理を実行する。

通信部３２によって、マスターノード２０からリソース抑制通知を受信された場合（ステップＳ３０１、Ｙｅｓ）、リソース抑制部３９は、通知されたリソースＩＤを利用するプロセスに対して、一定量のリソース利用を抑制する処理を実行する（ステップＳ３０２）。なお、この処理の詳細は後述する。

（リソース抑制処理）
次に、図９を用いて、スレーブノードによる抑制処理の処理手順を説明する。図９は、スレーブノードによる抑制処理の処理手順を示すフローチャートである。図９に示すように、スレーブノードは、稼動監視部３８によってリソースを抑制することを通知されたことを契機に処理を実行する。なお、ここで説明する処理は、図７のステップＳ２０５及び図８のステップＳ３０２に対応する処理である。

リソース抑制部３９は、抑制中リストを初期化し（ステップＳ４０１）、抑制要求があるか否かを判定する（ステップＳ４０２）。ここで、リソース抑制部３９は、抑制要求があると判定した場合（ステップＳ４０２、Ｙｅｓ）、抑制対象のプロセスＩＤとリソースＩＤとを受信する（ステップＳ４０３）。一方、リソース抑制部３９は、抑制要求がないと判定した場合（ステップＳ４０２、Ｎｏ）、ステップＳ４１３の処理に移行する。

続いて、リソース抑制部３９は、抑制中リスト内に指定されたプロセスＩＤが存在するか否かを判定する（ステップＳ４０４）。ここで、リソース抑制部３９は、抑制中リスト内に指定されたプロセスＩＤが存在しないと判定した場合（ステップＳ４０４、Ｎｏ）、抑制中リストに指定されたプロセスＩＤのレコードを追加し（ステップＳ４０５）、ステップＳ４０６に移行する。一方、リソース抑制部３９は、抑制中リスト内に指定されたプロセスＩＤが存在すると判定した場合（ステップＳ４０４、Ｙｅｓ）、ステップＳ４０６に移行する。すなわち、リソース抑制部３９は、抑制中リスト内の指定されたプロセスＩＤに対し、指定されたリソースＩＤが存在するか否かを判定する（ステップＳ４０６）。

ここで、リソース抑制部３９は、抑制中リスト内の指定されたプロセスＩＤに対し、指定されたリソースＩＤが存在しないと判定した場合（ステップＳ４０６、Ｎｏ）、以下の処理を実行する。すなわち、リソース抑制部３９は、抑制中リストのプロセスＩＤが一致するレコードにリソースＩＤをセットして更新し（ステップＳ４０７）、ステップＳ４０８に移行する。一方、リソース抑制部３９は、抑制中リスト内の指定されたプロセスＩＤに対し、指定されたリソースＩＤが存在すると判定した場合（ステップＳ４０６、Ｙｅｓ）、ステップＳ４０８に移行する。

リソース抑制部３９は、抑制中リストのリソースＩＤに対する抑制係数を加算して、レコードを更新し（ステップＳ４０８）、プロセスＩＤに該当するプロセスが存在するか否かを判定する（ステップＳ４０９）。ここで、リソース抑制部３９は、プロセスＩＤに該当するプロセスが存在しないと判定した場合（ステップＳ４０９、Ｎｏ）、抑制中リストの当該レコードを削除し（ステップＳ４１０）、ステップＳ４０９に移行する。

リソース抑制部３９は、プロセスＩＤに該当するプロセスが存在すると判定した場合（ステップＳ４０９、Ｙｅｓ）、抑制処理を実行する（ステップＳ４１１）。なお、抑制処理の詳細は後述する。続いて、リソース抑制部３９は、抑制中リストレコード数分、抑制したか否かを判定する（ステップＳ４１２）。

リソース抑制部３９は、抑制中リストレコード数分、抑制していないと判定した場合（ステップＳ４１２、Ｎｏ）、ステップＳ４０９に移行する。一方、リソース抑制部３９は、抑制中リストレコード数分、抑制したと判定した場合（ステップＳ４１２、Ｙｅｓ）、処理を終了するか否かを判定する（ステップＳ４１３）。

リソース抑制部３９は、処理を終了しないと判定した場合（ステップＳ４１３、Ｎｏ）、ステップＳ４０２に移行する。一方、リソース抑制部３９は、処理を終了すると判定した場合（ステップＳ４１３、Ｙｅｓ）、リソース抑制処理を終了する。

（Ｓｕｓｐｅｎｄ/Ｒｅｓｕｍｅ処理）
図１０は、Ｓｕｓｐｅｎｄ／Ｒｅｓｕｍｅ ＴｈｒｅａｄによるＣＰＵ負荷抑制処理の処理手順を示すフローチャートである。図１０に示すように、リソース抑制部３９は、ＯｐｅｎＴｈｒｅａｄ関数などで対象プロセスのスレッドハンドルを取得する（ステップＳ５０１）。そして、リソース抑制部３９は、ＳｕｓｐｅｎｄＴｈｒｅａｄ関数でスレッドをサスペンドさせ（ステップＳ５０２）、全スレッド数分の処理を繰り返したか否かを判定する（ステップＳ５０３）。

リソース抑制部３９は、全スレッド数分の処理を繰り返していないと判定した場合（ステップＳ５０３、Ｎｏ）、ステップＳ５０２に移行する。一方、リソース抑制部３９は、全スレッド数分の処理を繰り返したと判定した場合（ステップＳ５０３、Ｙｅｓ）、抑制係数×Ｎミリ秒スリープする（ステップＳ５０４）。

そして、リソース抑制部３９は、ＲｅｓｕｍｅＴｈｒｅａｄ関数でスレッドをレジュームさせ（ステップＳ５０５）、全スレッド数分の処理を繰り返したか否かを判定する（ステップＳ５０６）。ここで、リソース抑制部３９は、全スレッド数分の処理を繰り返していないと判定した場合（ステップＳ５０６、Ｎｏ）、ステップＳ５０５に移行する。一方、リソース抑制部３９は、全スレッド数分の処理を繰り返したと判定した場合（ステップＳ５０６、Ｙｅｓ）、処理を終了する。

（ＡＰＩフック）
図１１は、ＡＰＩによるＩ／Ｏ利用抑制処理を示すシーケンス図である。図１１に示すように、リソース抑制部３９は、全てのＡＰＩの利用をフックする（ステップＳ６０１）。例えば、リソース抑制部３９は、ＳｅｔＷｉｎｄｏｗｓ（登録商標）ＨｏｏｋＥｘなどで全てのプロセスのＡＰＩの利用をフックする。

また、抑制対象プロセスは、内部処理を実行し（ステップＳ６０２）、ＡＰＩをコールする（ステップＳ６０３）。そして、リソース抑制部３９は、リソースＩＤのリソースを消費するＡＰＩ毎の代替ＡＰＩ関数処理を実行する。すなわち、リソース抑制部３９は、フックしたプロセスのうち、抑制対象であるリソースを利用するプロセスに対して、抑制係数×Ｎミリ秒スリープしてＡＰＩ処理部３５に引き渡す（ステップＳ６０４）。続いて、抑制対象プロセスは、内部処理を実行し（ステップＳ６０５）、処理を終了する。

（Ｋｅｒｎｅｌフック）
図１２は、ＫｅｒｎｅｌフックによるＩ／Ｏ利用抑制処理を示すシーケンス図である。図１２に示すように、抑制対象プロセスは、内部処理を実行し（ステップＳ７０１）、システムコールをコールする（ステップＳ７０２）。そして、リソース抑制部３９は、リソースＩＤのリソースを消費するシステムコール毎の関数処理を実行する。すなわち、リソース抑制部３９は、抑制係数×Ｎミリ秒スリープして、カーネル部３６に引き渡す（ステップＳ７０３）。続いて、抑制対象プロセスは、内部処理を実行し（ステップＳ７０４）、処理を終了する。

［実施例１の効果］
上述してきたように、実施例１では、処理動作中に利用するリソース量を外部からプロセス単位で抑制することができる。

また、実施例１では、稼動監視部３８によって、スレーブノードがリソース不足に陥ったと判定された場合、リソース抑制部３９は、プロセスのＣＰＵ利用を単位時間あたりで抑制して、他のプロセスの動作を行うための余剰リソースを確保する。

また、実施例１では、緩やかな負荷増加傾向や偏りは、マスターノードの全体監視部２４が察知し、全体的な余剰リソースを確保する。このように、実施例１に係るコンピュータシステム１は、負荷分散することなく、プロセスにリソース容量以上のリソースを利用させない。

また、実施例１では、Ｉ／Ｏ負荷の高いプロセスを特定し、そのプロセスを短期間にサスペンド／レジュームさせることで、単位時間あたりのＩ／Ｏ要求を減らすことができる。

また、実施例１では、マスターノードがスレーブノードの送出するパケット量をネットワークリソースとして監視し、スレーブノード内外の過負荷や不均衡を検出する。そして、リソース抑制部３９は、スレーブノードのプロセス単位にリソースを抑制するので、Ｌ３スイッチやルーターではできなかった、優先度の異なる同種のサービスをアプリケーション側で制御できる。

実施例１では、リソース利用容量が枯渇傾向にあるか否かを判定し、枯渇傾向あると判定した場合に、リソースの利用を抑制する例について説明した。ところで、コンピュータシステムにおいて、ＣＰＵリソースを消費せずに省電力モードでコンピュータを動作させる場合がる。このように省電力モードでコンピュータを動作させる場合、ＳＬＡやコンピュータアーキテクチャ毎に異なる動作条件を処理プログラム自身で解決することが困難であった。そこで、実施例２では、省電力モードに設定されたスレーブノードにおいて、所定の閾値を超えるリソースを利用した場合に、リソースの利用を抑制する例について説明する。

［実施例２に係るシステムの構成］
実施例２にシステムの構成は、図１に示したシステム構成を同様である。また、マスターノードの構成については、図２に示した構成と同様であり、スレーブノードの構成については、図５に示した構成と同様である。相違する点は、目標利用量として設定する閾値の値が、リソースが枯渇傾向にあるか否かを判定する閾値の値よりも低い値に設定されることである。例えば、目標利用量として設定する閾値の値は、「３０％」に設定される。なお、目標利用量として設定する閾値の値は、この値に限定されるものではなく、ユーザが任意の値に変更可能である。

［処理の処理手順］
実施例２の処理の処理手順では、実施例１とは異なる処理手順についてのみ説明する。次に図１３を用いて、実施例２に係るマスターノードによる処理の処理手順を説明する。図１３は、実施例２に係るマスターノードによる処理の処理手順を示すフローチャートである。図１３に示すステップＳ８０１の処理からステップＳ８０５までの処理は、図６に示したステップＳ１０１からステップＳ１０５までの処理と同様であるので、ここでは、ステップＳ８０１の処理からステップＳ８０５までの処理についての説明を省略する。

特定部２５は、リソース利用量について、スレーブノードの利用が目標利用量より多いか否かを判定する（ステップＳ８０６）。ここで、特定部２５は、リソース利用量について、スレーブノードの利用が目標利用量より多いと判定した場合（ステップＳ８０６、Ｙｅｓ）、抑制フラグをたて（ステップＳ８０７）、ステップＳ８０８の処理に移行する。一方、特定部２５は、リソース利用量について、スレーブノードの利用が目標利用量より多くないと判定した場合（ステップＳ８０６、Ｎｏ）、ステップＳ８０８の処理に移行する。

特定部２５は、抑制フラグがたっているか否かを判定する（ステップＳ８０８）。ここで、特定部２５は、抑制フラグがたっていると判定した場合（ステップＳ８０８、Ｙｅｓ）、より多くリソースを消費しているスレーブノードに対してリソース抑制通知を発行し、通信部２２を介して送信し（ステップＳ８０９）、ステップＳ８０１に移行する。一方、特定部２５は、抑制フラグがたっていないと判定した場合（ステップＳ８０８、Ｎｏ）、ステップＳ８０１に移行する。

次に、図１４を用いて、実施例２に係るスレーブノードによる処理の処理手順を説明する。図１４は、実施例２に係るスレーブノードによる処理の処理手順を示すフローチャートである。

図１４に示すように、通信部３２によって、マスターノード２０からリソース抑制通知を受信された場合（ステップＳ９０１、Ｙｅｓ）、リソース抑制部３９は、指定されたリソースＩＤの抑制量が目標値に達しているか否かを判定する（ステップＳ９０２）。

ここで、リソース抑制部３９は、指定されたリソースＩＤの抑制量が目標値に達していないと判定した場合（ステップＳ９０２、Ｎｏ）、指定されたリソース容量を消費または占有しているプロセスに対してリソース利用を抑制し（ステップＳ９０３）、ステップＳ９０２に移行する。一方、リソース抑制部３９は、指定されたリソースＩＤの抑制量が目標値に達していると判定した場合（ステップＳ９０２、Ｙｅｓ）、ステップＳ９０１に移行する。なお、ステップＳ９０３の処理は、図９〜図１２で説明した処理を適宜実行する。

［実施例２の効果］
上述してきたように、実施例２では、利用量に目標値を設定し、ＣＰＵの負荷を抑制するので、省電力モードに移行させることができる。

例えば、実施例２では、マスターノードがスレーブノードに対しＣＰＵのリソース利用に対し目標閾値を設定して送付し、スレーブノード内での稼動監視が目標値に達するまで処理負荷の高いプロセスを抽出し、リソース抑制部がそれを抑制することができる。

また、実施例２では、スレーブノード内で動作中の処理負荷の高いもののみを抑制するので、システム全体として処理を継続しつつも、処理負荷を低減する。この結果、実施例２に係るスレーブノードは、ＣＰＵを省電力モードに移行させることができる。

ところで、本発明は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例３では、本発明に含まれる他の実施例について説明する。

（システム構成等）
実施例１及び実施例２において説明した各処理のうち自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文章中や図面中で示した処理手順、制御手順、具体的名称については、特記する場合を除いて任意に変更することができる。

また、図示した記憶部が格納する情報は一例に過ぎず、必ずしも図示のごとく情報が格納される必要はない。

また、各種の負荷や利用状況などに応じて、各実施例において説明した各処理の各ステップでの処理の順番を変更してもよい。例えば、図６に示すステップＳ１０２とステップＳ１０３との順番を入れ替えても良く、また、ステップＳ１０２とステップＳ１０３との処理を並行して実行してもよい。

また、図示した各構成部は、機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。例えば、マスターノード２０の全体監視部２４と特定部２５とは統合されてもよい。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（プログラム）
ところで、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。

図１５は、リソース監視プログラムを実行するコンピュータを示す図である。図１５に示すように、コンピュータ３００は、利用者からデータや各種設定などを受け付ける入力装置３１０と、コンピュータの状況などを通知する出力装置３２０とを有する。また、コンピュータ３００は、他の装置とデータを送受信するネットワークインターフェース３３０と媒体読取装置３４０とＨＤＤ３５０とＲＡＭ３６０とＣＰＵ３７０とバス３８０とを有する。そして、各装置３１０〜３７０それぞれは、バス３８０に接続される。

ここで、図１５に示すように、ＨＤＤ３５０には、図２に示した、全体監視部２４と特定部２５と同様の機能を発揮するリソース監視プログラム３５１が予め記憶されている。また、媒体読取装置３４０は、リソース監視プログラム３５１を実現するための各種データを記憶する。この各種データは、例えば、図２に示した、リソース識別テーブル２１ａやリソース利用状況テーブル２１ｂを含む。そして、ＣＰＵ３７０は、リソース監視プログラム３５１をＲＡＭ３６０に展開して、リソース監視プロセス３７１として実行する。すなわち、リソース監視プロセス３７１は、図２に示した、全体監視部２４と特定部２５と同様の動作を実行する。

図１６は、抑制通知プログラムを実行するコンピュータを示す図である。図１６に示すように、コンピュータ４００は、利用者からデータや各種設定などを受け付ける入力装置４１０と、コンピュータの状況などを通知する出力装置４２０とを有する。また、コンピュータ４００は、他の装置とデータを送受信するネットワークインターフェース４３０と媒体読取装置４４０とＨＤＤ４５０とＲＡＭ４６０とＣＰＵ４７０とバス４８０とを有する。そして、各装置４１０〜４７０それぞれは、バス４８０に接続される。

ここで、図１６に示すように、ＨＤＤ４５０には、図５に示した、稼動監視部３８及びリソース抑制部３９と同様の機能を発揮するリソース抑制プログラム４５１が予め記憶されている。また、媒体読取装置４４０は、リソース抑制プログラム４５１を実現するための各種データを記憶する。この各種データは、例えば、図５に示した、リソース識別テーブル３１ａやリソース利用状況テーブル３１ｂを含む。そして、ＣＰＵ４７０は、リソース抑制プログラム４５１をＲＡＭ４６０に展開して、リソース抑制プロセス４７１として実行する。すなわち、リソース抑制プロセス４７１は、図５に示した、稼動監視部３８及びリソース抑制部３９と同様の動作を実行する。

ところで、上記したリソース監視プログラム３５１は、必ずしもＨＤＤ３５０に記憶させておく必要はない。同様に抑制通知プログラム４５１は、必ずしもＨＤＤ４５０に記憶させておく必要はない。例えば、コンピュータ３００や４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に記憶させておくようにしてもよい。また、コンピュータ３００や４００の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」に記憶させておいてもよい。さらに、公衆回線、インターネット、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などを介してコンピュータ３００に接続される「他のコンピュータシステム」に記憶させておいてもよい。そして、コンピュータ３００がこれらからプログラムを読み出して実行するようにしてもよい。

すなわち、このプログラムは、上記した「可搬用の物理媒体」、「固定用の物理媒体」、「通信媒体」などの記録媒体に、コンピュータ読み取り可能に記憶されるものである。そして、コンピュータ３００や４００は、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータ３００や４００によって実行されることに限定されるものではない。例えば、他のコンピュータシステムまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

１ コンピュータシステム
２ ハブ・スポーク型ネットワーク
２０ マスターノード
２１ 記憶部
２１ａ リソース識別テーブル
２１ｂ リソース利用状況テーブル
２２ 通信部
２３ 制御部
２４ 全体監視部
２５ 特定部
３０〜５０ スレーブノード
３１ 記憶部
３２ 通信部
３３ 制御部
３４ プロセス群
３５ ＡＰＩ処理部
３６ カーネル部
３７ ドライバ部
３８ 稼動監視部
３９ リソース抑制部

Claims (11)

1. コンピュータに、
   自装置のリソースの容量とリソースの利用量とを取得し、
   前記取得されたリソースの容量とリソースの利用量とを監視装置に送信し、
   前記送信されたリソースの容量とリソースの利用量とに基づいて、前記監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、前記リソースの利用量を抑制することを示す抑制通知を前記監視装置から受信し、
   前記受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定し、
   前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定されたプロセスからの利用要求を取得し、
   前記取得した利用要求を保持し、
   前記利用要求を保持する時間が所定時間経過した後に、前記保持する利用要求を前記管理装置に出力する
   処理を実行させることを特徴とするリソース抑制プログラム。
2. 前記取得する処理は、前記特定されたプロセスのＡＰＩの利用をフックして取得し、保持することを特徴とする請求項１に記載のリソース抑制プログラム。
3. 前記取得する処理は、前記特定されたプロセスのドライバの利用をフックして取得し、保持することを特徴とする請求項１に記載のリソース抑制プログラム。
4. 前記取得する処理は、前記特定されたプロセスのスレッドハンドルを、ＯｐｅｎＴｈｒｅａｄ関数を用いて取得し、保持することを特徴とする請求項１に記載のリソース抑制プログラム。
5. コンピュータに、
   自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得し、
   前記取得した複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定し、
   前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成し、
   前記生成した抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定した情報処理装置に送信する
   処理を実行させることを特徴とするリソース監視プログラム。
6. コンピュータに
   前記リソースの総利用量が所定の閾値を超えていないと判定した場合に、前記複数の情報処理装置間で利用するリソースの利用量に偏りがあるか否かを判定する処理を更に実行させ、
   前記生成する処理は、前記リソースの利用量に偏りがあると判定された場合に、前記利用量に偏りがあるリソースの利用量を抑制することを示す抑制通知を生成することを特徴とする請求項５に記載のリソース監視プログラム。
7. 自装置のリソースの容量とリソースの利用量とを取得する第１取得部と、
   前記第１取得部によって取得されたリソースの容量とリソースの利用量とを監視装置に送信する送信部と、
   前記送信部によって送信されたリソースの容量とリソースの利用量とに基づいて、前記監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、前記リソースの利用量を抑制することを示す抑制通知を前記監視装置から受信する受信部と、
   前記受信部によって受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する特定部と、
   前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定部によって特定されたプロセスからの利用要求を取得する第２取得部と、
   前記第２取得部によって取得された利用要求を保持する保持部と、
   前記保持部によって利用要求が保持される時間が所定時間経過した後に、前記保持される利用要求を前記管理装置に出力する出力部と
   を有することを特徴とするリソース抑制装置。
8. 自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得する取得部と、
   前記取得部によって取得された複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する判定部と、
   前記判定部によってリソースの総利用量が所定の閾値を超えたと判定された場合、前記リソースの利用量を抑制することを示す抑制通知を生成する生成部と、
   前記生成部によって生成された抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定した情報処理装置に送信する送信部と
   を有することを特徴とするリソース監視装置。
9. コンピュータが、
   自装置のリソースの容量とリソースの利用量とを取得し、
   前記取得されたリソースの容量とリソースの利用量とを監視装置に送信し、
   前記送信されたリソースの容量とリソースの利用量とに基づいて、前記監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、前記リソースの利用量を抑制することを示す抑制通知を前記監視装置から受信し、
   前記受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定し、
   前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定されたプロセスからの利用要求を取得し、
   前記取得した利用要求を保持し、
   前記利用要求を保持する時間が所定時間経過した後に、前記保持する利用要求を前記管理装置に出力する
   処理を実行することを特徴とするリソース抑制方法。
10. コンピュータが、
    自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得し、
    前記取得した複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定し、
    前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成し、
    前記生成した抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定した情報処理装置に送信する
    処理を実行することを特徴とするリソース監視方法。
11. プロセスを実行する情報処理装置と、前記情報処理装置を接続される監視装置とを有するシステムであって、
    前記情報処理装置は、
    自装置のリソースの容量とリソースの利用量とを取得する第１取得部と、
    前記第１取得部によって取得されたリソースの容量とリソースの利用量とを前記監視装置に送信する送信部と、
    前記送信部によって送信されたリソースの容量とリソースの利用量とに基づいて、前記監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、前記リソースの利用量を抑制することを示す抑制通知を前記監視装置から受信する受信部と、
    前記受信部によって受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する特定部と、
    前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定部によって特定されたプロセスからの利用要求を取得する第２取得部と、
    前記第２取得部によって取得された利用要求を保持する保持部と、
    前記保持部によって利用要求を保持される時間が所定時間経過した後に、前記保持される利用要求を前記管理装置に出力する出力部と
    を有し、
    前記監視装置は、
    前記情報処理装置が有するリソースの容量と前記リソースの利用量とを取得する取得部と、
    前記取得した前記情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する判定部と、
    前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成する生成部と、
    前記生成した抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定した情報処理装置に送信する送信部と
    を有することを特徴とするリソース抑制システム。

Images