JP2007102332A - 負荷分散システム及び負荷分散方法 - Google Patents

Abstract

【課題】プログラムの実行単位間の関連度に応じて適切に負荷を分散し、負荷の均一化を実現することができる負荷分散システム及び負荷分散方法を提供する。
【解決手段】オペレーティングシステムに基づいてそれぞれ動作する複数のシステム資源に対し、プログラムを実行単位毎に割り当てる手段（ステップＳ１）と、実行単位毎のリソース利用状況を取得し、取得した実行単位毎のリソース利用状況に基づいて実行単位間の関連度を決定し、実行単位間の関連度を示す関連情報を取得する手段（ステップＳ２）と、取得した関連情報に基づいて、関連度が低い実行単位を他のシステム資源に移動させる手段（ステップＳ３）とを備える。
【選択図】図２

Description

本発明は、負荷分散システム及び負荷分散方法に関する。

複数のシステム資源を利用してプログラムを実行可能な計算機システムには、通常、各システム資源に負荷を分散する負荷分散システムが用いられる。この負荷分散システムを用いたクラスタシステムが開発されている。

クラスタシステムは、システム資源としての複数のノード（計算機）を１つの群としてまとめ、信頼性や処理性能の向上を実現するシステムである。このクラスタシステムは、複数のノードをネットワークにより相互に接続することによって構成されている。さらに、クラスタシステムには、スケジューラとしてプロセスマイグレーションマネージャ（以降、ＰＭＭとする）が設けられている。

ＰＭＭは、クラスタシステムにおいて、プログラムを構成する複数のプロセスのリソース使用状況を監視し、そのリソース使用状況に基づいてノード間でのプロセスの移動を制御する機構である。このＰＭＭにより、システム全体での負荷が分散され、システムの効率的な運用が実現されている。また、ＰＭＭの機構としては、システム全体での負荷だけに着目した機構や各プロセスの関連性に着目した機構等が提案されている。さらに、ノード上に配置されたタスクの実行順序を制御し、実時間性を確保して所望の処理を行う分散処理方法も提案されている（例えば、特許文献１参照）。
特開平１１−２４２６５８号公報

しかしながら、システム全体での負荷に着目したＰＭＭの機構では、システムに存在する各プロセスの関連性を無視しているため、関連性が強いプロセス同士が異なるノードに移動してしまうことがある。このようにプロセス配置が不適切である場合には、リソース間の不要な送受信が発生してしまう。

また、各プロセスの関連性に着目したＰＭＭの機構では、同じノードに関連性が強いプロセスを集約することにより、リソース間の不要な送受信を減少させることはできるが、そのノードに本来別のノードで動作した方が効率の良いプロセス、すなわちそのノードに存在するプロセスに対し関連性が低いプロセスが存在した場合には、そのノードの負荷が必要以上に大きくなってしまう。

本発明は、上記に鑑みてなされたものであり、その目的は、プログラムの実行単位間の関連度に応じて適切に負荷を分散し、負荷の均一化を実現することができる負荷分散システム及び負荷分散方法を提供することである。

本発明の実施の形態に係る第１の特徴は、負荷分散システムにおいて、オペレーティングシステムに基づいてそれぞれ動作する複数のシステム資源に対し、プログラムを実行単位毎に割り当てる手段と、実行単位毎のリソース利用状況を取得し、取得した実行単位毎のリソース利用状況に基づいて実行単位間の関連度を決定し、実行単位間の関連度を示す関連情報を取得する手段と、取得した関連情報に基づいて、関連度が低い実行単位を他のシステム資源に移動させる手段とを備えることである。

本発明の実施の形態に係る第２の特徴は、負荷分散方法において、オペレーティングシステムに基づいてそれぞれ動作する複数のシステム資源に対し、プログラムを実行単位毎に割り当てるステップと、実行単位毎のリソース利用状況を取得し、取得した実行単位毎のリソース利用状況に基づいて実行単位間の関連度を決定し、実行単位間の関連度を示す関連情報を取得するステップと、取得した関連情報に基づいて、関連度が低い実行単位を他のシステム資源に移動させるステップとを備えることである。

本発明によれば、プログラムの実行単位間の関連度に応じて適切に負荷を分散し、負荷の均一化を実現することができる負荷分散システム及び負荷分散方法を提供することができる。

（第１の実施の形態）
本発明の第１の実施の形態について図１ないし図３を参照して説明する。第１の実施の形態は、負荷分散システムをクラスタシステムに適応した一適応例である。

図１に示すように、第１の実施の形態に係るクラスタシステム１は、システム資源として複数のノード２及び共有のディスク３をネットワーク４により接続することによって構成されている。このネットワーク４には、クライアント端末（図示せず）が直接又は外部ネットワークを介して接続されている。

ノード２は、ＣＰＵ（中央処理装置）やメモリ（記憶部）等を備える計算機である。このノード２は、例えば、各種のサービス（プログラム）を提供するサーバ装置として機能する。サービスは、プログラムの実行単位（処理単位）である複数のプロセスＰ１〜Ｐ３により構成されている。

なお、第１の実施の形態では、サービスが複数のノード２により同時並行して実行可能なタイプ、例えば並列実行型のプログラムであるため、各ノード２がそれぞれシステム資源となる。

ディスク３は、ファイル等の各種データを記憶する記憶装置である。このディスク３は、各ノード２に対して共有の記憶装置として機能する。ネットワーク４は、各ノード２間の通信及びノード２とクライアント端末との通信を可能にする。なお、ネットワーク４としては、例えばＷＡＮ（ワイドエリアネットワーク）やＬＡＮ（ローカルエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）等のネットワークを用いる。

各ノード２では、それぞれ対応するオペレーティングシステム（以降、ＯＳとする）５が動作する。ＯＳ５は、それぞれ独立した複数のリソース、例えば、セマフォ、共有メモリ、パイプ及びメッセージ等を管理保有する。また、プロセスＰ１〜Ｐ３は、アプリケーションプログラムインターフェース（以降、ＡＰＩとする）６を介してＯＳ５内のリソースを確保し、そのリソースにアクセスする。ＡＰＩ６は、各プロセスＰ１〜Ｐ３のリソース利用状況を監視する機構及びそれらのリソース利用状況を保持する機構を備えている。また、ＡＰＩ６は、リソースのアクセス具合（共用度を含む）もリソース利用状況として取得する。

このようなクラスタシステム１では、プロセスマイグレーションマネージャ等のスケジューラ７が動作する。このスケジューラ７は、クラスタシステム１において、各ＡＰＩ６から各プロセスＰ１〜Ｐ３のリソース利用状況を取得し、取得した各プロセスＰ１〜Ｐ３のリソース使用状況を集計し、そのリソース使用状況に基づいてノード２間でのプロセスＰ１〜Ｐ３の移動を制御する機構である。なお、スケジューラ７は、各ノード２が相互に通信を行いながら同期して一体となって動作することにより実現されるサービス（プロセス又はプロセス群）である。

詳しくは、スケジューラ７は、各ＡＰＩ６から各プロセスＰ１〜Ｐ３のリソース利用状況を取得し、プロセスＰ１〜Ｐ３が存在するＯＳ５、すなわちノード２を常に把握し、取得した各プロセスＰ１〜Ｐ３のリソース利用状況を集計し、プロセスＰ１〜Ｐ３毎のリソース利用状況を示すリソース利用状況情報としてリソース利用状況表Ｈ１を取得する。さらに、スケジューラ７は、そのリソース利用状況表Ｈ１に基づいてプロセスＰ１〜Ｐ３間の関連度（関連レベル）を決定し、そのプロセスＰ１〜Ｐ３間の関連度を示す関連情報として関連表Ｈ２を取得する。

なお、スケジューラ７は、それらのリソース利用状況表Ｈ１及びプロセスＰ１〜Ｐ３の関連表Ｈ２を格納する格納領域を有しており、格納領域にリソース利用状況表Ｈ１及びプロセスＰ１〜Ｐ３の関連表Ｈ２を保持する。

ここで、スケジューラ７は、リソース利用状況表Ｈ１に基づいて、プロセスＰ１〜Ｐ３間の関連度を高レベル（Ｈ）又は低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。すなわち、スケジューラ７は、リソースに対するアクセス状態や待ち状態等に関するアクセス情報（例えば更新頻度）を収集し、そのアクセス情報に基づいてプロセスＰ１〜Ｐ３間の関連度を高レベル又は低レベルと決定する。

例えば、図１に示すように、プロセスＰ１及びプロセスＰ２は、共有メモリ（図１中のリソースＸ１）に対して高い共用状況でアクセスし、排他的に共有メモリを利用するため、高い依存関係を有している。したがって、プロセスＰ１及びプロセスＰ２間の関連度は高レベルと決定される。一方、プロセスＰ２及びプロセスＰ３は、ファイル（図１中のリソースＸ２）に対して低い共用状況でアクセスするため、低い依存関係を有している。したがって、プロセスＰ２及びプロセスＰ３間の関連度は低レベルと決定される。

プロセスＰ１〜Ｐ３間の関連度は、アクセス先のリソースに応じて、例えばセマフォ、共有メモリ、パイプ、メッセージ、ファイルの順序で低くなり、セマフォ＞共有メモリ＞パイプ＞メッセージ＞ファイルという関係式で表される。なお、第１の実施の形態では、セマフォ及び共有メモリを高レベルとし、パイプ、メッセージ及びファイルを低レベルとし、プロセスＰ１〜Ｐ３間の関連度を２つのレベルに分けている。このように第１の実施の形態では、プロセスＰ１〜Ｐ３間の関連度は、リソース毎に予め期待される共用度に応じて設定されている。

次に、このような構成のクラスタシステム１のサービス提供動作について説明する。

クライアント端末からのサービス（プログラム）の実行要求がネットワーク４を介してクラスタシステム１に送信される。クラスタシステム１内のノード２はクライアント端末からの実行要求により指定されたサービスを実行し、その実行結果に対応する応答をネットワーク４を介して要求元のクライアント端末に返す。

このとき、図２に示すように、まず、スケジューラ７が各ノード２にサービス（プログラム）を実行単位毎、すなわちプロセスＰ１〜Ｐ３毎に各ノード２に割り当てる（ステップＳ１）。これにより、各プロセスＰ１〜Ｐ３は各ノード２に振り分けられる。これに応じて、各ノード２がそれぞれ対応するＯＳ５により各プロセスＰ１〜Ｐ３を実行する。

例えば、図１に示すように、各プロセスＰ１〜Ｐ３がノード２（図１中のノードＡ）に割り当てられる。これに応じて、ノード２（図１中のノードＡ）がＯＳ５（図１中のＯＳＡ）により各プロセスＰ１〜Ｐ３を実行する。

次いで、図２に示すように、スケジューラ７は、各ＡＰＩ６から各プロセスＰ１〜Ｐ３のリソース利用状況を取得し、リソース利用状況情報としてリソース利用状況表Ｈ１を得て、さらに、そのリソース利用状況表Ｈ１に基づいてプロセスＰ１〜Ｐ３間の関連度を決定し、そのプロセスＰ１〜Ｐ３間の関連度を示す関連情報として関連表Ｈ２を取得する（ステップＳ２）。

詳しくは、スケジューラ７は、各ＡＰＩ６から各プロセスＰ１〜Ｐ３のリソース利用状況を取得し、プロセスＰ１〜Ｐ３が存在するノード２を常に把握し、取得した各プロセスＰ１〜Ｐ３のリソース利用状況を集計し、リソース利用状況表Ｈ１を作成又は更新する。さらに、スケジューラ７は、リソースに対するアクセス状態や待ち状態等に関するアクセス情報（例えば更新頻度）を収集し、そのアクセス情報に基づいてプロセスＰ１〜Ｐ３間の実行に関する依存関係を導出し、その依存関係に基づいてプロセスＰ１〜Ｐ３間の関連度を高レベル（Ｈ）又は低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。

例えば、図１に示すように、スケジューラ７は、各ＡＰＩ６から各プロセスＰ１〜Ｐ３のリソース利用状況を取得し、各プロセスＰ１〜Ｐ３がノード２（図１中のノードＡ）に存在することを把握し、さらに、プロセスＰ１及びプロセスＰ２が共有メモリ（図１中のリソースＸ１）にアクセスしていることと、プロセスＰ２及びプロセスＰ３がディスク３のファイル（図１中のリソースＸ２）にアクセスしていることを把握し、リソース利用状況表Ｈ１を作成又は更新する。さらに、スケジューラ７は、そのリソース利用状況表Ｈ１に基づいて、プロセスＰ１及びプロセスＰ２間の関連度を高レベル（Ｈ）と決定し、プロセスＰ２及びプロセスＰ３間の関連度を低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。

ここで、図１に示すリソース利用状況表Ｈ１では、リソース利用状況がリソースＸ１、Ｘ２毎に示されている。Ｘ１：Ｐ１＠Ａ，Ｐ２＠Ａとは、リソースＸ１がノード２（図１中のノードＡ）上のプロセスＰ１と、同じくノード２（図１中のノードＡ）上のプロセスＰ２とによりアクセスされていることを示している。また、Ｘ２：Ｐ２＠Ａ，Ｐ３＠Ａとは、リソースＸ２がノード２（図１中のノードＡ）上のプロセスＰ２と、同じくノード２（図１中のノードＡ）上のプロセスＰ３によりアクセスされていることを示している。

また、図１に示す関連表Ｈ２では、プロセスＰ１〜Ｐ３間の関連度がプロセスＰ１〜Ｐ３間毎に示されている。（Ｐ１，Ｐ２）＝（Ｘ１：Ｈ）とは、プロセスＰ１及びプロセスＰ２が共有メモリ（図１中のリソースＸ１）にアクセスしており、それらの関連度が高レベルであることを示している。一方、（Ｐ２，Ｐ３）＝（Ｘ２：Ｌ）とは、プロセスＰ１及びプロセスＰ２がファイル（図１中のリソースＸ２）にアクセスしており、それらの関連度が低レベルであることを示している。

最後に、図２に示すように、スケジューラ７は、リソース利用状況表Ｈ１及びプロセスＰ１〜Ｐ３の関連表Ｈ２に基づいて、関連度が低レベルである（関連度が低い）プロセスＰ３を現在のノード２から他のノード２に移動させ、プロセスマイグレーション、すなわち負荷分散を行う（ステップＳ３）。このような処理が繰り返される。

詳しくは、スケジューラ７は、プロセスＰ１〜Ｐ３間の関連度が低レベルであると決定した場合、プロセスＰ１〜Ｐ３間に関連性が存在していても、関連度が低いプロセスＰ１〜Ｐ３を他のノード２に移動させるプロセスマイグレーションが可能であると判断し、関連度が低いプロセスＰ３を各ＯＳ５のリソース利用状況に基づいてリソース的な余裕があるＯＳ５、すなわちノード２に移動させる。このようにして、プロセスマイグレーションが行われ、負荷分散が実現される。

例えば、関連表Ｈ２に基づいて、図３に示すように、関連度が低いプロセスＰ３がノード２（図３中のノードＡ）からの他のノード２（図３中のノードＢ）に移動する。これに応じて、ノード２（図３中のノードＡ）がＯＳ５（図３中のＯＳＡ）によりプロセスＰ１、Ｐ２を実行し、ノード２（図３中のノードＢ）がＯＳ５（図３中のＯＳＢ）によりプロセスＰ３を実行することになる。これにより、各ノード２に対する負荷が分散される。

なお、図１中のリソース利用状況表Ｈ１に示すＸ２：Ｐ２＠Ａ，Ｐ３＠Ａは、図３中のリソース利用状況表Ｈ１に示すように、Ｘ２：Ｐ２＠Ａ，Ｐ３＠Ｂに更新される。ここで、Ｘ２：Ｐ２＠Ａ，Ｐ３＠Ｂとは、リソースＸ２がノード２（図３中のノードＡ）上のプロセスＰ２と、ノード２（図３中のノードＢ）上のプロセスＰ３とによりアクセスされていることを示している。

以上説明したように、第１の実施の形態によれば、プロセスＰ１〜Ｐ３毎のリソース利用状況を取得し、取得したプロセスＰ１〜Ｐ３毎のリソース利用状況に基づいてプロセスＰ１〜Ｐ３間の関連度を決定し、その関連度を示す関連情報として関連表Ｈ２を取得し、取得した関連表Ｈ２に基づいて、関連度が低いプロセスＰ３を現在のノード２（図３中のノードＡ）から他のノード２（図３中のノードＢ）に移動させることによって、関連性が強いプロセスＰ１、Ｐ２同士が同じノード２（図３中のノードＡ）上に存在することになるので、リソース間の不要な送受信の発生が防止され、さらに、関連性が強いプロセスＰ１、Ｐ２同士が存在するノード２（図３中のノードＡ）上に関連性が弱いプロセスＰ３が存在しなくなるので、全てのノード２の負荷が均一に抑えられる。このようにして、プロセスＰ１〜Ｐ３間の関連度に応じて適切に負荷を分散し、負荷の均一化を実現することができる。

（第２の実施の形態）
本発明の第２の実施の形態について図２、図４及び図５を参照して説明する。

本発明の第２の実施の形態は、基本的に第１の実施の形態と同様である。第２の実施の形態では、第１の実施の形態との相違点について説明する。なお、第１の実施の形態で説明した部分と同一部分は同一符号で示し、その説明は省略する（後述する他の実施の形態でも同様である）。

第２の実施の形態では、サービス（プログラム）の実行単位がプロセスＰ１〜Ｐ３に代えてスレッドＴ１〜Ｔ３である。これにより、サービスは、スレッドＴ１〜Ｔ３毎に各ノード２に振り分けられる。例えば、図４に示すように、プロセスＰ１は、その実行単位である複数のスレッドＴ１〜Ｔ３を有している。このプロセスＰ１は、ＡＰＩ６を介してＯＳ５内のリソースを確保し、そのリソースにアクセスする。

ＡＰＩ６は、プロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を監視する機構及びそれらのリソース利用状況を保持する機構を備えている。また、ＡＰＩ６は、リソースのアクセス具合（共用度を含む）もリソース利用状況として取得する。

スケジューラ７は、スレッドマイグレーションマネージャとして機能する。このスケジューラ７は、クラスタシステム１において、ＡＰＩ６からプロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を取得し、取得した各スレッドＴ１〜Ｔ３のリソース使用状況を集計し、そのリソース使用状況に基づいてノード２間でのスレッドＴ１〜Ｔ３の移動を制御する機構である。なお、スケジューラ７は、各ノード２が相互に通信を行いながら同期して一体となって動作することにより実現されるサービス（プロセス又はプロセス群）である。

詳しくは、スケジューラ７は、ＡＰＩ６からプロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を取得し、スレッドＴ１〜Ｔ３が存在するＯＳ５、すなわちノード２を常に把握し、取得した各スレッドＴ１〜Ｔ３のリソース利用状況を集計し、スレッドＴ１〜Ｔ３毎のリソース利用状況を示すリソース利用状況情報としてリソース利用状況表Ｈ１を取得する。さらに、スケジューラ７は、そのリソース利用状況表Ｈ１に基づいてスレッドＴ１〜Ｔ３間の関連度（関連レベル）を決定し、そのスレッドＴ１〜Ｔ３間の関連度を示す関連情報として関連表Ｈ２を取得する。なお、スケジューラ７は、リソース利用状況表Ｈ１に基づいて、スレッドＴ１〜Ｔ３間の関連度を高レベル（Ｈ）又は低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。

スレッドＴ１〜Ｔ３間の関連度は、アクセス先のリソースに応じて、例えばセマフォ、共有メモリ、パイプ、メッセージ、ファイルの順序で低くなり、セマフォ＞共有メモリ＞パイプ＞メッセージ＞ファイルという関係式で表される。なお、第２の実施の形態では、セマフォ及び共有メモリを高レベルとし、パイプ、メッセージ及びファイルを低レベルとし、スレッドＴ１〜Ｔ３間の関連度を２つのレベルに分けている。このように第２の実施の形態では、スレッドＴ１〜Ｔ３間の関連度は、リソース毎に予め期待される共用度に応じて設定されている。

次に、このような構成のクラスタシステム１のサービス提供動作について説明する。クラスタシステム１内のノード２はクライアント端末からの実行要求により指定されたサービスを実行する。

このとき、図２に示すように、まず、スケジューラ７が各ノード２にサービス（プログラム）を実行単位毎、すなわちスレッドＴ１〜Ｔ３毎に各ノード２に割り当てる（ステップＳ１）。これにより、各スレッドＴ１〜Ｔ３は各ノード２に振り分けられる。これに応じて、各ノード２がそれぞれ対応するＯＳ５により各スレッドＴ１〜Ｔ３を実行する。

例えば、図４に示すように、スレッドＴ１〜Ｔ３がノード２（図４中のノードＡ）に割り当てられる。これに応じて、ノード２（図４中のノードＡ）がＯＳ５（図４中のＯＳＡ）により各スレッドＴ１〜Ｔ３を実行する。

次いで、図２に示すように、スケジューラ７は、ＡＰＩ６からプロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を取得し、リソース利用状況情報としてリソース利用状況表Ｈ１を得て、さらに、そのリソース利用状況表Ｈ１に基づいてスレッドＴ１〜Ｔ３間の関連度を決定し、そのスレッドＴ１〜Ｔ３間の関連度を示す関連情報として関連表Ｈ２を取得する（ステップＳ２）。

詳しくは、スケジューラ７は、ＡＰＩ６からプロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を取得し、スレッドＴ１〜Ｔ３が存在するノード２を常に把握し、取得した各スレッドＴ１〜Ｔ３のリソース利用状況を集計し、リソース利用状況表Ｈ１を作成又は更新する。さらに、スケジューラ７は、リソースに対するアクセス状態や待ち状態等に関するアクセス情報（例えば更新頻度）を収集し、そのアクセス情報に基づいてスレッドＴ１〜Ｔ３間の実行に関する依存関係を導出し、その依存関係に基づいてスレッドＴ１〜Ｔ３間の関連度を高レベル（Ｈ）又は低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。

例えば、図４に示すように、スケジューラ７は、ＡＰＩ６からプロセスＰ１の各スレッドＴ１〜Ｔ３のリソース利用状況を取得し、各スレッドＴ１〜Ｔ３がノード２（図４中のノードＡ）に存在することを把握し、さらに、スレッドＴ１及びスレッドＴ２が共有メモリ（図４中のリソースＸ１）にアクセスしていることと、スレッドＴ２及びスレッドＴ３がディスク３のファイル（図４中のリソースＸ２）にアクセスしていることを把握し、リソース利用状況表Ｈ１を作成又は更新する。さらに、スケジューラ７は、リソース利用状況表Ｈ１に基づいて、スレッドＴ１及びスレッドＴ２間の関連度を高レベル（Ｈ）と決定し、スレッドＴ２及びスレッドＴ３間の関連度を低レベル（Ｌ）と決定し、関連表Ｈ２を作成又は更新する。

ここで、図４に示すリソース利用状況表Ｈ１では、リソース利用状況がリソースＸ１、Ｘ２毎に示されている。Ｘ１：Ｐ１−Ｔ１＠Ａ，Ｐ１−Ｔ２＠Ａとは、リソースＸ１がノード２（図４中のノードＡ）上のプロセスＰ１のスレッドＴ１と、同じくノード２（図４中のノードＡ）上のプロセスＰ１のスレッドＴ２とによりアクセスされていることを示している。また、Ｘ２：Ｐ１−Ｔ２＠Ａ，Ｐ１−Ｔ３＠Ａとは、リソースＸ２がノード２（図４中のノードＡ）上のプロセスＰ１のスレッドＴ２と、同じくノード２（図４中のノードＡ）上のスレッドＴ３によりアクセスされていることを示している。

また、図４に示す関連表Ｈ２では、スレッドＴ１〜Ｔ３間の関連度がスレッドＴ１〜Ｔ３間毎に示されている。（Ｐ１−Ｔ１，Ｐ１−Ｔ２）＝（Ｘ１：Ｈ）とは、プロセスＰ１のスレッドＴ１及びスレッドＴ２が共有メモリ（図４中のリソースＸ１）にアクセスしており、それらの関連度が高レベルであることを示している。一方、（Ｐ１−Ｔ２，Ｐ１−Ｔ３）＝（Ｘ２：Ｌ）とは、プロセスＰ１のスレッドＴ２及びスレッドＴ３がファイル（図４中のリソースＸ２）にアクセスしており、それらの関連度が低レベルであることを示している。

最後に、図２に示すように、スケジューラ７は、リソース利用状況表Ｈ１及びプロセスの関連表Ｈ２に基づいて、関連度が低レベルである（関連度が低い）スレッドＴ３を現在のノード２から他のノード２に移動させ、スレッドマイグレーション、すなわち負荷分散を行う（ステップＳ３）。このような処理が繰り返される。

詳しくは、スケジューラ７は、スレッドＴ１〜Ｔ３間の関連度が低レベルであると決定した場合、スレッドＴ１〜Ｔ３間に関連性が存在していても、関連度が低いスレッドＴ３を他のノード２に移動させるスレッドマイグレーションが可能であると判断し、関連度が低いスレッドＴ３を各ＯＳ５のリソース利用状況に基づいてリソース的な余裕があるＯＳ５、すなわちノード２に移動させる。このようにして、スレッドマイグレーションが行われ、負荷分散が実現される。

例えば、関連表Ｈ２に基づいて、図５に示すように、関連度が低いスレッドＴ３がノード２（図５中のノードＡ）からの他のノード２（図５中のノードＢ）に移動する。これに応じて、ノード２（図５中のノードＡ）がＯＳ５（図５中のＯＳＡ）によりプロセスＰ１のスレッドＴ１、Ｔ２を実行し、ノード２（図５中のノードＢ）がＯＳ５（図５中のＯＳＢ）によりプロセスＰ１のスレッドＴ３を実行することになる。これにより、各ノード２に対する負荷が分散される。

なお、図４中のリソース利用状況表Ｈ１に示すＸ２：Ｐ１−Ｔ２＠Ａ，Ｐ１−Ｔ３＠Ａは、図５中のリソース利用状況表Ｈ１に示すように、Ｘ２：Ｐ１−Ｔ２＠Ａ，Ｐ１−Ｔ３＠Ｂに更新される。ここで、Ｘ２：Ｐ１−Ｔ２＠Ａ，Ｐ１−Ｔ３＠Ｂとは、リソースＸ２がノード２（図５中のノードＡ）上のプロセスＰ１のスレッドＴ２と、ノード２（図５中のノードＢ）上のプロセスＰ１のスレッドＴ３とによりアクセスされていることを示している。

以上説明したように、第２の実施の形態によれば、プロセスＰ１のスレッドＴ１〜Ｔ３毎のリソース利用状況を取得し、取得したスレッドＴ１〜Ｔ３毎のリソース利用状況に基づいてスレッドＴ１〜Ｔ３間の関連度を決定し、その関連度を示す関連情報として関連表Ｈ２を取得し、取得した関連表Ｈ２に基づいて、関連度が低いスレッドＴ３を現在のノード２（図５中のノードＡ）から他のノード２（図５中のノードＢ）に移動させることによって、関連性が強いスレッドＴ１、Ｔ２同士は同じノード２（図５中のノードＡ）上に存在することになるので、リソース間の不要な送受信の発生が防止され、さらに、関連性が強いスレッドＴ１、Ｔ２同士が存在するノード２（図５中のノードＡ）上に関連性が弱いスレッドＴ３が存在しなくなるので、全てのノード２の負荷が均一に抑えられる。このようにして、スレッドＴ１〜Ｔ３間の関連度に応じて適切に負荷を分散し、負荷の均一化を実現することができる。特に、同じプロセスＰ１内のスレッドＴ１〜Ｔ３を他のノード２に移動させることが可能になるので、より負荷の均一化を実現することができる。

（第３の実施の形態）
本発明の第３の実施の形態について図６及び図７を参照して説明する。

本発明の第３の実施の形態は、基本的に第２の実施の形態と同様である。第３の実施の形態では、第２の実施の形態との相違点について説明する。

第３の実施の形態では、複数のノード２が１つのＯＳ５に基づいてそれぞれ動作する。すなわち、ＯＳ５は、シングルシステムイメージのオペレーティングシステムである。また、プロセスＰ１は複数のスレッドＴ１、Ｔ２を有しており、プロセスＰ２はスレッドＴ３を有しいている。

このような構成のクラスタシステム１のサービス提供動作は第２の実施の形態と同様である。例えば、図６に示すように、プロセスＰ１のスレッドＴ１、Ｔ２及びプロセスＰ２のスレッドＴ３がノード２（図６中のノードＡ）に割り当てられる。これに応じて、ノード２（図６中のノードＡ）がＯＳ５により各スレッドＴ１〜Ｔ３を実行する。このとき、各ＡＰＩ６から各スレッドＴ１〜Ｔ３のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。その後、関連表Ｈ２に基づいて、図７に示すように、関連度が低いスレッドＴ３がノード２（図７中のノードＡ）からの他のノード２（図７中のノードＢ）に移動する。これに応じて、ノード２（図７中のノードＡ）がＯＳ５によりプロセスＰ１のスレッドＴ１、Ｔ２を実行し、ノード２（図７中のノードＢ）がＯＳ５によりプロセスＰ２のスレッドＴ３を実行することになる。これにより、各ノード２に対する負荷が分散される。

なお、図６中のリソース利用状況表Ｈ１に示すＸ２：Ｐ１−Ｔ２＠Ａ，Ｐ２−Ｔ３＠Ａは、図７中のリソース利用状況表Ｈ１に示すように、Ｘ２：Ｐ１−Ｔ２＠Ａ，Ｐ２−Ｔ３＠Ｂに更新される。ここで、Ｘ２：Ｐ１−Ｔ２＠Ａ，Ｐ２−Ｔ３＠Ｂとは、リソースＸ２がノード２（図５中のノードＡ）上のプロセスＰ１のスレッドＴ２と、ノード２（図５中のノードＢ）上のプロセスＰ２のスレッドＴ３とによりアクセスされていることを示している。

以上説明したように、第３の実施の形態によれば、シングルシステムイメージのＯＳ５においても、第２の実施の形態と同様の効果を得ることができる。

（第４の実施の形態）
本発明の第４の実施の形態について図８を参照して説明する。

本発明の第４の実施の形態は、基本的に第３の実施の形態と同様である。第４の実施の形態では、第３の実施の形態との相違点について説明する。

ＯＳ５では、図８に示すように、スケジューラ７の機能の一部を代行するＯＳスケジューラ８が動作する。ＯＳスケジューラ８は、各ノード２に対するプロセスＰ１〜Ｐ２及びスレッドＴ１〜Ｔ３の割り当てを監視し、スレッドＴ１〜Ｔ３が存在するノード２を示す情報（図８中のＴ１＠Ａ、Ｔ２＠Ａ、Ｔ３＠Ａ）を含むリソース情報を保持する機構を有する。また、ＯＳスケジューラ８は、スケジューラ７と通信を行う機能を有し、スケジューラ７から提供される情報、例えば関連情報（図８中の関連表Ｈ２）を利用してスケジューリングを行う。このＯＳスケジューラ８は、スケジューラ７から取得した関連情報（図８中の関連表Ｈ２）をリソース情報（図８中のＴ１＠Ａ、Ｔ２＠Ａ、Ｔ３＠Ａ）と合わせることによって、各ノード２に対するスレッドＴ１〜Ｔ３の配置を決定する。

このような構成のクラスタシステム１のサービス提供動作は第３の実施の形態と同様である。例えば、図８に示すように、プロセスＰ１のスレッドＴ１、Ｔ２及びプロセスＰ２のスレッドＴ３がノード２（図８中のノードＡ）に割り当てられる。これに応じて、ノード２（図８中のノードＡ）がＯＳ５により各スレッドＴ１〜Ｔ３を実行する。このとき、各ＡＰＩ６から各スレッドＴ１〜Ｔ３のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。その後、関連表Ｈ２に基づいて、関連度が低いスレッドＴ３がノード２（図８中のノードＡ）からの他のノード２（図８中のノードＢ）に移動する。これに応じて、ノード２（図８中のノードＡ）がＯＳ５によりプロセスＰ１のスレッドＴ１、Ｔ２を実行し、ノード２（図８中のノードＢ）がＯＳ５によりプロセスＰ２のスレッドＴ３を実行することになる。これにより、各ノード２に対する負荷が分散される。

以上説明したように、第４の実施の形態によれば、第３の実施の形態と同様の効果を得ることができ、さらに、ＯＳスケジューラ８がスケジューラ７の一部の機能を代行することによって、スケジューラ７の負荷を軽減することができる。

（第５の実施の形態）
本発明の第５の実施の形態について図９を参照して説明する。

本発明の第５の実施の形態は、基本的に第３の実施の形態と同様である。第５の実施の形態では、第３の実施の形態との相違点について説明する。

第５の実施の形態は、マルチスレッドをサポートするコンピュータシステムに負荷分散システムを適応した一適応例である。第５の実施の形態では、図９に示すように、コンピュータシステム１１は、複数のＣＰＵ（中央処理装置）１２及びディスク１３をネットワーク１４により相互に接続することによって構成されている。

なお、第５の実施の形態では、サービスが複数のＣＰＵ１２により同時並行して実行可能なタイプ、例えば並列実行型のプログラムであるため、各ＣＰＵ１２がそれぞれシステム資源となる。

ＣＰＵ１２はキャッシュメモリ（図示せず）を備えている。また、ディスク１３は、ファイル等の各種データを記憶する記憶装置である。このディスク１３は、各ディスク１３に対して共有の記憶装置として機能する。ネットワーク１４としては、バスライン等のネットワークを用いる。

このような構成のクラスタシステム１のサービス提供動作は第３の実施の形態と同様である。例えば、図９に示すように、プロセスＰ１のスレッドＴ１、Ｔ２及びプロセスＰ２のスレッドＴ３がＣＰＵ１２（図９中のＣＰＵＡ）に割り当てられる。これに応じて、ＣＰＵ１２（図９中のＣＰＵＡ）がＯＳ５により各スレッドＴ１〜Ｔ３を実行する。このとき、ＡＰＩ６から各スレッドＴ１〜Ｔ３のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。その後、関連表Ｈ２に基づいて、関連度が低いスレッドＴ３がＣＰＵ１２（図９中のＣＰＵＡ）からの他のＣＰＵ１２（図９中のＣＰＵＢ）に移動する。これに応じて、ＣＰＵ１２（図９中のＣＰＵＡ）がＯＳ５によりプロセスＰ１のスレッドＴ１、Ｔ２を実行し、ＣＰＵ１２（図９中のＣＰＵＢ）がＯＳ５によりプロセスＰ２のスレッドＴ３を実行することになる。これにより、各ＣＰＵ１２に対する負荷が分散される。

以上説明したように、第５の実施の形態によれば、第３の実施の形態と同様の効果を得ることができ、さらに、ＣＰＵ１２に対するスケジュールが可能となり、ＣＰＵ１２のキャッシュメモリの利用効率の低下を防止することができる。

（第６の実施の形態）
本発明の第６の実施の形態について図１０を参照して説明する。

本発明の第６の実施の形態は、基本的に第５の実施の形態と同様である。第６の実施の形態では、第５の実施の形態との相違点について説明する。

第６の実施の形態では、図１０に示すように、マルチコアＣＰＵ１５がＣＰＵ１２に代えて設けられている。マルチコアＣＰＵ１５は、２つのＣＰＵ１２及びキャッシュメモリ（図示せず）を備えている。２つのＣＰＵ１２はキャッシュメモリを共有している。

このような構成のクラスタシステム１のサービス提供動作は第５の実施の形態と同様である（図２参照）。例えば、図１０に示すように、プロセスＰ１のスレッドＴ１、Ｔ２及びプロセスＰ２のスレッドＴ３がマルチコアＣＰＵ１５のＣＰＵ１２（図１０中のＣＰＵＡ）に割り当てられる。これに応じて、ＣＰＵ１２（図１０中のＣＰＵＡ）がＯＳ５により各スレッドＴ１〜Ｔ３を実行する。このとき、各ＡＰＩ６から各スレッドＴ１〜Ｔ３のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。

その後、関連表Ｈ２に基づいて、関連度が低いスレッドＴ３がマルチコアＣＰＵ１５のＣＰＵ１２（図１０中のＣＰＵＡ）からの他のマルチコアＣＰＵ１５のＣＰＵ１２（図１０中のＣＰＵＣ）に移動する。これに応じて、ＣＰＵ１２（図１０中のＣＰＵＡ）がＯＳ５によりスレッドＴ１、Ｔ２を実行し、マルチコアＣＰＵ１５（図１０中のＣＰＵＣ）がＯＳ５によりスレッドＴ３を実行することになる。これにより、各ＣＰＵ１２に対する負荷が分散される。

以上説明したように、第６の実施の形態によれば、マルチコアＣＰＵ１５を用いた場合でも、第５の実施の形態と同様の効果を得ることができる。

なお、関連表Ｈ２に基づいて、関連度が高いスレッドＴ２をマルチコアＣＰＵ１５のＣＰＵ１２（図１０中のＣＰＵＡ）から同一コア内の他のＣＰＵ１２（図１０中のＣＰＵＢ）に移動させるようにしてもよい。これにより、マルチコアＣＰＵ１５のＣＰＵ１２（図１０中のＣＰＵＡ）の負荷が低減されるので、各ＣＰＵ１２に対する負荷をより分散することができる。

（第７の実施の形態）
本発明の第７の実施の形態について図１１を参照して説明する。

本発明の第７の実施の形態は、基本的に第６の実施の形態と同様である。第７の実施の形態では、第６の実施の形態との相違点について説明する。

第７の実施の形態では、図１１に示すように、マルチコアＣＰＵ１５が、２つのＣＰＵ１２及びキャッシュメモリ（図示せず）に加え、スケジューラユニット１６を備えている。２つのＣＰＵ１２はキャッシュメモリを共有している。

スケジューラユニット１６は、スケジューラ７と通信することによりマルチコアＣＰＵ１５内におけるスレッド割り当て及びキャッシュ割り当てを制御するユニットである。また、スケジューラユニット１６は、スレッドＴ１〜Ｔ３の実行順序及びキャッシュの制御を行う。

このような構成のクラスタシステム１のサービス提供動作は第６の実施の形態と同様である。例えば、図１１に示すように、プロセスＰ１のスレッドＴ１、Ｔ２及びプロセスＰ２のスレッドＴ３がマルチコアＣＰＵ１５のＣＰＵ１２（図１１中のＣＰＵＡ）に割り当てられる。これに応じて、ＣＰＵ１２（図１１中のＣＰＵＡ）がＯＳ５により各スレッドＴ１〜Ｔ３を実行する。このとき、各ＡＰＩ６から各スレッドＴ１〜Ｔ３のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。

その後、関連表Ｈ２に基づいて、関連度が低いスレッドＴ３がマルチコアＣＰＵ１５のＣＰＵ１２（図１１中のＣＰＵＡ）からの他のマルチコアＣＰＵ１５のＣＰＵ１２（図１１中のＣＰＵＢ）に移動する。これに応じて、ＣＰＵ１２（図１１中のＣＰＵＡ）がＯＳ５によりスレッドＴ１、Ｔ２を実行し、ＣＰＵ１２（図１１中のＣＰＵＣ）がＯＳ５によりスレッドＴ３を実行することになる。これにより、各ＣＰＵ１２に対する負荷が分散される。

また、スレッドＴ１及びスレッドＴ２間の関連度が高い場合には、スレッドＴ１がアクセスしているキャッシュメモリがエージアウトされると、スレッドＴ２がアクセスしているキャッシュメモリの優先順位が下げられ、キャッシュ効率の向上が図られる。

以上説明したように、第７の実施の形態によれば、スケジューラユニット１６を備えるマルチコアＣＰＵ１５を用いた場合でも、第６の実施の形態と同様の効果を得ることができる。

なお、関連表Ｈ２に基づいて、関連度が高いスレッドＴ２をマルチコアＣＰＵ１５のＣＰＵ１２（図１１中のＣＰＵＡ）から同一コア内の他のＣＰＵ１２（図１１中のＣＰＵＢ）に移動させるようにしてもよい。これにより、マルチコアＣＰＵ１５のＣＰＵ１２（図１１中のＣＰＵＡ）の負荷が低減されるので、各ＣＰＵ１２に対する負荷をより分散することができる。

（第８の実施の形態）
本発明の第８の実施の形態について図１２を参照して説明する。

本発明の第８の実施の形態は、基本的に第１の実施の形態と同様である。第８の実施の形態では、第１の実施の形態との相違点について説明する。

第８の実施の形態では、図１２に示すように（図１２中の関連表Ｈ２参照）、セマフォ及び共有メモリ１を高レベル（Ｈ）とし、パイプ及び共有メモリ２を中レベル（Ｍ）とし、メッセージ及びファイルを低レベル（Ｌ）とし、プロセスＰ１〜Ｐ３間の関連度を３つのレベルに分けている。なお、共有メモリが共有メモリ１及び共有メモリ２に分割されている。

このような構成のクラスタシステム１のサービス提供動作は第１の実施の形態と同様である。例えば、図１２に示すように、プロセスＰ１〜Ｐ４がノード２（図１２中のノードＡ）に割り当てられる。これに応じて、ノード２（図１２中のノードＡ）がＯＳ５（図１２中のＯＳＡ）により各プロセスＰ１〜Ｐ４を実行する。このとき、各ＡＰＩ６から各プロセスＰ１〜Ｐ４のリソース利用状況が取得され、リソース利用状況表Ｈ１及び関連表Ｈ２が作成又は更新される。

その後、関連表Ｈ２に基づいて、関連度が低いプロセスＰ４がノード２（図１２中のノードＡ）からの他のノード２（図１２中のノードＢ）に移動する。これに応じて、ノード２（図１２中のノードＡ）がＯＳ５（図１２中のＯＳＡ）によりプロセスＰ１〜Ｐ３を実行し、ノード２（図１２中のノードＢ）がＯＳ５（図１２中のＯＳＢ）によりプロセスＰ４を実行することになる。これにより、各ノード２に対する負荷が分散される。

以上説明したように、第８の実施の形態によれば、第１の実施の形態と同様の効果を得ることができ、特に、プロセスＰ１〜Ｐ４間の関連度を細かく分けることによって、全てのノード２の負荷をより均一に抑えることができる。

（他の実施の形態）
なお、本発明は、前述の実施の形態に限るものではなく、その要旨を逸脱しない範囲において種々変更可能である。

例えば、前述の実施の形態においては、セマフォ及び共有メモリを高レベル（Ｈ）とし、パイプ、メッセージ及びファイルを低レベル（Ｌ）とし、プロセスＰ１〜Ｐ３間の関連度又はスレッドＴ１〜Ｔ３の関連度を２つのレベルに分けたり、セマフォ及び共有メモリ１を高レベル（Ｈ）とし、パイプ及び共有メモリ２を中レベル（Ｍ）とし、メッセージ及びファイルを低レベル（Ｌ）とし、プロセスＰ１〜Ｐ３間の関連度又はスレッドＴ１〜Ｔ３の関連度を３つのレベルに分けたりしているが、これに限るものではなく、例えば４つ以上の複数のレベルに分けるようにしてもよい。

また、前述の実施の形態においては、プロセスＰ１〜Ｐ３間の関連度又はスレッドＴ１〜Ｔ３の関連度を予め設定しているが、これに限るものではなく、例えばＡＰＩ６によりリソースのアクセス具合（共用度を含む）を取得することが可能であるため、プロセスＰ１〜Ｐ３間の関連度又はスレッドＴ１〜Ｔ３の関連度をその都度見直すようにしてもよい。

また、前述の実施の形態においては、関連度が低い実行単位として低レベルのプロセスＰ１〜Ｐ３又は低レベルのスレッドＴ１〜Ｔ３を移動させているが、これに限るものではなく、例えば関連度が低い実行単位として低レベルのプロセスＰ１〜Ｐ３又は低レベルのスレッドＴ１〜Ｔ３に加え、中レベルのプロセスＰ１〜Ｐ３又は中レベルのスレッドＴ１〜Ｔ３も移動させるようにしてもよい。

また、前述の実施の形態においては、関連表Ｈ２をプロセスＰ１〜Ｐ３間単位やスレッドＴ１〜Ｔ３間単位等で作成しているが、これに限るものではなく、例えば、プロセス単位で作成するようにしてもよく、さらに、リソース単位に作成するようにしてもよい。

本発明の第１の実施の形態に係るクラスタシステムの概略構成を示す模式図である。 図１に示すクラスタシステムの負荷分散処理の流れを示すフローチャートである。 図１に示すクラスタシステムの負荷分散を説明するための模式図である。 本発明の第２の実施の形態に係るクラスタシステムの概略構成を示す模式図である。 図４に示すクラスタシステムの負荷分散を説明するための模式図である。 本発明の第３の実施の形態に係るクラスタシステムの概略構成を示す模式図である。 図６に示すクラスタシステムの負荷分散を説明するための模式図である。 本発明の第４の実施の形態に係るクラスタシステムの概略構成を示す模式図である。 本発明の第５の実施の形態に係るコンピュータシステムの概略構成を示す模式図である。 本発明の第６の実施の形態に係るコンピュータシステムの概略構成を示す模式図である。 本発明の第７の実施の形態に係るコンピュータシステムの概略構成を示す模式図である。 本発明の第８の実施の形態に係るクラスタシステムの概略構成を示す模式図である。

符号の説明

１，１１…負荷分散システム（クラスタシステム又はコンピュータシステム）、２，１２，１５…システム資源（ノード又は中央処理装置）、５…オペレーティングシステム、Ｐ１〜Ｐ３，Ｔ１〜Ｔ３…実行単位（プロセス又はスレッド）

Claims (16)

1. オペレーティングシステムに基づいてそれぞれ動作する複数のシステム資源に対し、プログラムを実行単位毎に割り当てる手段と、
   前記実行単位毎のリソース利用状況を取得し、取得した前記実行単位毎のリソース利用状況に基づいて前記実行単位間の関連度を決定し、前記実行単位間の関連度を示す関連情報を取得する手段と、
   取得した前記関連情報に基づいて、前記関連度が低い前記実行単位を他の前記システム資源に移動させる手段と、
   を備えることを特徴とする負荷分散システム。
2. 複数の前記システム資源は、それぞれ対応する複数の前記オペレーティングシステムに基づいてそれぞれ動作することを特徴とする請求項１記載の負荷分散システム。
3. 複数の前記システム資源は、１つのオペレーティングシステムに基づいてそれぞれ動作することを特徴とする請求項１記載の負荷分散システム。
4. 前記実行単位はプロセスであることを特徴とする請求項１ないし３のいずれか一に記載の負荷分散システム。
5. 前記実行単位はスレッドであることを特徴とする請求項１ないし３のいずれか一に記載の負荷分散システム。
6. 前記システム資源はノードであることを特徴とする請求項１ないし５のいずれか一に記載の負荷分散システム。
7. 前記システム資源は中央処理装置であることを特徴とする請求項１ないし５のいずれか一に記載の負荷分散システム。
8. 前記中央処理装置はマルチコアの中央処理装置であることを特徴とする請求項７に記載の負荷分散システム。
9. オペレーティングシステムに基づいてそれぞれ動作する複数のシステム資源に対し、プログラムを実行単位毎に割り当てるステップと、
   前記実行単位毎のリソース利用状況を取得し、取得した前記実行単位毎のリソース利用状況に基づいて前記実行単位間の関連度を決定し、前記実行単位間の関連度を示す関連情報を取得するステップと、
   取得した前記関連情報に基づいて、前記関連度が低い前記実行単位を他の前記システム資源に移動させるステップと、
   を備えることを特徴とする負荷分散方法。
10. 複数の前記システム資源は、それぞれ対応する複数の前記オペレーティングシステムに基づいてそれぞれ動作することを特徴とする請求項９記載の負荷分散方法。
11. 複数の前記システム資源は、１つのオペレーティングシステムに基づいてそれぞれ動作することを特徴とする請求項９記載の負荷分散方法。
12. 前記実行単位はプロセスであることを特徴とする請求項９ないし１１のいずれか一に記載の負荷分散方法。
13. 前記実行単位はスレッドであることを特徴とする請求項９ないし１１のいずれか一に記載の負荷分散方法。
14. 前記システム資源はノードであることを特徴とする請求項９ないし１３のいずれか一に記載の負荷分散方法。
15. 前記システム資源は中央処理装置であることを特徴とする請求項９ないし１３のいずれか一に記載の負荷分散方法。
16. 前記中央処理装置はマルチコアの中央処理装置であることを特徴とする請求項１５に記載の負荷分散方法。
    
    
    

Images