JP2016139171A - リソース割当装置、リソース割当システム、および、リソース割当方法 - Google Patents

Abstract

【課題】共有リソースにアクセスするプロセスが複数存在するときに、システムの利用効率を高めること。【解決手段】リソース割当装置１は、１つの共有リソースを利用するプロセスについて、同じ共有リソースを利用するプロセスの集合をグループ化し、前記同じ共有リソースにアクセス可能な物理サーバ２内の同じコア上に、グループ化されたプロセスの集合をまとめて割り当てるプロセス割当部１３を有する。物理サーバ２の各コアは、自身に割り当てられたグループ化されたプロセスの集合を実行するときに、あるプロセスの終了を待ってから別のプロセスを開始する。【選択図】図１

Description

本発明は、リソース割当装置、リソース割当システム、および、リソース割当方法の技術に関する。

共有データなどの共有リソースにアクセスするプロセスが複数存在するときには、同時アクセスなどによりデータの整合性がとれなくなることもある。そこで、非特許文献１には、排他ロックという同時アクセスの制御手段が記載されている。あるプロセスがあるデータに対して排他ロックをかけると、他のプロセスがそのデータに対してアクセスすることができなくなる。これにより、リソースにアクセスできるプロセスを限定することで、データの整合性を担保することができる。

なお、共有データに排他ロックをかけたプロセスは、その共有データに対する処理を終えると、ロックを解放する。その後、他のプロセスはその共有データにアクセス可能となる。
非特許文献２には、排他ロックを用いる副作用として、特定の条件下でプロセスが共有データのロックを解放しても、他のプロセスが共有データにアクセスできない事象が記載されている。

E. W. DIJKSTRA著、「Solution of a Problem in Concurrent Programming Control」、Communications of the ACM、Volume 8,Number 9、Sept.1965、p.569 北野雄大著、「マルチコア環境における処理遅延に関する一考察」、Proceedings of the 2013 IEICE Society Conference, B-16-3, Sep.2013

なお、共有データを用いてプロセスが処理できるようになるには、共有データにアクセスするための排他ロックに成功した上で、自身のプロセスが動作する計算機資源（ＣＰＵなど）に余裕があることが必要である。

一方、排他ロックに成功しても計算機資源に余裕がない場合や、計算機資源に余裕があっても他プロセスが先に排他ロックをしてしまった場合には、プロセスにとって余計な待ち時間が発生してしまう。よって、システム全体では処理能力に余裕があっても、共有リソースにアクセスするプロセスが複数存在するときには、システムの利用効率を充分に高められていなかった。
なお、システムの利用効率が悪いと、ある箇所は資源が遊休しているが、別の箇所では負荷が局所的に集中してしまうことで、システム全体の処理結果が少なくなってしまう。

そこで、本発明は、共有リソースにアクセスするプロセスが複数存在するときに、システムの利用効率を高めることを、主な課題とする。

前記課題を解決するために、本発明は、１つの共有リソースを利用するプログラムの実行単位について、同じ共有リソースを利用する前記実行単位の集合をグループ化し、前記同じ共有リソースにアクセス可能な物理サーバ内の同じ演算手段上に、グループ化された前記実行単位の集合をまとめて割り当てる割当手段を有することを特徴とする。

これにより、グループ化された実行単位の集合は同時に実行されないので、共有リソースにアクセス可能な実行単位が、適切に演算手段の計算機資源を利用することで、システムの利用効率を高めることができる。さらに、共有リソースへの障害発生時にはその影響範囲を同じグループとして容易に特定できる。

本発明は、複数の共有リソースを利用する前記実行単位の入力を受け付け、その共有リソースにアクセスするための、利用する共有リソースごとの呼出先の実行単位と、それらの呼出先の実行単位に対してアクセスの指示を呼び出すための呼出元の実行単位とに分割し、呼出先の実行単位をグループ化の対象とする分割手段を有することを特徴とする。

これにより、複数の共有リソースを利用するような複雑なプログラムでも、システムの利用効率を高めることができる。

本発明は、前記割当手段によって第１の演算手段上に割り当てられた前記実行単位を、第２の演算手段上に移動するとき、前記第１の演算手段上に割り当てられた同じグループに属する前記実行単位の集合をまとめて前記第２の演算手段上に移動する移動手段を有することを特徴とする。

これにより、共有リソースの物理的な移動などのシステム構成が変更されたときや、割当先の演算手段が混雑したときなどでも、システムの利用効率を高めつつ低コストで対応できる。

本発明は、前記割当手段が、割当候補である複数の演算手段について、各演算手段に割り当てられる実行単位の数が均等になるように、割当先の演算手段を選択することを特徴とする。

これにより、容易に各演算手段の負荷分散を実現できる。

本発明は、前記割当手段が、割当候補である複数の演算手段について、各演算手段に割り当てられる実行単位が発生される負荷が均等になるように、割当先の演算手段を選択することを特徴とする。

これにより、高精度に各演算手段の負荷分散を実現できる。

本発明は、前記割当手段が、割当候補である複数の演算手段について、前記同じ共有リソースにアクセス可能な各演算手段のうちのアクセスコストが最小の演算手段を選択することを特徴とする。

これにより、実行単位の実行時のスループットを向上させることができる。

本発明の各演算手段は、自身に割り当てられたグループ化された前記実行単位の集合を実行するときに、ある実行単位の終了を待ってから別の実行単位を開始し、
所定の実行単位の実行時間が所定時間を経過したときには、その所定の実行単位をタイムアウトさせることを特徴とする。

これにより、グループ内での実行単位間の排他制御が行われることで、共有リソースのデータ内容の整合性を保証できる。

本発明によれば、共有リソースにアクセスするプロセスが複数存在するときに、システムの利用効率を高めることができる。

本発明の一実施形態に関するリソース割当システムを示す構成図である。 本発明の一実施形態に関するリソース割当方法を示すフローチャートである。 図３（ａ）は、グループ化されたリソースの割当処理を示す説明図である。図３（ｂ）は、グループ化されていないリソース割当処理の問題点を示す説明図である。 本発明の一実施形態に関するプロセス分割処理を示す説明図である。 図５（ａ）は、図３（ａ）の構成におけるグループ管理テーブルを示す構成図である。図５（ｂ）は、図４の構成におけるグループ管理テーブルを示す構成図である。 図６（ａ）は、第１の割当例における割当前のグループ管理テーブルを示す構成図である。図６（ｂ）は、第１の割当例における割当後のグループ管理テーブルを示す構成図である。 図７（ａ）は、第２の割当例における割当前のグループ管理テーブルを示す構成図である。図７（ｂ）は、プロセス重みテーブルを示す構成図である。図７（ｃ）は、第２の割当例における割当後のグループ管理テーブルを示す構成図である。 図８（ａ）は、第３の割当例における割当前のグループ管理テーブルを示す構成図である。図８（ｂ）は、ＶＭ管理テーブルを示す構成図である。図８（ｃ）は、第３の割当例における割当後のグループ管理テーブルを示す構成図である。 図９（ａ）は、グループ化されたプロセスの移動処理を示す構成図である。図９（ｂ）は、グループ化されていないプロセスの移動処理の問題点を示す構成図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、リソース割当システムを示す構成図である。
リソース割当システムは、リソースを提供する１台以上の物理サーバ２と、その物理サーバ２に対してプロセス（または、スレッド、タスク、ジョブなどのプログラムの実行単位）を配置することで、配置されたプロセスにリソースを割り当てるリソース割当装置１とがネットワークで接続されて構成される。
リソース割当システムの各装置は、ＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。

なお、図１では、１台のリソース割当装置１が２つの物理サーバ２を外からまとめて管理（接続）する構成を例示した。一方、各物理サーバ２ごとに別々のリソース割当装置１を内蔵させ、物理サーバ２とリソース割当装置１とを同一筐体として構成してもよい。なお、同一筐体とする場合、物理サーバ２のＶＭを管理するホストＯＳなどに、リソース割当装置１の各手段を搭載すればよい。

各物理サーバ２は、１つ以上のＣＰＵコア（以下、「コア」と略す）と、そのコアが実行する処理で利用されるデータの記憶手段（メモリ、ハードディスクなど）とを有する。なお、１台の物理サーバ２内に複数のコア（マルチコア）が存在してもよい。
さらに、物理サーバ２は、コアなどの計算機資源を管理するＶＭ（Virtual Machine）を構築してもよい。ＶＭ内に計算機資源を隠蔽することで、利用者（利用者のプロセス）に対してハードウェアの具体的な構成を意識させずに、計算機資源を使用させる。これにより、プロセス内にハードウェアの具体的な構成を明示する必要がなくなり、プロセスのプログラミング負担を軽減させることができる。

リソース割当装置１は、物理サーバ２の各コアに対して、プロセスを割り当てる。ここで、リソース割当装置１は、ＶＭを介さずに直接コアに対してプロセスを割り当ててもよいし、ＶＭを介して（ＶＭに指示を出して）コアに対してプロセスを割り当ててもよい。
なお、ＶＭに指示を出す場合、「コアＣ１に、プロセスＰ１を配置せよ」のようなハードウェアリソースを明示する（隠蔽しない）命令を受け付けるように、ＶＭを機能拡張する必要がある。

リソース割当装置１は、通信部１１、プロセス分割部１２、プロセス割当部１３、プロセス移動部１４、グループ管理テーブル１５、プロセス重みテーブル１６、および、ＶＭ管理テーブル１７を有する。以下、これらの各構成要素の詳細について、図１を参照しつつ、図２に沿って説明する。

図２は、リソース割当方法を示すフローチャートである。
Ｓ１１は、プロセス分割部１２によるプロセス分割要否の判定処理である。プロセス分割部１２は、リソース割当装置１に入力される割当対象の各プロセスについて、プロセスごとに分割が必要か否かを判定する。
まず、１つのプロセスが０または１つの共有リソース（例えば、図１の「データ」で示される共有データ）にアクセス（データリードまたはデータライト）する場合、そのプロセスは、分割が不要である（Ｓ１１，Ｎｏ）ので処理をＳ１３に進める。
一方、１つのプロセスが２つ以上の共有リソースにアクセスする場合、そのプロセスは、分割が必要である（Ｓ１１，Ｙｅｓ）ので処理をＳ１２に進める。

Ｓ１２は、プロセス分割部１２によるプロセス分割処理である。プロセス分割部１２は、Ｓ１１で分割が必要とされる１つの分割前プロセスを、１つの呼出元プロセスと複数の呼出先プロセスとに分割する。例えば、分割前プロセスが共有データＡ，Ｂ，Ｃにそれぞれアクセスする場合、その分割前プロセスは、１つの呼出元プロセスと３つの呼出先プロセス（合計４つのプロセス）へと分割される。

Ｓ１３は、プロセス割当部１３によるプロセスグループ化処理である。プロセス割当部１３は、Ｓ１１の分割が不要な各プロセスと、Ｓ１２で分割された各プロセスについて、同じ共有リソースにアクセスするプロセス群を１つのグループとしてグループ化する。なお、共有リソースにアクセスしないプロセス群は、グループ化しなくてもよい。そして、グループ管理テーブル１５には、Ｓ１３のグループ化された結果が格納される。
Ｓ１４は、プロセス割当部１３によるプロセス割当処理である。プロセス割当部１３は、Ｓ１３のグループごとにコアを割り当てるように、通信部１１を介して各コアに指示する。換言すると、同じグループに属するプロセス群は、同じコアにまとめて割り当てられる。この割当アルゴリズムは様々な手法を適用でき、プロセス重みテーブル１６およびＶＭ管理テーブル１７は、それらの手法で割当先を決定するために利用される（詳細は、図６〜図８の説明を参照）。

Ｓ１５は、プロセス移動部１４によるプロセス移動要否の判定処理である。プロセス割当部１３がすでに割り当てたプロセスが実行されるコア上に、他の優先度の高いプロセスが生起されるなどの理由により、割り当てたプロセスの実行時間が少なくなることもある。その場合、プロセス移動部１４は、あるコアに割当済みのプロセスを他のコアで実行するように移動させる（Ｓ１５，Ｙｅｓ）と判定し、処理をＳ１６に進める。一方、プロセスの移動が不要なら（Ｓ１５，Ｎｏ）処理を終了する。

Ｓ１６は、プロセス移動部１４によるプロセス移動処理である。Ｓ１４と同様に、プロセス移動部１４は、同じグループに属するプロセス群を、同じコアにまとめて移動するように、通信部１１を介して各コアに指示する。
このように、プロセスの初回割当（Ｓ１４）やプロセスの移動（Ｓ１６）において、同じ共有データにアクセスするプロセス群が別々のコアで実行されないようにすることで、同じ共有データへのアクセス競合を予防できる。

図３（ａ）は、Ｓ１３でグループ化されたリソースの割当処理（Ｓ１４）を示す説明図である。
コアＣ１には、共有データＤ１にアクセスするための、グループＧ１に属するプロセスＰ１，Ｐ４がまとめて割り当てられている。
コアＣ２には、共有データＤ２にアクセスするための、グループＧ２に属するプロセスＰ２が割り当てられている。
コアＣ３には、共有データＤ３にアクセスするための、グループＧ３に属するプロセスＰ３，Ｐ５がまとめて割り当てられている。

なお、各コアは、自身にグループとして割り当てられているプロセス群に対して、以下の排他制御を実施してもよい。例えば、グループＧ１に属するプロセスＰ１，Ｐ４について、プロセスＰ１，Ｐ４の順に実行し、プロセスＰ１の実行完了を待ってからプロセスＰ４を開始する（つまり、プロセスＰ１，Ｐ４を同時には実行しない）。排他制御における各プロセスの実行順序は、例えば、キュー（待ち行列）によって管理される。この排他制御自身は、コア上のＯＳが実行してもよいし、コア上のユーザプロセスが実行してもよい。

さらに、排他制御の例外処理として、プロセスＰ１の実行開始時刻からの経過時間が所定時間（例えば、１０分）を超えても実行終了しない場合、そのプロセスＰ１をフリーズなどの実行異常状態とみなして、プロセスＰ１を呼び出した呼出元プロセスに対して異常通知を行ったり、プロセスＰ１を中止（タイムアウト）して次のプロセスＰ４を実行させたりしてもよい。これにより、自由度の高い排他制御が可能となる。

図３（ｂ）は、比較例として、グループ化されていないリソース割当処理の問題点を示す説明図である。図３（ａ）と異なり、共有データＤ１にアクセスするプロセスＰ１と、同じ共有データＤ１にアクセスするプロセスＰ４とが異なるコアＣ１，Ｃ２に割り当てられている。
この比較例では、プロセスＰ１が共有データＤ１に排他ロックをかけることで、プロセスＰ４に対して共有データＤ１へのアクセスを禁止させる。その後プロセスＰ１が共有データＤ１の排他ロックを解除（アンロック）することで、プロセスＰ４に対して共有データＤ１へのアクセスを許可する。

しかし、プロセスＰ１，Ｐ４は、お互いにいつ排他ロックをかけるかなどの調整を行わないので、共有データＤ１に対する排他ロックやロック待ちが多発し、コアＣ１，Ｃ２などの計算機資源の利用効率が悪い。また、アンロック漏れによるデッドロックが発生した場合、共有データＤ１をセマフォ管理しているコアＣ１のＯＳに問い合わせるなど、原因の究明にコストがかかる。

図４は、プロセス分割部１２によるプロセス分割処理（Ｓ１２）を示す説明図である。
プロセス分割部１２は、図３（ａ）の５つのプロセスＰ１〜Ｐ５のうち、プロセスＰ２を分割対象（Ｓ１１，Ｙｅｓ）と判断したとする。そして、プロセスＰ２は、共有データＤ１，Ｄ３を読み込み、その和を計算して共有データＤ２へと書き出す処理であるとする。

プロセス分割部１２は、図４に示すように、１つのプロセスＰ２を４つのプロセスＰ２１〜Ｐ２４へと分割する。
プロセスＰ２４は、他の呼出先プロセスＰ２１〜Ｐ２３を呼び出す呼出元プロセスである。プロセスＰ２４は、コアＣ４に割り当てられ、グループには属さない。
プロセスＰ２１は、共有データＤ１を読み込む呼出先プロセスであり、グループＧ１に属する。プロセスＰ２４は、プロセスＰ２１とのソケット通信を介して、共有データＤ１のＩＤ値を指定した読み込み命令を通知する。
プロセスＰ２３は、共有データＤ３を読み込む呼出先プロセスであり、グループＧ３に属する。プロセスＰ２４は、プロセスＰ２３とのソケット通信を介して、共有データＤ３のＩＤ値を指定した読み込み命令を通知する。

プロセスＰ２２は、共有データＤ２へ書き出す呼出先プロセスであり、グループＧ２に属する。プロセスＰ２４は、プロセスＰ２２とのソケット通信を介して、共有データＤ２のＩＤ値を指定した書き込み命令を通知する。この書き込み命令には、プロセスＰ２４による計算結果である共有データＤ１，Ｄ３の和が書き込みデータとして指定される。

ここで、呼出元プロセスＰ２４をグループ外としてコアＣ４に配置することで、各呼出先プロセスＰ２１〜Ｐ２３の負荷を軽減できる。
一方、プロセスＰ２２とＰ２４とを統合し（つまり、呼出元プロセスと呼出先プロセスとを１つのプロセスで兼ねる）、グループＧ２に属するプロセスＰ２２が、共有データＤ１，Ｄ３の和を計算してもよい。これにより、分割された後のプロセスの数を４つから３つに減らすことで、プロセス管理の負担を軽減できる。

なお、各呼出先プロセスＰ２１〜Ｐ２３をミドルウェアとして事前に物理サーバ２に配備しておき、そのＡＰＩ（Application Programming Interface）を開発者に提供してもよい。これにより、アプリケーションの開発者はデータのロック、アンロックを意識しないで呼出元プロセスを作成すればよいので、開発コストが低減される。

図５（ａ）は、図３（ａ）の構成におけるグループ管理テーブル１５を示す構成図である。グループ管理テーブル１５は、グループごとに、そのグループが扱う共有データと、その共有データにアクセスするプロセスのＩＤと、そのプロセスが配置されるコアのＩＤとが対応づけられている。

図５（ｂ）は、図４の構成におけるグループ管理テーブル１５を示す構成図である。前記したように、図５（ａ）のプロセスＩＤ「Ｐ２」が、図５（ｂ）ではグループ内のプロセスＩＤ「Ｐ２１〜Ｐ２３」と、グループ外のプロセスＩＤ「Ｐ２４」とに分割されている。
以下、プロセス割当処理（Ｓ１４）によりグループ管理テーブル１５を作成する具体例について、第１の割当例（図６参照）、第２の割当例（図７参照）、第３の割当例（図８参照）を順に説明する。

図６（ａ）は、第１の割当例における割当前のグループ管理テーブル１５を示す構成図である。図５（ａ）と比較すると、まだ各プロセスがどのコアに割り当てられるかが決まっていないので、「コアＩＤ」列が存在しない（または空欄である）。

図６（ｂ）は、第１の割当例における割当後のグループ管理テーブル１５を示す構成図である。
プロセス割当部１３は、グループ管理テーブル１５のプロセスＩＤ列のプロセス数を計測し、その結果を最右列「プロセス数」へと書き出す。次に、プロセス割当部１３は、各コアで実行されるプロセス数が均等になるように、「コアＩＤ」列の割り当てを行う。例えば、図６（ｂ）では、以下のように４〜５つの間で均等化されている。
（コアＣ１の総プロセス数）＝２（Ｇ１）＋２（Ｇ４）＝４
（コアＣ２の総プロセス数）＝４（Ｇ２）
（コアＣ３の総プロセス数）＝３（Ｇ３）＋２（Ｇ５）＝５

図７（ａ）は、第２の割当例における割当前のグループ管理テーブル１５を示す構成図である。図７（ａ）のグループ管理テーブル１５は、図６（ａ）のものと同じデータである。

図７（ｂ）は、プロセス重みテーブル１６を示す構成図である。プロセス重みテーブル１６は、プロセスごとに、そのプロセスのコアで実行するときの負荷（ＣＰＵ利用率、メモリ利用率、共有データへのアクセス負荷など）を示す重みを特定するためのテーブルである。例えば、プロセスＰ１の重みは１５で、プロセスＰ２の重みは５なので、プロセスＰ１はプロセスＰ２のほぼ３倍の負荷をかけることがわかる。
なお、重みの決定方法は、例えば以下のいずれかの方法がある。
・負荷の重みは、設計者によって静的に決定される。
・負荷の重みは、プロセスをテストコードによって実行させた結果の「実行ステップ数」を用いる。
・負荷の重みは、所定期間におけるプロセスのＣＰＵ利用時間から決定され、動的に更新される。

図７（ｃ）は、第２の割当例における割当後のグループ管理テーブル１５を示す構成図である。
プロセス割当部１３は、グループ管理テーブル１５のプロセスＩＤ列の各プロセスについて、プロセス重みテーブル１６からその重みを特定し、その和を最右列「重みの和」へと書き出す。例えば、グループＧ１では、Ｐ１の重みが１５であり、Ｐ６の重みが２０であるので、その重みの和は３５＝１５＋２０である。 次に、プロセス割当部１３は、各コアで実行される重みの総和が均等になるように、「コアＩＤ」列の割り当てを行う。例えば、図７（ｂ）では、以下のように４０〜５０の間で均等化されている。
（コアＣ１の重みの総和）＝３５（Ｇ１）＋１５（Ｇ５）＝５０
（コアＣ２の重みの総和）＝２５（Ｇ２）＋１５（Ｇ４）＝４０
（コアＣ３の重みの総和）＝４５（Ｇ３）
そして、プロセス割当部１３は、例えばグループＩＤの小さい順に、そのグループに属する各プロセスを、前記均等化して決定した各コアに割り当てていく。

図８（ａ）は、第３の割当例における割当前のグループ管理テーブル１５を示す構成図である。図８（ａ）のグループ管理テーブル１５は、図６（ａ）のものと同じデータである。

図８（ｂ）は、ＶＭ管理テーブル１７を示す構成図である。ＶＭ管理テーブル１７は、各共有データについて、どのＶＭの管理下に置かれているかを示す第１テーブル１７ａと、各ＶＭについて、どのコアを収容するかを示す第２テーブル１７ｂとにより構成される。
例えば、共有データＤ１がＶＭ１の近くに配置されており（第１テーブル１７ａの１行目）、そのＶＭ１がコアＣ１を収容する（第２テーブル１７ｂの１行目）ので、共有データＤ１（を記憶する記憶手段）の配置場所に物理的に最も近いコア（つまり、通信遅延が最小であるなどのアクセスコストが最小のコア）が、コアＣ１であることがわかる。

図８（ｃ）は、第３の割当例における割当後のグループ管理テーブル１５を示す構成図である。
プロセス割当部１３は、図８（ｂ）で説明したように、各共有データの配置場所に対して物理的に最も近いコアを、グループ管理テーブル１５の「コアＩＤ」列へと書き出す。

図９（ａ）は、グループ化されたプロセスの移動処理（Ｓ１６）を示す構成図である。図３（ａ）の状態から、コアＣ２上のグループＧ２が削除され、コアＣ１上に優先プロセスの生起によりグループＧ１の実行が困難になったとする。
プロセス移動部１４は、グループＧ１単位で、コアＣ１からコアＣ２にプロセス群を移動する。つまり、グループＧ１に属するプロセスＰ１とＰ４とが、まとめてコアＣ２に移動する。これにより、共有データＤ１にアクセスするプロセスＰ１とＰ４との間でのアクセス競合を防止できる。
さらに、プロセス移動部１４は、共有データＤ１の配置が変更されるなどのシステム構成の変更に対して、グループごとにプロセスの移動先のコアを決定する。よって、システム構成の変更に対するインパクトを小さくすることができる。

図９（ｂ）は、比較例として、グループ化されていないプロセスの移動処理の問題点を示す構成図である。図９（ａ）との違いは、コアＣ１の混雑に伴い、そのコアＣ１上のプロセスＰ１はコアＣ２に退避するが、プロセスＰ４は退避しない点である。
これにより、図３（ｂ）と同じ状況（アクセス競合）が発生してしまう。さらに、共有データＤ１の配置の変更を行うときには、その共有データＤ１にアクセスするプロセスＰ１，Ｐ４が各コアに点在してしまっているので、それらを検索するなどのインパクトが大きくなってしまう。

以上説明した本実施形態のリソース割当システムは、実際のコア性能やメモリ量がＶＭによって隠蔽されることにより、システムの利用効率が低下してしまうような仮想化環境においては、計算機資源の効率的な利用という観点でとくに有効である。
一般的に、仮想化環境においては様々な共有データにアクセスするプロセスが様々なＶＭの様々なコアの上で並行に動作することになり、プロセス間の並列度は高まる。そのため、共有データに対する排他ロックやロック待ちが多発し、計算機資源の利用効率が悪い状態であった。

そこで、本実施形態のリソース割当装置１は、同じ共有データにアクセスするプロセスをグループ化し、そのグループ単位で同一コアに割り当てたり（Ｓ１４）、割り当てたグループを別コアへ移動したり（Ｓ１６）することによって、共有データに対するプロセス間のアクセス競合を回避させる。
これにより、同一コアに割り当てられたプロセス間での共有データへのアクセスと、コア資源の利用とを併せて実行しやすくなり、計算機資源の利用効率を高めることができる。さらに、アンロック漏れやデッドロックなど排他制御における不具合が生じた際に、不具合が発生した共有データにアクセスするプロセス群を特定するなどの障害解析が容易になる。

また、プロセス割当部１３は、グループ化したプロセス群を同一コアに配置するときに、図３（ａ）で説明したように、グループ内にキュー（待ち行列）を形成される。データへの同時アクセスがなくなり、データに対するロック処理が不要となる。そのため、データに対するロック待ちも発生しないことから、ハードウェアリソースの効率利用が可能となる。
さらに、プロセス割当部１３は、第１の割当例（図６参照）、第２の割当例（図７参照）、第３の割当例（図８参照）で説明したように、グループ間の負荷を分散（均一化）させるように、効率的なコアへの配置を行う。これにより、システム全体での負荷の偏りが低減されるので、システムの過剰な性能拡張を回避できる。

１ リソース割当装置
２ 物理サーバ
１１ 通信部
１２ プロセス分割部（分割手段）
１３ プロセス割当部（割当手段）
１４ プロセス移動部（移動手段）
１５ グループ管理テーブル
１６ プロセス重みテーブル
１７ ＶＭ管理テーブル

Claims (8)

1. １つの共有リソースを利用するプログラムの実行単位について、同じ共有リソースを利用する前記実行単位の集合をグループ化し、前記同じ共有リソースにアクセス可能な物理サーバ内の同じ演算手段上に、グループ化された前記実行単位の集合をまとめて割り当てる割当手段を有することを特徴とする
   リソース割当装置。
2. 複数の共有リソースを利用する前記実行単位の入力を受け付け、その共有リソースにアクセスするための、利用する共有リソースごとの呼出先の実行単位と、それらの呼出先の実行単位に対してアクセスの指示を呼び出すための呼出元の実行単位とに分割し、呼出先の実行単位をグループ化の対象とする分割手段を有することを特徴とする
   請求項１に記載のリソース割当装置。
3. 前記割当手段によって第１の演算手段上に割り当てられた前記実行単位を、第２の演算手段上に移動するとき、前記第１の演算手段上に割り当てられた同じグループに属する前記実行単位の集合をまとめて前記第２の演算手段上に移動する移動手段を有することを特徴とする
   請求項１に記載のリソース割当装置。
4. 前記割当手段は、割当候補である複数の演算手段について、各演算手段に割り当てられる実行単位の数が均等になるように、割当先の演算手段を選択することを特徴とする
   請求項１に記載のリソース割当装置。
5. 前記割当手段は、割当候補である複数の演算手段について、各演算手段に割り当てられる実行単位が発生される負荷が均等になるように、割当先の演算手段を選択することを特徴とする
   請求項１に記載のリソース割当装置。
6. 前記割当手段は、割当候補である複数の演算手段について、前記同じ共有リソースにアクセス可能な各演算手段のうちのアクセスコストが最小の演算手段を選択することを特徴とする
   請求項１に記載のリソース割当装置。
7. 請求項１ないし請求項６のいずれか１項に記載のリソース割当装置と、前記物理サーバとを含めて構成され、
   前記物理サーバの各演算手段は、自身に割り当てられたグループ化された前記実行単位の集合を実行するときに、ある実行単位の終了を待ってから別の実行単位を開始し、
   所定の実行単位の実行時間が所定時間を経過したときには、その所定の実行単位をタイムアウトさせることを特徴とする
   リソース割当システム。
8. リソース割当装置の割当手段は、１つの共有リソースを利用するプログラムの実行単位について、同じ共有リソースを利用する前記実行単位の集合をグループ化し、前記同じ共有リソースにアクセス可能な物理サーバ内の同じ演算手段上に、グループ化された前記実行単位の集合をまとめて割り当てることを特徴とする
   リソース割当方法。

Images