コンピュータに、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定し、前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定されたプロセスからの利用要求を取得し、前記取得した利用要求を保持し、前記利用要求を保持する時間が所定時間経過した後に、前記保持する利用要求を前記管理装置に出力する処理を実行させることを特徴とするリソース抑制プログラム。前記取得する処理は、前記特定されたプロセスのAPIの利用をフックして取得し、保持することを特徴とする請求項1に記載のリソース抑制プログラム。前記取得する処理は、前記特定されたプロセスのドライバの利用をフックして取得し、保持することを特徴とする請求項1に記載のリソース抑制プログラム。前記取得する処理は、前記特定されたプロセスのスレッドハンドルを、OpenThresd関数を用いて取得し、保持することを特徴とする請求項1に記載のリソース抑制プログラム。コンピュータに、自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得し、前記取得した複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定し、前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成し、前記生成した抑制通知を前記情報処理装置に送信する処理を実行させることを特徴とするリソース監視プログラム。コンピュータに前記リソースの総利用量が所定の閾値を超えていないと判定した場合に、前記複数の情報処理装置間で利用するリソースの利用量に偏りがあるか否かを判定する処理を更に実行させ、前記生成する処理は、前記リソースの利用量に偏りがあると判定された場合に、前記利用量に偏りがあるリソースの利用量を抑制することを示す抑制通知を生成することを特徴とする請求項5に記載のリソース監視プログラム。利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する特定部と、前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定部によって特定されたプロセスからの利用要求を取得する取得部と、前記取得部によって取得された利用要求を保持する保持部と、前記保持部によって利用要求が保持される時間が所定時間経過した後に、前記保持される利用要求を前記管理装置に出力する出力部とを有することを特徴とするリソース抑制装置。自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得する取得部と、前記取得部によって取得された複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する判定部と、前記判定部によってリソースの総利用量が所定の閾値を超えたと判定された場合、前記リソースの利用量を抑制することを示す抑制通知を生成する生成部と、前記生成部によって生成された抑制通知を前記リソースの総利用量が所定の閾値を超えた情報処理装置に送信する送信部とを有することを特徴とするリソース監視装置。コンピュータが、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定し、前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定されたプロセスからの利用要求を取得し、前記取得した利用要求を保持し、前記利用要求を保持する時間が所定時間経過した後に、前記保持する利用要求を前記管理装置に出力する処理を実行することを特徴とするリソース抑制方法。コンピュータが、自装置と接続された複数の情報処理装置それぞれから前記複数の情報処理装置それぞれが有するリソースの容量と前記リソースの利用量とを取得し、前記取得した複数の情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定し、前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成し、前記生成した抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定された情報処理装置に送信する処理を実行することを特徴とするリソース監視方法。プロセスを実行する情報処理装置と、前記情報処理装置を接続される監視装置とを有するシステムであって、前記情報処理装置は、自装置のリソースの容量とリソースの利用量とを取得する第1取得部と、前記第1取得部によって取得されたリソースの容量とリソースの利用量とを前記監視装置に送信する送信部と、前記送信部によって送信されたリソースの容量とリソースの利用量とに基づいて、前記監視装置によって自装置が利用するリソースが抑制対象であると判定された場合に、前記リソースの利用量を抑制することを示す抑制通知を前記監視装置から受信する受信部と、前記受信部によって受信された抑制通知に基づいて、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する特定部と、前記リソースの利用を管理する管理装置を送信先とした前記リソースの利用要求のうち、前記特定部によって特定されたプロセスからの利用要求を取得する第2取得部と、前記第2取得部によって取得された利用要求を保持する保持部と、前記保持部によって利用要求を保持される時間が所定時間経過した後に、前記保持される利用要求を前記管理装置に出力する出力部とを有し、前記監視装置は、前記情報処理装置が有するリソースの容量と前記リソースの利用量とを取得する取得部と、前記取得した前記情報処理装置が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する判定部と、前記リソースの総利用量が所定の閾値を超えたと判定した場合、前記リソースの利用量を抑制することを示す抑制通知を生成する生成部と、前記生成した抑制通知を前記リソースの総利用量が所定の閾値を超えたと判定した情報処理装置に送信する送信部とを有することを特徴とするリソース抑制システム。しかしながら、上述した従来の技術では、処理動作中に利用するリソース量を外部から抑制することができないという課題があった。近年はマルチメディアなどの大量なデータを高速に処理し、多数のクライアントにサービスを提供することが求められている。例えば、映像の形式を変換するメディア処理のプログラムは、大量なデータを長時間取り扱うので、1トランザクションあたりのスループットを高めるために、CPUリソースを最大限に利用する。このため、メディア処理のプログラムによってCPUリソースが使い切られてしまい、通信のためのプロセスなどの他のプロセスは、十分な性能で動作することができなくなる。また、仮想化技術を利用したコンピュータリソースの効率的な運用方法として、異なるユーザを同居させたマルチテナントで物理的なリソースを共有するクラウドコンピューティングがある。クラウドコンピューティングでは、異なるユーザAとユーザBとでハードディスクを共有するが、互いのユーザは、相手のディスクにはアクセスできないようにセキュリティが保証されている。また、互いのユーザは、相互にアクセスを調停することもできない。このため、例えば、ユーザAがハードディスクを長時間利用中に、ユーザBもハードディスクにアクセスした場合、ユーザBは、ユーザAがアクセスを終了するまでハードディスクへアクセスできない。この結果、ユーザBのCPUは、ユーザAがハードディスクへのアクセスを終了するまで動作できなくなり、他のプロセスを処理できなくなる。このようなことから、ユーザAによるハードディスクへのアクセスを抑制することが望まれる。また、クラウドコンピューティングでは、ネットワークの組み替えを論理的に行うためにVLANVirtualLocalAreaNetworkを用いて同じ物理ケーブル内で他のネットワークセグメントを共有することが多い。このため、ゲストマシンAがネットワーク帯域に余裕があると判定しても、既に他のゲストマシBンが物理帯域を使い切っており、リソースが枯渇していることがある。このような場合、ゲストマシンAは、ネットワーク帯域を利用できなくなる。開示の技術は、上記に鑑みてなされたものであって、処理動作中に利用するリソース量を外部から抑制することができるリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムを提供することを目的とする。本願の開示するリソース抑制プログラムは、一つの態様において、利用量が所定の閾値を超えるリソースを最も利用するプロセスを特定する。また、リソース抑制プログラムは、リソースの利用を管理する管理装置を送信先としたリソースの利用要求のうち、特定したプロセスからの利用要求を取得する。そして、リソース抑制プログラムは、取得した利用要求を保持し、利用要求を保持する時間が所定時間経過した後に、保持する利用要求を管理装置に出力する。本願の開示するリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムの一つの態様によれば、処理動作中に利用するリソース量を外部から抑制することができるという効果を奏する。以下に、本願の開示するリソース抑制プログラム、リソース監視プログラム、リソース抑制装置、リソース監視装置、リソース抑制方法、リソース監視方法及びリソース抑制システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。実施例1では、図1から図12を用いて、コンピュータシステムの全体構成、マスターノードの構成、スレーブノードの構成、処理の処理手順、実施例1による効果を順に説明する。[コンピュータシステムの全体構成]図1は、コンピュータシステムの構成例を示す図である。図1に示すように、コンピュータシステム1は、マスターノード20とスレーブノード30~50とを有する。ここで、マスターノード20は、システムに1台存在するコンピュータであり、監視装置の一例である。スレーブノード30~50は、システムに1台以上存在するコンピュータであり、情報処理装置の一例である。マスターノード20と、スレーブノード30~50とは、ハブスポーク型ネットワーク2で互いに通信可能に接続されている。なお、マスターノード20と、スレーブノード30~50との接続は、ハブスポーク型ネットワーク2に限定されるものではなく、IPInternetProtocolネットワークに接続されていれば他の接続形態であってもよい。このようなコンピュータシステム1において、スレーブノード30~50は、自装置のリソースの容量とリソースの利用量とを取得し、取得したリソースの容量とリソースの利用量とをマスターノード20に送信する。マスターノード20は、自装置と接続された複数のスレーブノード30~50それぞれから複数のスレーブノード30~50それぞれが有するリソースの容量とリソースの利用量とを取得する。マスターノード20は、取得した複数のスレーブノード30~50が利用するリソースの総利用量が所定の閾値を超えたか否かを判定する。マスターノード20は、リソースの総利用量が所定の閾値を超えたと判定した場合、リソースの利用量を抑制することを示す抑制通知を生成する。マスターノード20は、より多くリソースを利用しているスレーブノード30~50に生成した抑制通知を送信する。そして、スレーブノード30~50は、送信したリソースの容量とリソースの利用量とに基づいて、マスターノード20によって自装置が利用するリソースが抑制対象であると判定された場合に、抑制通知をマスターノード20から受信する。そして、スレーブノード30~50は、リソースの利用量を抑制する。このように、コンピュータシステム1は、処理動作中に利用するリソース量を外部から抑制する。[マスターノードの構成]次に、図2を用いて、マスターノードの構成を説明する。図2は、マスターノードの構成を示すブロック図である。マスターノードは、記憶部21と通信部22と制御部23とを有する。記憶部21は、例えば、半導体メモリ素子などの記憶装置であり、リソース識別テーブル21a、リソース利用状況テーブル21bを有する。図3はリソース識別テーブルの一例を示す図である。図3に示すように、リソース識別テーブル21aは、リソースIDとリソース名とを対応付けた情報を記憶する。ここで、リソース識別テーブル21aとして記憶されるリソースIDは、リソースを識別する識別子を示す。例えば、リソースIDには、1、2、3などが格納される。また、リソース名は、リソースの名称を示す。例えば、リソース名には、CPU負荷ユーザ[]、CPU負荷カーネル[]、CPU負荷I/O待ち[]などが格納される。図3に示す例では、リソース識別テーブル21aは、リソースIDが1で識別されるリソースがユーザモードのCPU負荷であることを示し、リソースIDが2で識別されるリソースがカーネルモードのCPU負荷であることを示す。なお、リソース識別テーブル21aが記憶する情報は、ユーザによって予め設定される。リソース利用状況テーブル21bは、スレーブノード単位のリソース利用状況を示す情報を記憶する。図4を用いてリソース利用状況テーブル21bとして記憶される情報を説明する。図4は、リソース利用状況テーブルの一例を示す図である。なお、リソース利用状況テーブル21bとして記憶される情報は、全体監視部24によって格納される。図4に示すように、例えば、リソース利用状況テーブル21bは、スレーブノードIDごとのリソースIDの情報を記憶する。ここで、リソース利用状況テーブル21bに記憶されるリソースIDは、リソース識別テーブル21aとして記憶されるリソースIDと同様に、リソースを識別する識別子を示す。また、スレーブノードIDは、スレーブノードの識別子である。例えば、スレーブノードIDには、192.168.2.1、192.168.2.2、192.168.2.3などが格納される。なお、以下の説明では、スレーブノード30のスレーブノードIDを192.168.2.1、スレーブノード40のスレーブノードIDを192.168.2.2、スレーブノード50のスレーブノードIDを192.168.2.3として説明する。図4に示す例では、リソース利用状況テーブル21bは、リソースIDが1であるユーザモードのCPU負荷は、スレーブノード30で7、スレーブノード40で65、スレーブノード50で39であることを示す。同様に、リソース利用状況テーブル21bは、リソースIDが2であるカーネルモードのCPU負荷は、スレーブノード30で2、スレーブノード40で23、スレーブノード50で14であることを示す。図2に戻り、通信部22は、スレーブノード30~50と情報のやり取りを制御する。例えば、通信部22は、スレーブノード30~50からリソース容量とリソース利用量とを受信する。通信部22は、受信したリソース容量とリソース利用量とを全体監視部24に出力する。また、通信部22は、特定部25によって生成されたリソース抑制通知を受付け、受付けたリソース抑制通知をリソース抑制対象であるスレーブノードに送信する。制御部23は、CPUCentralProcessingUnitやMPUMicroProcessingUnitなどの電子回路であり、全体監視部24と特定部25とを有する。全体監視部24は、通信部22を介して取得したスレーブノード30~50の稼動状態をリソース利用状況テーブル21bに格納する。例えば、全体監視部24は、スレーブノード30~50からのリソース容量とリソース利用量とを取得し、取得したリソース容量とリソース利用量とをリソース利用状況テーブル21bに格納する。一例を挙げると、全体監視部24は、スレーブノード40からNIC性能が1000000[KB/秒]、送信パケット量が2500[KB/秒]、受信パケット量が4000[KB/秒]であることを取得した場合、以下の処理を実行する。すなわち、全体監視部24は、リソース利用状況テーブル21bのノードID192.168.2.2のリソースID31に1000000、リソースID32に2500、リソースID33に4000を格納する。また、全体監視部24は、リソース利用状況テーブル21bをもとに、各スレーブノードのリソース容量の総和からシステムのリソース総容量を算出する。例えば、全体監視部24は、図4に示したリソース利用状況テーブルにおいて、リソースIDが31であるNIC性能が、スレーブノード30~50それぞれで1000000[KB/秒]である場合、以下の処理を実行する。すなわち、全体監視部24は、システムのNIC性能は、3000000[KB/秒]であると算出する。また、全体監視部24は、リソース利用状況テーブル21bをもとに、各スレーブのリソース利用量の総和から、システムのリソース総利用量を算出する。例えば、全体監視部24は、図4に示したリソース利用状況テーブルにおいて、リソースIDが32とリソースID33とからシステムのNICリソース総利用量を算出する。すなわち、全体監視部24は、システムのNIC性能は、6800[KB/秒]であると算出する。また、全体監視部24は、算出したシステムのリソース総容量、総利用量をリソース利用状況テーブル21bに格納し、リソース容量とリソース利用量とをリソース利用状況テーブル21bに格納したことを特定部25に通知する。特定部25は、システム全体のリソース容量と各スレーブノードのリソース利用量の総和を比較し、システムリソースが枯渇傾向にあるか否かを判定する。特定部25は、システムのリソースが枯渇傾向であると判定した場合、抑制フラグをたてる。例えば、特定部25は、システム全体のリソース利用量が所定の閾値を超えたと判定した場合に、リソースが枯渇していると判定する。一例を挙げると、特定部25は、DISKI/Oの利用量が90を超えた場合、システム全体のリソースが枯渇していると判定する。なお、閾値の値はこれに限定されるものではなく、任意に変更可能である。また、特定部25は、通知のあったスレーブノードと他のスレーブノード間で比較してリソースの利用量に偏りがあるか否かを判定する。特定部25は、リソースの利用量に偏りがあると判定した場合、抑制フラグをたてる。例えば、特定部25は、システム全体のリソース利用量が所定の閾値を超えていないと判定した場合に、リソースの利用量に偏りがあるか否かを判定する。一例を挙げると、特定部25は、送信パケット量及び受信パケット量が所定の閾値、90を超えていないが、スレーブノード40が85もネットワークリソースを利用していた場合には、リソースの利用量に偏りがあると判定する。なお、閾値の値はこれらに限定されるものではなく、任意に変更可能である。そして、特定部25は、抑制フラグが真である場合、スレーブノードIDとリソースIDとを含んだリソース抑制通知を生成し、生成したリソース抑制通知を通信部22に出力する。例えば、特定部25は、リソース利用量の高いスレーブノードIDもしくは偏りのあるスレーブノードIDと、リソースIDとをリソース利用状況テーブル21bから特定する。[スレーブノードの構成]次に、図5を用いて、スレーブノードの構成を説明する。図5は、スレーブノードの構成を示すブロック図である。スレーブノード30は、記憶部31と通信部32と制御部33とを有する。なお、スレーブノード30~50の構成は同様であるので、ここでは、スレーブノード30の構成についてのみ説明し、スレーブノード40~50の構成についての説明は省略する。記憶部31は、例えば、半導体メモリ素子などの記憶装置であり、リソース識別テーブル31a、リソース利用状況テーブル31bを有する。なお、リソース識別テーブル31aとして記憶される情報は、リソース識別テーブル21aとして記憶される情報と同様であるので、ここでは、リソース識別テーブル31aについての説明を省略する。また、リソース利用状況テーブル31bとして記憶される情報は、リソース利用状況テーブル21bとして記憶される情報と同様であるので、ここでは、リソース利用状況テーブル31bについての説明を省略する。通信部32は、マスターノード20及びスレーブノード40~50と情報のやり取りを制御する。例えば、通信部32は、稼動監視部38から自装置のリソース容量とリソース利用量とを受付け、受付けたリソース容量とリソース利用量とをマスターノード20に送信する。また、通信部32は、マスターノード20からリソース抑制通知を受信する。通信部32は、受信したリソース抑制通知をリソース抑制部39に出力する。制御部33は、CPUやMPUなどの電子回路であり、プロセス群34とAPI処理部35とカーネル部36とドライバ部37と稼動監視部38とリソース抑制部39とを有する。プロセス群34は、スレーブノード30が有するリソースを利用するプログラムの実体である。プロセス群34は、リソースを利用する場合、API処理部35にリソースの利用を要求する。なお、プロセス群34には、抑制対象となるリソースを利用するプロセスが含まれる。API処理部35は、プロセス群34からリソースの利用要求を受け付け、受け付けた利用要求をカーネル部36に出力する。例えば、API処理部35は、プロセス群34からリソースの利用の要求を受け付けた場合、APIApplicationProgrammingInterfaceを提供し、提供したAPIを介してプロセス群34からリソースの利用要求を受け付ける。カーネル部36は、メモリ、CPU、I/Oなどのシステムのリソースを管理し、プロセス群34とドライバ部37とのやりとりを制御する。すなわち、カーネル部36は、オペレーティングシステムの基本コンポーネントとして、ハードウェアとソフトウェアがやり取りできるようにする。例えば、カーネル部36は、API処理部35からリソースの利用要求を受け付けた場合、リソースの利用を要求するプロセス群34に対してリソースを割り当てる。ドライバ部37は、カーネル部36からリソースの割り当て指示を受け付け、受け付けた指示に基づきハードウェアを制御する。例えば、ドライブ部37は、I/Oリソースやネットワークリソースを制御する。稼動監視部38は、自ノードの保有するリソース容量と、自ノード内で稼働中のプロセス群のリソース利用量を取得する。そして、稼動監視部38は、取得したリソース利用量からプロセス毎のリソース利用量の総和を算出する。また、稼動監視部38は、取得したリソース容量とリソース利用量とを比較し、ノード内のリソースが枯渇傾向にあるか否かを判定する。そして、稼動監視部38は、ノード内のリソースが枯渇していると判定した場合、枯渇しているリソースのリソースIDを特定し、特定したリソースIDをリソース抑制部39に出力する。例えば、稼動監視部38は、リソース利用量が所定の閾値を超えたと判定した場合に、リソースが枯渇していると判定する。一例を挙げると、稼動監視部38は、CPUの利用量が85を超えた場合、リソースが枯渇していると判定する。なお、閾値の値はこれに限定されるものではなく、任意に変更可能である。また、稼動監視部38は、リソース容量と、リソース利用量とをマスターノード20に通信部32を介して送信する。例えば、稼動監視部38は、自装置のスレーブノードIDと、リソース容量と、リソース利用量とを含んだ情報をマスターノード20に送信する。リソース抑制部39は、稼動監視部38から枯渇しているリソースのリソースIDを受け付ける。あるいは、リソース抑制部39は、マスターノード20から受信したリソース抑制通知からリソースIDを抽出する。続いて、リソース抑制部39は、指定されたリソースIDをもとに、最もリソースを消費しているプロセスを稼動監視部38から取得する。そして、リソース抑制部39は、利用を抑制すべきリソースIDをキーに、リソースを消費しているプロセスの全スレッドに影響してリソース利用を一定期間抑制する。例えば、リソース抑制部39は、API処理部35、カーネル部36及びドライバ部37のいずれかに介在して、プロセスがリソースを利用することを抑制する。次に、リソース抑制部39によるリソースを抑制する処理を詳細に説明する。リソース抑制部39は、処理プログラムの変更を行わず、またOSOperatingSystemのタイムシェアリングシステムなどの処理優先部分に影響を与えずに、抑制対象である処理プロセスとOSとの間に介在する。リソース抑制部39による介在方式は、実装するOSによって異なる。ここではサービス系処理を行う代表的なOSである、Windows登録商標とLinux登録商標とを例に挙げて説明する。Windowsの処理例えば、リソース抑制部39は、OpenThred関数を用いて、リソース消費の高いプロセスのスレッド状態を把握し、スレッド単位に短期間のサスペンドとレジュームとを繰り返し実行する。リソース抑制部39は、抑制対象プロセスのサスペンドを実行するので、必ず当該プロセスに対する単位時間あたりのリソース利用負荷は100未満になる。例えば1秒間のうち10msの間介在すると1のリソース抑制になる。また、リソース抑制部39は、全てのプロセスのAPIの利用をフックする。例えば、リソース抑制部39は、SetWindowsHookExなどで全てのプロセスのWindowsAPIの利用をフックする。一例を挙げると、リソース抑制部39は、プロセス群34がAPI処理部35に要求した利用要求を取得して保持する。そして、リソース抑制部39は、リソースIDのリソースを消費するWindowsAPI毎の代替API関数処理を実行する。すなわち、リソース抑制部39は、抑制係数×Nミリ秒スリープしてから、API処理部35に制御を引き渡す。Linuxの処理リソース抑制部39は、フックモジュールを用いて、リソースを消費するopen、close、read、write、fork、mmapなどのシステムコールを監視し、該当するプロセスのシステムコール毎に短期間のスリープを行う。一例を挙げると、リソース抑制部39は、API処理部35がカーネル部36に要求したシステムコールを取得して保持する。リソース抑制部39は、抑制対象プロセスのスリープを実行するので、必ず当該プロセスに対する単位時間あたりのリソース利用負荷は100未満になる。例えば、リソース抑制部39は、1秒間のうち10msの間介在すると1のリソースを抑制することになる。リソース抑制部39は、所定時間スリープした後に、カーネル部36にシステムコールの制御を引き渡す。[処理手順]次に図6~12を用いて、処理の処理手順を説明する。ここでは、図6を用いて、マスターノードによる処理の処理手順を説明し、図7~図12を用いてスレーブノードによる処理の処理手順を説明する。マスターノードによる処理の処理手順図6を用いて、マスターノードによる処理の処理手順を説明する。図6は、マスターノードによる処理の処理手順を説明するフローチャートである。図6に示すように、マスターノード20は、スレーブノード30~50からリソース容量とリソース利用量とを取得したことを契機に処理を実行する。通信部22は、スレーブノード30~50からリソース容量とリソース利用量とを受信するステップS101。そして、全体監視部24は、通信部22によって受信された各スレーブノード30~50のリソース容量から、システムのリソース総容量を算出するステップS102。また、全体監視部24は、通信部22によって受信された各スレーブノード30~50のリソース利用量から、システムのリソース利用量を算出するステップS103。全体監視部24は、算出したシステムのリソース総容量とリソース利用量とをリソース利用状況テーブル21bに格納するステップS104。特定部25は、抑制フラグをおろしステップS105、あるリソースについてシステムのリソース総容量が枯渇傾向にあるか否かを判定するステップS106。ここで、特定部25は、あるリソースについてシステムのリソース総容量が枯渇傾向にあると判定した場合ステップS106、Yes、抑制フラグをたてステップS107、ステップS108の処理に移行する。一方、特定部25は、あるリソースについてシステムのリソース総容量が枯渇傾向にないと判定した場合ステップS106、No、ステップS108の処理に移行する。特定部25は、リソースの利用量についてスレーブノード間で偏りがあるか否かを判定するステップS108。ここで、特定部25は、リソースの利用量についてスレーブノード間で偏りがあると判定した場合ステップS108、Yes、抑制フラグをたてステップS109、ステップS110の処理に移行する。一方、特定部25は、リソースの利用量についてスレーブノード間で偏りがないと判定した場合ステップS108、No、ステップS110の処理に移行する。特定部25は、抑制フラグがたっているか否かを判定するステップS110。ここで、特定部25は、抑制フラグがたっていると判定した場合ステップS110、Yes、より多くリソースを消費しているスレーブノードに対してリソース抑制通知を発行し、通信部22を介して送信しステップS111、ステップS101に移行する。一方、特定部25は、抑制フラグがたっていないと判定した場合ステップS110、No、ステップS101に移行する。スレーブノードによる処理の処理手順図7は、スレーブノードによる処理の処理手順を説明するフローチャートである。例えば、スレーブノード30~50は、所定の時間が経過したことを契機に処理を実行する。なお、スレーブノード30~50による処理手順は同様であるので、ここでは、スレーブノード30を例にして処理手順を説明する。図7に示すように、稼動監視部38は、自ノードが保有するリソース容量を取得しステップS201、全プロセスのリソース利用量を取得するステップS202。そして、稼動監視部38は、自ノード内のリソース容量が枯渇傾向にあるか否かを判定するステップS203。ここで、稼動制御部34は、自ノード内のリソース容量が枯渇傾向にあると判定した場合ステップS203、Yes、枯渇しているリソースのリソースIDをリソース抑制部に通知するステップS204。リソース抑制部39は、通知されたリソースIDを利用するプロセスに対して、一定量のリソース利用を抑制する処理を実行するステップS205。なお、この処理の詳細は後述する。ステップS205の処理が終了後、または、稼動制御部34によって自ノード内のリソース容量が枯渇傾向にないと判定された場合ステップS203、No、通信部32は、リソース容量とリソース利用量とをマスターノード20へ送信するステップS206。ステップS206が終了後、スレーブノード30はステップS201に移行し、以降の処理を継続して実行する。スレーブノードによる抑制処理の処理手順次に、図8を用いて、スレーブノードによる抑制通知受信処理の処理手順を説明する。図8は、スレーブノードによる抑制処理の処理手順を示すフローチャートである。図8に示すように、スレーブノード20からリソース抑制通知を受信したことを契機に処理を実行する。通信部32によって、マスターノード20からリソース抑制通知を受信された場合ステップS301、Yes、リソース抑制部39は、通知されたリソースIDを利用するプロセスに対して、一定量のリソース利用を抑制する処理を実行するステップS302。なお、この処理の詳細は後述する。リソース抑制処理次に、図9を用いて、スレーブノードによる抑制処理の処理手順を説明する。図9は、スレーブノードによる抑制処理の処理手順を示すフローチャートである。図9に示すように、スレーブノードは、稼動監視部38によってリソースを抑制することを通知されたことを契機に処理を実行する。なお、ここで説明する処理は、図7のステップS205及び図8のステップS302に対応する処理である。リソース抑制部39は、抑制中リストを初期化しステップS401、抑制要求があるか否かを判定するステップS402。ここで、リソース抑制部39は、抑制要求があると判定した場合ステップS402、Yes、抑制対象のプロセスIDとリソースIDとを受信するステップS403。一方、リソース抑制部39は、抑制要求がないと判定した場合ステップS402、No、ステップS413の処理に移行する。続いて、リソース抑制部39は、抑制中リスト内に指定されたプロセスIDが存在するか否かを判定するステップS404。ここで、リソース抑制部39は、抑制中リスト内に指定されたプロセスIDが存在しないと判定した場合ステップS404、No、抑制中リストに指定されたプロセスIDのレコードを追加しステップS405、ステップS406に移行する。一方、リソース抑制部39は、抑制中リスト内に指定されたプロセスIDが存在すると判定した場合ステップS404、Yes、ステップS406に移行する。すなわち、リソース抑制部39は、抑制中リスト内の指定されたプロセスIDに対し、指定されたリソースIDが存在するか否かを判定するステップS406。ここで、リソース抑制部39は、抑制中リスト内の指定されたプロセスIDに対し、指定されたリソースIDが存在しないと判定した場合ステップS406、No、以下の処理を実行する。すなわち、リソース抑制部39は、抑制中リストのプロセスIDが一致するレコードにリソースIDをセットして更新しステップS407、ステップS408に移行する。一方、リソース抑制部39は、抑制中リスト内の指定されたプロセスIDに対し、指定されたリソースIDが存在すると判定した場合ステップS406、Yes、ステップS408に移行する。リソース抑制部39は、抑制中リストのリソースIDに対する抑制係数を加算して、レコードを更新しステップS408、プロセスIDに該当するプロセスが存在するか否かを判定するステップS409。ここで、リソース抑制部39は、プロセスIDに該当するプロセスが存在しないと判定した場合ステップS409、No、抑制中リストの当該レコードを削除しステップS410、ステップS409に移行する。リソース抑制部39は、プロセスIDに該当するプロセスが存在すると判定した場合ステップS409、Yes、抑制処理を実行するステップS411。なお、抑制処理の詳細は後述する。続いて、リソース抑制部39は、抑制中リストレコード数分、抑制したか否かを判定するステップS412。リソース抑制部39は、抑制中リストレコード数分、抑制していないと判定した場合ステップS412、No、ステップS409に移行する。一方、リソース抑制部39は、抑制中リストレコード数分、抑制したと判定した場合ステップS412、Yes、処理を終了するか否かを判定するステップS413。リソース抑制部39は、処理を終了しないと判定した場合ステップS413、No、ステップS402に移行する。一方、リソース抑制部39は、処理を終了すると判定した場合ステップS413、Yes、リソース抑制処理を終了する。SuspendResume処理図10は、Suspend/ResumeThreadによるCPU負荷抑制処理の処理手順を示すフローチャートである。図10に示すように、リソース抑制部39は、OpenThred関数などで対象プロセスのスレッドハンドルを取得するステップS501。そして、リソース抑制部39は、SuspendThred関数でスレッドをサスペンドさせステップS502、全スレッド数分の処理を繰り返したか否かを判定するステップS503。リソース抑制部39は、全スレッド数分の処理を繰り返していないと判定した場合ステップS503、No、ステップS502に移行する。一方、リソース抑制部39は、全スレッド数分の処理を繰り返したと判定した場合ステップS503、Yes、抑制係数×Nミリ秒スリープするステップS504。そして、リソース抑制部39は、ResumeThred関数でスレッドをレジュームさせステップS505、全スレッド数分の処理を繰り返したか否かを判定するステップS506。ここで、リソース抑制部39は、全スレッド数分の処理を繰り返していないと判定した場合ステップS506、No、ステップS505に移行する。一方、リソース抑制部39は、全スレッド数分の処理を繰り返したと判定した場合ステップS506、Yes、処理を終了する。APIフック図11は、APIによるI/O利用抑制処理を示すシーケンス図である。図11に示すように、リソース抑制部39は、全てのAPIの利用をフックするステップS601。例えば、リソース抑制部39は、SetWindows登録商標HookExなどで全てのプロセスのAPIの利用をフックする。また、抑制対象プロセスは、内部処理を実行しステップS602、APIをコールするステップS603。そして、リソース抑制部39は、リソースIDのリソースを消費するAPI毎の代替API関数処理を実行する。すなわち、リソース抑制部39は、フックしたプロセスのうち、抑制対象であるリソースを利用するプロセスに対して、抑制係数×Nミリ秒スリープしてAPI処理部35に引き渡すステップS604。続いて、抑制対象プロセスは、内部処理を実行しステップS605、処理を終了する。Kernelフック図12は、KernelフックによるI/O利用抑制処理を示すシーケンス図である。図12に示すように、抑制対象プロセスは、内部処理を実行しステップS701、システムコールをコールするステップS702。そして、リソース抑制部39は、リソースIDのリソースを消費するシステムコール毎の関数処理を実行する。すなわち、リソース抑制部39は、抑制係数×Nミリ秒スリープして、カーネル部36に引き渡すステップS703。続いて、抑制対象プロセスは、内部処理を実行しステップS704、処理を終了する。[実施例1の効果]上述してきたように、実施例1では、処理動作中に利用するリソース量を外部からプロセス単位で抑制することができる。また、実施例1では、稼動監視部38によって、スレーブノードがリソース不足に陥ったと判定された場合、リソース抑制部39は、プロセスのCPU利用を単位時間あたりで抑制して、他のプロセスの動作を行うための余剰リソースを確保する。また、実施例1では、緩やかな負荷増加傾向や偏りは、マスターノードの全体監視部24が察知し、全体的な余剰リソースを確保する。このように、実施例1に係るコンピュータシステム1は、負荷分散することなく、プロセスにリソース容量以上のリソースを利用させない。また、実施例1では、I/O負荷の高いプロセスを特定し、そのプロセスを短期間にサスペンド/レジュームさせることで、単位時間あたりのI/O要求を減らすことができる。また、実施例1では、マスターノードがスレーブノードの送出するパケット量をネットワークリソースとして監視し、スレーブノード内外の過負荷や不均衡を検出する。そして、リソース抑制部39は、スレーブノードのプロセス単位にリソースを抑制するので、L3スイッチやルーターではできなかった、優先度の異なる同種のサービスをアプリケーション側で制御できる。実施例1では、リソース利用容量が枯渇傾向にあるか否かを判定し、枯渇傾向あると判定した場合に、リソースの利用を抑制する例について説明した。ところで、コンピュータシステムにおいて、CPUリソースを消費せずに省電力モードでコンピュータを動作させる場合がる。このように省電力モードでコンピュータを動作させる場合、SLAやコンピュータアーキテクチャ毎に異なる動作条件を処理プログラム自身で解決することが困難であった。そこで、実施例2では、省電力モードに設定されたスレーブノードにおいて、所定の閾値を超えるリソースを利用した場合に、リソースの利用を抑制する例について説明する。[実施例2に係るシステムの構成]実施例2にシステムの構成は、図1に示したシステム構成を同様である。また、マスターノードの構成については、図2に示した構成と同様であり、スレーブノードの構成については、図5に示した構成と同様である。相違する点は、目標利用量として設定する閾値の値が、リソースが枯渇傾向にあるか否かを判定する閾値の値よりも低い値に設定されることである。例えば、目標利用量として設定する閾値の値は、30に設定される。なお、目標利用量として設定する閾値の値は、この値に限定されるものではなく、ユーザが任意の値に変更可能である。[処理の処理手順]実施例2の処理の処理手順では、実施例1とは異なる処理手順についてのみ説明する。次に図13を用いて、実施例2に係るマスターノードによる処理の処理手順を説明する。図13は、実施例2に係るマスターノードによる処理の処理手順を示すフローチャートである。図13に示すステップS801の処理からステップS805までの処理は、図6に示したステップS101からステップS105までの処理と同様であるので、ここでは、ステップS801の処理からステップS805までの処理についての説明を省略する。特定部25は、リソース利用量について、スレーブノードの利用が目標利用量より多いか否かを判定するステップS806。ここで、特定部25は、リソース利用量について、スレーブノードの利用が目標利用量より多いと判定した場合ステップS806、Yes、抑制フラグをたてステップS807、ステップS808の処理に移行する。一方、特定部25は、リソース利用量について、スレーブノードの利用が目標利用量より多くないと判定した場合ステップS806、No、ステップS808の処理に移行する。特定部25は、抑制フラグがたっているか否かを判定するステップS808。ここで、特定部25は、抑制フラグがたっていると判定した場合ステップS808、Yes、より多くリソースを消費しているスレーブノードに対してリソース抑制通知を発行し、通信部22を介して送信しステップS809、ステップS801に移行する。一方、特定部25は、抑制フラグがたっていないと判定した場合ステップS808、No、ステップS801に移行する。次に、図14を用いて、実施例2に係るスレーブノードによる処理の処理手順を説明する。図14は、実施例2に係るスレーブノードによる処理の処理手順を示すフローチャートである。図14に示すように、通信部32によって、マスターノード20からリソース抑制通知を受信された場合ステップS901、Yes、リソース抑制部39は、指定されたリソースIDの抑制量が目標値に達しているか否かを判定するステップS902。ここで、リソース抑制部39は、指定されたリソースIDの抑制量が目標値に達していないと判定した場合ステップS902、No、指定されたリソース容量を消費または占有しているプロセスに対してリソース利用を抑制しステップS903、ステップS902に移行する。一方、リソース抑制部39は、指定されたリソースIDの抑制量が目標値に達していると判定した場合ステップS902、Yes、ステップS901に移行する。なお、ステップS903の処理は、図9~図12で説明した処理を適宜実行する。[実施例2の効果]上述してきたように、実施例2では、利用量に目標値を設定し、CPUの負荷を抑制するので、省電力モードに移行させることができる。例えば、実施例2では、マスターノードがスレーブノードに対しCPUのリソース利用に対し目標閾値を設定して送付し、スレーブノード内での稼動監視が目標値に達するまで処理負荷の高いプロセスを抽出し、リソース抑制部がそれを抑制することができる。また、実施例2では、スレーブノード内で動作中の処理負荷の高いもののみを抑制するので、システム全体として処理を継続しつつも、処理負荷を低減する。この結果、実施例2に係るスレーブノードは、CPUを省電力モードに移行させることができる。ところで、本発明は、上述した実施例以外にも、種々の異なる形態にて実施されてよい。そこで、実施例3では、本発明に含まれる他の実施例について説明する。システム構成等実施例1及び実施例2において説明した各処理のうち自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともできる。あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文章中や図面中で示した処理手順、制御手順、具体的名称については、特記する場合を除いて任意に変更することができる。また、図示した記憶部が格納する情報は一例に過ぎず、必ずしも図示のごとく情報が格納される必要はない。また、各種の負荷や利用状況などに応じて、各実施例において説明した各処理の各ステップでの処理の順番を変更してもよい。例えば、図6に示すステップS102とステップS103との順番を入れ替えても良く、また、ステップS102とステップS103との処理を並行して実行してもよい。また、図示した各構成部は、機能概念的なものであり、必ずしも物理的に図示のごとく構成されていることを要しない。例えば、マスターノード20の全体監視部24と特定部25とは統合されてもよい。さらに、各装置にて行われる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。プログラムところで、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。図15は、リソース監視プログラムを実行するコンピュータを示す図である。図15に示すように、コンピュータ300は、利用者からデータや各種設定などを受け付ける入力装置310と、コンピュータの状況などを通知する出力装置320とを有する。また、コンピュータ300は、他の装置とデータを送受信するネットワークインターフェース330と媒体読取装置340とHDD350とRAM360とCPU370とバス380とを有する。そして、各装置310~370それぞれは、バス380に接続される。ここで、図15に示すように、HDD350には、図2に示した、全体監視部24と特定部25と同様の機能を発揮するリソース監視プログラム351が予め記憶されている。また、媒体読取装置340は、リソース監視プログラム351を実現するための各種データを記憶する。この各種データは、例えば、図2に示した、リソース識別テーブル21aやリソース利用状況テーブル21bを含む。そして、CPU370は、リソース監視プログラム351をRAM360に展開して、リソース監視プロセス371として実行する。すなわち、リソース監視プロセス371は、図2に示した、全体監視部24と特定部25と同様の動作を実行する。図16は、抑制通知プログラムを実行するコンピュータを示す図である。図16に示すように、コンピュータ400は、利用者からデータや各種設定などを受け付ける入力装置410と、コンピュータの状況などを通知する出力装置420とを有する。また、コンピュータ400は、他の装置とデータを送受信するネットワークインターフェース430と媒体読取装置440とHDD450とRAM460とCPU470とバス480とを有する。そして、各装置410~470それぞれは、バス480に接続される。ここで、図16に示すように、HDD450には、図5に示した、稼動監視部38及びリソース抑制部39と同様の機能を発揮するリソース抑制プログラム451が予め記憶されている。また、媒体読取装置440は、リソース抑制プログラム451を実現するための各種データを記憶する。この各種データは、例えば、図5に示した、リソース識別テーブル31aやリソース利用状況テーブル31bを含む。そして、CPU470は、リソース抑制プログラム451をRAM460に展開して、リソース抑制プロセス471として実行する。すなわち、リソース抑制プロセス471は、図5に示した、稼動監視部38及びリソース抑制部39と同様の動作を実行する。ところで、上記したリソース監視プログラム351は、必ずしもHDD350に記憶させておく必要はない。同様に抑制通知プログラム451は、必ずしもHDD450に記憶させておく必要はない。例えば、コンピュータ300や400に挿入されるフレキシブルディスクFD、CD-ROM、MOディスク、DVDディスク、光磁気ディスク、ICカードなどの可搬用の物理媒体に記憶させておくようにしてもよい。また、コンピュータ300や400の内外に備えられるハードディスクドライブHDDなどの固定用の物理媒体に記憶させておいてもよい。さらに、公衆回線、インターネット、LANLocalAreaNetwork、WANWideAreaNetworkなどを介してコンピュータ300に接続される他のコンピュータシステムに記憶させておいてもよい。そして、コンピュータ300がこれらからプログラムを読み出して実行するようにしてもよい。すなわち、このプログラムは、上記した可搬用の物理媒体、固定用の物理媒体、通信媒体などの記録媒体に、コンピュータ読み取り可能に記憶されるものである。そして、コンピュータ300や400は、このような記録媒体からプログラムを読み出して実行することで上記した実施例と同様の機能を実現する。なお、この他の実施例でいうプログラムは、コンピュータ300や400によって実行されることに限定されるものではない。例えば、他のコンピュータシステムまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。