JP5466568B2 - 資源管理方法、資源管理プログラム、および、資源管理装置 - Google Patents
資源管理方法、資源管理プログラム、および、資源管理装置 Download PDFInfo
- Publication number
- JP5466568B2 JP5466568B2 JP2010100477A JP2010100477A JP5466568B2 JP 5466568 B2 JP5466568 B2 JP 5466568B2 JP 2010100477 A JP2010100477 A JP 2010100477A JP 2010100477 A JP2010100477 A JP 2010100477A JP 5466568 B2 JP5466568 B2 JP 5466568B2
- Authority
- JP
- Japan
- Prior art keywords
- unit
- physical
- memory
- application
- application unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Memory System (AREA)
- Stored Programmes (AREA)
Description
本発明は、資源管理方法、資源管理プログラム、および、資源管理装置の技術に関する。
非特許文献１には、１つの物理計算機を仮想的に分割して、複数の仮想計算機を構築する仮想計算機環境の技術が開示されている。
このような仮想計算機環境が構成される仮想計算機システムでは、メモリやディスク領域、あるいは、ＣＰＵやネットワーク装置などの物理資源が、それぞれの仮想計算機に割り当てられ、分割して管理されるため、物理計算機の物理資源の割り当てがアンバランスになってしまうことがある。
このような仮想計算機環境が構成される仮想計算機システムでは、メモリやディスク領域、あるいは、ＣＰＵやネットワーク装置などの物理資源が、それぞれの仮想計算機に割り当てられ、分割して管理されるため、物理計算機の物理資源の割り当てがアンバランスになってしまうことがある。
例えば、メモリ資源の場合を考えると、各仮想計算機上に空きメモリが分散され、メモリが余っている仮想計算機が存在する一方で、メモリが不足し、オペレーティングシステム（ＯＳ）のメモリ管理機構による、メモリページのハードディスクなどの補助記憶装置へのスワップアウトが頻発するという事態が生じる。
また、新たな仮想計算機の立ち上げなどに利用できる、仮想計算機に割り当てられていないメモリが不足するという状況が発生する可能性がある。
また、新たな仮想計算機の立ち上げなどに利用できる、仮想計算機に割り当てられていないメモリが不足するという状況が発生する可能性がある。
非特許文献１には、メモリのアンバランス問題を解決する手段の１つとしてバルーニング技術が開示されている。バルーニング技術では、仮想計算機上で動作するＯＳにデバイスドライバを配置し、仮想計算機環境からの指示によりデバイスドライバが、ＯＳに対してメモリ割当を要求し、デバイスドライバに割り当てられたメモリ領域を仮想計算機環境へ返却する。これにより返却された領域は、他の仮想計算機への割当が可能となる。
メモリを有効活用する技術は、仮想化環境に限らず重要であり、これまで数多く開示されている。
特許文献１には、ＯＳ上の複数のタスク間でメモリを有効活用する技術が開示されている。本技術は、２つのタスクで使用するメモリ領域を同一のメモリ領域にマッピングし、あるタスクではアドレスの上位から、別のタスクではアドレスの下位からメモリを割り当て、空きメモリが不足すると、一方のタスクへメモリ解放要求を出す。この技術では、一方のタスクのメモリ使用量が増えた場合に、他方のメモリ使用量が減少するという関係にある場合は有効である。
特許文献２には、ある処理プログラムＡにおいてメモリが不足した場合に、ある別の処理プログラムＢに対して空きメモリの解放を要求し、その空きメモリをシステムへ返却し、再度処理プログラムＡに対するメモリ割当要求を行うメモリ管理方法が開示されている。
特許文献１には、ＯＳ上の複数のタスク間でメモリを有効活用する技術が開示されている。本技術は、２つのタスクで使用するメモリ領域を同一のメモリ領域にマッピングし、あるタスクではアドレスの上位から、別のタスクではアドレスの下位からメモリを割り当て、空きメモリが不足すると、一方のタスクへメモリ解放要求を出す。この技術では、一方のタスクのメモリ使用量が増えた場合に、他方のメモリ使用量が減少するという関係にある場合は有効である。
特許文献２には、ある処理プログラムＡにおいてメモリが不足した場合に、ある別の処理プログラムＢに対して空きメモリの解放を要求し、その空きメモリをシステムへ返却し、再度処理プログラムＡに対するメモリ割当要求を行うメモリ管理方法が開示されている。
一方、ディスク資源の場合でも、各仮想化計算機上が使用する仮想ディスクに空き領域が分散され、ディスク容量に余裕のある仮想計算機が存在する一方で、ディスク領域が不足し、データの格納が行えなくなる仮想計算機が存在するという事態が生じる。
このような事態を解決するために、これまでに、例えば、ＶＭｗａｒｅ社の仮想化ソフトウェア「ＥＳＸｉ」においては、仮想計算機が使用する仮想ディスクの領域を拡張、あるいは、割り当てる物理ディスク容量を削減させる機能が提供されている。
また、ストレージ装置においても、必要に応じて仮想ディスクに物理ディスク領域を追加で割り当てる技術が広く使われている。また、一度割り当てた物理領域を開放し、仮想ディスクを縮小させるための技術が、特許文献３に開示されている。
また、同様の問題は、仮想計算機へのＣＰＵ資源の割当、および、ネットワーク資源の割当においても同様に発生する。
また、ストレージ装置においても、必要に応じて仮想ディスクに物理ディスク領域を追加で割り当てる技術が広く使われている。また、一度割り当てた物理領域を開放し、仮想ディスクを縮小させるための技術が、特許文献３に開示されている。
また、同様の問題は、仮想計算機へのＣＰＵ資源の割当、および、ネットワーク資源の割当においても同様に発生する。
Carl A. Waldspurger, Memory Resource Management in VMware ESX Server, OSDI 2002.
前記したように、複数の仮想計算機でそれぞれの物理資源の割り当てがアンバランスになってしまうと、物理資源の利用効率が悪化してしまい、仮想計算機システム全体の処理効率も悪化、あるいは、資源が不足した仮想計算機上のアプリケーションの実行が停止してしまう。
非特許文献１の技術は、メモリが不足した場合、各仮想計算機からメモリを解放する。そのため、メモリ不足の発生を待たねばならず、プログラムのメモリ不足に伴う処理効率の低下が発生してしまう。
また、非特許文献1の技術は、仮想計算機のＯＳ上で動作するアプリケーションが確保しているが、使用していないメモリを解放することができない。
特許文献１の技術は、一方のタスクのメモリ使用量が増えた場合に、他方のタスクのメモリ使用量が減少するという関係にない場合、同時に必要となるメモリが増加する可能性があり、その場合、メモリ不足を引き起こし易くなる。また、複数のタスクに対応できていない。
また、非特許文献1の技術は、仮想計算機のＯＳ上で動作するアプリケーションが確保しているが、使用していないメモリを解放することができない。
特許文献１の技術は、一方のタスクのメモリ使用量が増えた場合に、他方のタスクのメモリ使用量が減少するという関係にない場合、同時に必要となるメモリが増加する可能性があり、その場合、メモリ不足を引き起こし易くなる。また、複数のタスクに対応できていない。
特許文献２の技術では、メモリ不足が生じた場合のみ、別プログラムのメモリの解放を行う。そのため、別プログラムの負荷が高い場合にメモリ解放を行い、別プログラムの性能を低下させる可能性がある。
仮想計算機に割り当てる仮想ディスクの領域を拡張する場合においても、メモリ資源が不足した場合と同様の問題が起こる。すなわち、物理ディスク資源が不足した場合に、仮想計算機のＯＳ上で動作するアプリケーションが確保しているが、削除あるいは解放可能なディスク領域が存在している場合において、その領域は、管理しているアプリケーション以外からは存在を認識できないため、他の仮想計算機が使用する他の仮想ディスクの拡張に利用することができない。
そこで、本発明は、前記した問題を解決し、複数の仮想計算機を構築する仮想計算機システムにおいて、利用する物理資源の利用効率を高めることを、主な目的とする。
前記課題を解決するために、本発明は、１つ以上の仮想計算機と、その仮想計算機を動作させるためのハイパーバイザ部とを有して構成される仮想計算機環境を物理計算機上に構築するとともに、前記仮想計算機上のＯＳ上で動作するアプリケーション部が使用する計算機資源に対して、前記物理計算機の計算機資源を割り当てる資源管理方法であって、
前記仮想計算機が、割当処理部および前記アプリケーション部を動作させ、
前記アプリケーション部が、前記物理計算機の計算機資源を、前記アプリケーション部が使用する計算機資源として割り当てさせ、
前記割当処理部が、前記アプリケーション部が使用する計算機資源に対して、そのアプリケーション部に割り当て済みの計算機資源が少ないときに、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの計算機資源から、使用されていない計算機資源の解放指示を送信し、
前記アプリケーション部は、前記使用されていない計算機資源の解放指示を受信すると、前記アプリケーション部に割り当てられている計算機資源のうちの前記使用されていない計算機資源を解放するように、前記ハイパーバイザ部に指示することを特徴とする。
その他の手段は、後記する。
前記仮想計算機が、割当処理部および前記アプリケーション部を動作させ、
前記アプリケーション部が、前記物理計算機の計算機資源を、前記アプリケーション部が使用する計算機資源として割り当てさせ、
前記割当処理部が、前記アプリケーション部が使用する計算機資源に対して、そのアプリケーション部に割り当て済みの計算機資源が少ないときに、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの計算機資源から、使用されていない計算機資源の解放指示を送信し、
前記アプリケーション部は、前記使用されていない計算機資源の解放指示を受信すると、前記アプリケーション部に割り当てられている計算機資源のうちの前記使用されていない計算機資源を解放するように、前記ハイパーバイザ部に指示することを特徴とする。
その他の手段は、後記する。
本発明によれば、複数の仮想計算機を構築する仮想計算機システムにおいて、利用する物理資源の割当を仮想計算機システム上で実行するアプリケーションから制御することにより、物理資源の利用効率を高めることができる。
（第１実施形態、リソースとして、物理メモリを割り当てる）
以下、本発明の第１実施形態を、図面を参照して詳細に説明する。
以下、本発明の第１実施形態を、図面を参照して詳細に説明する。
図１は、仮想計算機環境８が構築される物理計算機９を示す構成図である。図１では、下位層から上位層にむかって接続する矢印を示すことにより、仮想計算機環境８のレイヤモデルを示している。例えば、物理計算機９からハイパーバイザ部８１に向かって矢印が記載されているが、この矢印は、下位層（物理計算機９）を利用して、上位層（ハイパーバイザ部８１）を構築する旨を示しており、ハイパーバイザ部８１は、実際には、物理計算機９の内部（主記憶装置９２）に存在する。
以下、物理計算機９上の仮想計算機環境８を示す階層モデルを説明する。最下位層（１）〜最上位層（５）の順に説明する。この階層モデルでは、（ｎ＋１）層は、（ｎ）層を利用して、その上に構築される。
階層（１）の物理層（物理計算機９の階層）は、最下位層である。この階層の物理計算機９は、ＣＰＵ９１と、主記憶装置９２と、入出力装置９３と、通信装置９４と、補助記憶装置９５と、がバス９６で接続されて構成されるコンピュータである。
階層（２）の仮想計算機環境８は、物理計算機９のＣＰＵ９１が、仮想計算機環境８を構成するためのプログラムを補助記憶装置９５から主記憶装置９２へと読み込んで、実行することにより構築される。仮想計算機環境８は、１台以上の仮想計算機８２を制御するハイパーバイザ部８１と、そのハイパーバイザ部８１から物理計算機９のリソース（主記憶装置９２の物理メモリなど）の割り当てを受けて、おのおの独立に仮想的な計算機として構築される仮想計算機８２と、により構成される。ハイパーバイザ部８１内の物理メモリ処理部３０は、物理計算機９のリソースにアクセスし、その割り当ておよび解放を実行する。
階層（３）のＯＳ８３は、仮想計算機８２上に構築される。つまり、仮想計算機８２ごとに同じまたは異なる種類のＯＳ８３を独立に起動することができる。ＯＳ８３上で起動する割当処理部１０は、自ら属する仮想計算機８２とは別の仮想計算機８２（同じ物理計算機９内の仮想計算機８２でもよいし、別の物理計算機９内の仮想計算機８２でもよい、また、仮想計算機でなくてもよい）上に構築されているＪａｖａ（登録商標）ＶＭ（Virtual Machine）８４（アプリケーション部２０）のリソース割り当てを制御する。
階層（４）のＪａｖａ ＶＭ８４は、ＯＳ８３上に構築されるＪａｖａ プログラムの実行環境である。なお、Ｊａｖａ ＶＭ８４の代わりに、メモリ管理機構を有する他の実行環境を採用してもよい。アプリケーション部２０は、自ら属するＪａｖａ ＶＭ８４が使用するリソースの割り当ておよび解放を制御する。なお、アプリケーション部２０が動作する仮想計算機８２の台数は、図１に示す１台に限定されず、同じ物理計算機９内に複数台存在していてもよい。
階層（５）のプログラム実行部８５は、Ｊａｖａ ＶＭ８４の実行環境（クラスライブラリなど）を用いて、Ｊａｖａ プログラムを実行する。
図２は、図１とは別の仮想計算機環境８が構築される物理計算機９を示す構成図である。図１では、割当処理部１０とアプリケーション部２０とが、別々の仮想計算機８２上に存在していたが、図２では、割当処理部１０とアプリケーション部２０とが、同じ仮想計算機８２上に存在している。つまり、割当処理部１０は、自ら属する仮想計算機８２上に構築されているＪａｖａ ＶＭ８４（アプリケーション部２０）のリソース割り当てを制御する。この図２の割当処理部１０は、Ｊａｖａ ＶＭ８４中の１つのスレッドとして動作し、所定間隔で実行される。
図３は、図１および図２で示した各処理部（割当処理部１０、アプリケーション部２０、物理メモリ処理部３０）の詳細を示す構成図である。
割当処理部１０は、割当制御部１１と、状況通知受信部１２と、処理状況管理テーブル１３と、メモリ割当管理テーブル１４と、を含めて構成される。
割当制御部１１は、処理状況管理テーブル１３およびメモリ割当管理テーブル１４にそれぞれ格納されているリソースの使用状況に応じて、リソースの割り当てをＪａｖａ ＶＭ８４に指示することで、リソースの使用を効率化する。
状況通知受信部１２は、Ｊａｖａ ＶＭ８４におけるリソース（ＣＰＵ９１、主記憶装置９２の物理メモリなど）の使用状況（使用量、使用率など）の通知を受ける。
処理状況管理テーブル１３には、状況通知受信部１２が動作状況通知部２１から受信した情報のうちの処理に関する情報（ＧＣ（Garbage Collection）処理中か否かなど）が格納される。
メモリ割当管理テーブル１４には、状況通知受信部１２が動作状況通知部２１および物理メモリ状況通知部３２から受信した情報（主記憶装置９２の物理メモリの使用状況）が格納される。
割当制御部１１は、処理状況管理テーブル１３およびメモリ割当管理テーブル１４にそれぞれ格納されているリソースの使用状況に応じて、リソースの割り当てをＪａｖａ ＶＭ８４に指示することで、リソースの使用を効率化する。
状況通知受信部１２は、Ｊａｖａ ＶＭ８４におけるリソース（ＣＰＵ９１、主記憶装置９２の物理メモリなど）の使用状況（使用量、使用率など）の通知を受ける。
処理状況管理テーブル１３には、状況通知受信部１２が動作状況通知部２１から受信した情報のうちの処理に関する情報（ＧＣ（Garbage Collection）処理中か否かなど）が格納される。
メモリ割当管理テーブル１４には、状況通知受信部１２が動作状況通知部２１および物理メモリ状況通知部３２から受信した情報（主記憶装置９２の物理メモリの使用状況）が格納される。
アプリケーション部２０は、動作状況通知部２１と、起動初期化部２２と、ＧＣ制御部２３と、メモリ領域２５と、を有する。
動作状況通知部２１は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、自らが所属するＪａｖａ ＶＭ８４の状態（メモリ領域２５の物理メモリの使用状況や、ＧＣ制御部２３によるＧＣ処理が実行中か否かという情報など）を、状況通知受信部１２に通知する。
起動初期化部２２は、Ｊａｖａ ＶＭ８４の起動時に、そのＪａｖａ ＶＭ８４（メモリ領域２５の割当も含む）の初期化処理を、ＯＳメモリ管理部２４に対して実行する。
動作状況通知部２１は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、自らが所属するＪａｖａ ＶＭ８４の状態（メモリ領域２５の物理メモリの使用状況や、ＧＣ制御部２３によるＧＣ処理が実行中か否かという情報など）を、状況通知受信部１２に通知する。
起動初期化部２２は、Ｊａｖａ ＶＭ８４の起動時に、そのＪａｖａ ＶＭ８４（メモリ領域２５の割当も含む）の初期化処理を、ＯＳメモリ管理部２４に対して実行する。
ＧＣ制御部２３は、メモリ領域２５内の未使用オブジェクトを解放するＧＣ処理の起動を制御する。ＧＣ処理は、例えば、mark and sweep方式のガベージコレクションアルゴリズムにより未使用メモリ領域を解放する。もちろん、mark and sweep方式に限定されず、プログラムの実行中に未使用領域を特定可能な任意のガベージコレクション方式をＧＣ処理として適用してもよい。ＧＣ処理の起動契機は、例えば、ＣＰＵ使用率が閾値以下、かつ、メモリの使用位置があらかじめ設定されている判定位置を超えたときである。
ＯＳメモリ管理部２４は、ＯＳ８３内に存在し、ハイパーバイザ部８１により割り当てられた主記憶装置９２の物理メモリを、ＯＳ８３上で動作するＪａｖａ ＶＭ８４などのプロセスへ割り当てる。しかし、ＯＳメモリ管理部２４は、起動初期化部２２の初期化処理において、起動初期化部２２からの指示により、Ｊａｖａ ＶＭ８４への物理メモリの管理処理（割り当て処理および解放処理、ハードディスク装置などへのスワップアウトなど）が停止される。その代わりに、Ｊａｖａ ＶＭ８４への物理メモリの管理処理は、割当処理部１０の割当制御部１１からの制御、および、Ｊａｖａ ＶＭ８４からの制御に従って、実行される。
メモリ領域２５は、プログラム実行部８５のプログラムにより使用されるメモリの領域であり、主記憶装置９２から物理メモリが割り当てられる。
メモリ領域２５は、プログラム実行部８５のプログラムにより使用されるメモリの領域であり、主記憶装置９２から物理メモリが割り当てられる。
物理メモリ処理部３０は、物理メモリ管理部３１と、物理メモリ状況通知部３２と、を備える。
物理メモリ管理部３１は、主記憶装置９２の物理メモリを所定サイズの領域（メモリページ）に分割して管理する。そして、物理メモリ管理部３１は、Ｊａｖａ ＶＭ８４からのメモリ割当要求に応じて割り当てるメモリページを提供するとともに、Ｊａｖａ ＶＭ８４からのメモリ解放要求に応じて指定されたメモリページを解放して、未割当状態に戻す。
物理メモリ状況通知部３２は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（主記憶装置９２の物理メモリの空き容量など）を、状況通知受信部１２に通知する。
物理メモリ管理部３１は、主記憶装置９２の物理メモリを所定サイズの領域（メモリページ）に分割して管理する。そして、物理メモリ管理部３１は、Ｊａｖａ ＶＭ８４からのメモリ割当要求に応じて割り当てるメモリページを提供するとともに、Ｊａｖａ ＶＭ８４からのメモリ解放要求に応じて指定されたメモリページを解放して、未割当状態に戻す。
物理メモリ状況通知部３２は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（主記憶装置９２の物理メモリの空き容量など）を、状況通知受信部１２に通知する。
図４は、メモリ領域２５内の物理メモリの状況を示す説明図である。各メモリ領域２５には、その領域の１つめの端点を示す最小位置（最下位アドレスの位置）と、その領域の２つめの端点を示す最大位置（最上位アドレスの位置）と、メモリ領域２５内の使用されている位置の内の最上位の位置を示す使用位置と、使用位置が判定位置を超過することによりＧＣ処理を起動させるための判定位置とが、それぞれメモリ領域内の位置を指し示すポインタとして設定されている。
つまり、メモリ領域２５は、最小位置から最大位置までの連続した領域として定義されている。そして、メモリ領域２５の使用位置は、最小位置（左端）から始まって、オブジェクトが割り当てられるたびに、そのオブジェクト分だけ最大位置（右端）に向かって、移動する。つまり、次に割り当てられるオブジェクトは、使用位置を始点とするメモリ領域に配置される。
図４（ａ）は、３つのアプリケーション（アプリＩＤ＝Ａ１，Ａ２，Ａ３）それぞれが使用する３つのメモリ領域２５を例示している。
アプリＩＤ＝Ａ１のメモリ領域２５には、６つのメモリページ（Ｐ１１〜Ｐ１６）のうち、２つのメモリページ（Ｐ１１，Ｐ１２）に対して物理メモリが割り当てられている（図中、「○」で表記）。
アプリＩＤ＝Ａ２のメモリ領域２５には、４つのメモリページ（Ｐ２１〜Ｐ２４）のうち、４つのメモリページ（Ｐ２１〜Ｐ２４）全てに対して物理メモリが割り当てられている。
アプリＩＤ＝Ａ３のメモリ領域２５には、４つのメモリページ（Ｐ３１〜Ｐ３４）のうち、２つのメモリページ（Ｐ３１，Ｐ３２）に対して物理メモリが割り当てられている。
アプリＩＤ＝Ａ１のメモリ領域２５には、６つのメモリページ（Ｐ１１〜Ｐ１６）のうち、２つのメモリページ（Ｐ１１，Ｐ１２）に対して物理メモリが割り当てられている（図中、「○」で表記）。
アプリＩＤ＝Ａ２のメモリ領域２５には、４つのメモリページ（Ｐ２１〜Ｐ２４）のうち、４つのメモリページ（Ｐ２１〜Ｐ２４）全てに対して物理メモリが割り当てられている。
アプリＩＤ＝Ａ３のメモリ領域２５には、４つのメモリページ（Ｐ３１〜Ｐ３４）のうち、２つのメモリページ（Ｐ３１，Ｐ３２）に対して物理メモリが割り当てられている。
そして、アプリＩＤ＝Ａ１のメモリ領域２５の使用位置が、物理メモリが割り当てられている最上位のページ（Ｐ１２）を超えるとすると、これ以上（Ｐ１３以降）は、物理メモリが割り当てられていない（「○」印が無い）ため、メモリが不足する。また、物理メモリ処理部３０が管理する物理メモリには、余裕のあるメモリページが存在しないとする。このとき、メモリページＰ１３に対して、新たに物理メモリを割り当てるためには、アプリＩＤ＝Ａ１以外のメモリ領域２５から、未使用の物理メモリを再割当する必要がある。
図４（ｂ）は、図４（ａ）の状態に対して、物理メモリの再割当を実行した後の物理メモリの状況を示す。
まず、アプリＩＤ＝Ａ２のメモリ領域２５において、使用位置がＰ２４まで来ているため、物理メモリが割り当てられている４つのメモリページ（Ｐ２１〜Ｐ２４）が、全て使用されている。よって、使用中の物理メモリを再割当の対象にはできないため、アプリＩＤ＝Ａ２のメモリ領域２５は、再割当の対象からは除外する。
まず、アプリＩＤ＝Ａ２のメモリ領域２５において、使用位置がＰ２４まで来ているため、物理メモリが割り当てられている４つのメモリページ（Ｐ２１〜Ｐ２４）が、全て使用されている。よって、使用中の物理メモリを再割当の対象にはできないため、アプリＩＤ＝Ａ２のメモリ領域２５は、再割当の対象からは除外する。
一方、アプリＩＤ＝Ａ３のメモリ領域２５において、物理メモリが割り当てられている２つのメモリページ（Ｐ３１，Ｐ３２）のうち、使用位置がＰ３１にとどまっているため、片方のメモリページ（Ｐ３１）だけが使用されている。つまり、もう片方のＰ３２は、物理メモリが割り当てられているものの、未使用のメモリページである。
そこで、メモリページＰ３２に割り当てられている物理メモリを、一旦返却し、そのメモリページを、アプリＩＤ＝Ａ１のメモリ領域２５内のメモリページＰ１３に再割当することで、メモリ不足を解消することができる。この再割当処理は、割当処理部１０の制御に従って、実行される。
そこで、メモリページＰ３２に割り当てられている物理メモリを、一旦返却し、そのメモリページを、アプリＩＤ＝Ａ１のメモリ領域２５内のメモリページＰ１３に再割当することで、メモリ不足を解消することができる。この再割当処理は、割当処理部１０の制御に従って、実行される。
以上、図４で説明したように、割当処理部１０が、割当済みであるが未使用の物理メモリを、物理メモリが不足しているアプリケーションへと融通することにより、メモリの使用効率を高めることができる。
ここで、アプリＩＤ＝Ａ１，Ａ２のアプリケーションが第１の仮想計算機８２上で動作し、アプリＩＤ＝Ａ３のアプリケーションが第２の仮想計算機８２上で動作しているとすると、仮想計算機８２をまたがったメモリの融通処理を実現することができる。このような、仮想計算機８２をまたがったリソース管理は、仮想計算機８２ごとに独立して起動しているＯＳ８３のＯＳメモリ管理部２４では、実現が困難である。
ここで、アプリＩＤ＝Ａ１，Ａ２のアプリケーションが第１の仮想計算機８２上で動作し、アプリＩＤ＝Ａ３のアプリケーションが第２の仮想計算機８２上で動作しているとすると、仮想計算機８２をまたがったメモリの融通処理を実現することができる。このような、仮想計算機８２をまたがったリソース管理は、仮想計算機８２ごとに独立して起動しているＯＳ８３のＯＳメモリ管理部２４では、実現が困難である。
図５は、処理状況管理テーブル１３およびメモリ割当管理テーブル１４を示す構成図である。なお、図５において、メモリ割当管理テーブル１４（再割当前）が図４（ａ）に対応し、メモリ割当管理テーブル１４（再割当後）が図４（ｂ）に対応する。
処理状況管理テーブル１３は、仮想計算機８２のＩＤであるアプリＩＤ１３１と、アプリＩＤ１４１が示すアプリケーションの名称であるアプリ名称１３２と、ＣＰＵ９１のＣＰＵ使用率１３３と、ＧＣ制御部２３がＧＣ処理を起動している（True）か否か（False）を示すＧＣ中フラグ１３４と、を対応づけて構成する。
メモリ割当管理テーブル１４は、アプリＩＤ１４１と、最小位置１４２と、判定位置１４３と、最大位置１４４と、使用位置１４５と、メモリ割当ページ１４６と、を対応づけて構成する。このメモリ割当管理テーブル１４に登録されている各レコードのアプリケーションが、状況通知受信部１２による状況通知の対象である。
アプリＩＤ１４１は、Ｊａｖａ ＶＭ８４などのアプリケーションのＩＤである。
アプリ名称１３２は、アプリＩＤ１４１が示すアプリケーションの名称である。
最小位置１４２、判定位置１４３、最大位置１４４、および、使用位置１４５は、図４で説明したように、アプリケーションが使用するメモリ領域２５内の各位置を示すポインタである。
メモリ割当ページ１４６は、図４の「○」印で説明したように、メモリ領域２５内で物理メモリが割り当てられているメモリページを示す。
アプリＩＤ１４１は、Ｊａｖａ ＶＭ８４などのアプリケーションのＩＤである。
アプリ名称１３２は、アプリＩＤ１４１が示すアプリケーションの名称である。
最小位置１４２、判定位置１４３、最大位置１４４、および、使用位置１４５は、図４で説明したように、アプリケーションが使用するメモリ領域２５内の各位置を示すポインタである。
メモリ割当ページ１４６は、図４の「○」印で説明したように、メモリ領域２５内で物理メモリが割り当てられているメモリページを示す。
図６は、図１の物理計算機９の動作を示すフローチャートである。
このフローチャートの開始状態として、１つのハイパーバイザ部８１と、１つ以上の仮想計算機８２とからなる仮想計算機環境８が、物理計算機９に構築され、そのハイパーバイザ部８１内で物理メモリ処理部３０が動作し、その仮想計算機８２上で割当処理部１０が動作しているものとする。さらに、各仮想計算機８２上には、ＯＳ８３（ＯＳメモリ管理部２４を含む）が起動している。
このフローチャートの開始状態として、１つのハイパーバイザ部８１と、１つ以上の仮想計算機８２とからなる仮想計算機環境８が、物理計算機９に構築され、そのハイパーバイザ部８１内で物理メモリ処理部３０が動作し、その仮想計算機８２上で割当処理部１０が動作しているものとする。さらに、各仮想計算機８２上には、ＯＳ８３（ＯＳメモリ管理部２４を含む）が起動している。
Ｓ１０１として、起動初期化部２２は、割当制御部１１からの起動要求により、仮想計算機８２上でＪａｖａ ＶＭ８４およびアプリケーション部２０の起動および初期化処理を実行する（後記する図７のサブルーチンを呼び出す）。なお、起動要求において指定されるオプションは、起動されるアプリケーション部２０内のメモリ領域２５の各位置（最小位置１４２、判定位置１４３、最大位置１４４）である。
Ｓ１０２として、起動初期化部２２は、割当処理部１０の割当制御部１１に対して初期化処理の結果を通知する。割当制御部１１は、通知された結果を、メモリ割当管理テーブル１４に登録する。
Ｓ１０２として、起動初期化部２２は、割当処理部１０の割当制御部１１に対して初期化処理の結果を通知する。割当制御部１１は、通知された結果を、メモリ割当管理テーブル１４に登録する。
Ｓ１０３〜Ｓ１０５は、メモリ割当処理である。
Ｓ１０３として、Ｊａｖａ ＶＭ８４は、プログラム実行部８５が実行するプログラムのオブジェクト配置処理に応じて、物理メモリが割り当てられていないメモリページが必要になると、メモリ領域２５へのメモリ割当要求を生成し、物理メモリ処理部３０に対してそのメモリ割当要求を送信する（後記する図８（ａ）のサブルーチンを呼び出す）。
Ｓ１０４として、物理メモリ管理部３１は、要求を受け、未使用の物理メモリを検索して割り当てる（例えば、図４（ｂ）のＰ１３）。割当可能な領域がない場合には、割り当てられない旨のメッセージをアプリケーション部２０に返答する。
Ｓ１０５として、Ｊａｖａ ＶＭ８４は、Ｓ１０４の返答により、物理メモリの割り当て処理が成功したときには、Ｓ１０３の配置対象のオブジェクトを使用位置１４５に配置するとともに、使用位置１４５を配置された領域の次の位置に更新する。
Ｓ１０３として、Ｊａｖａ ＶＭ８４は、プログラム実行部８５が実行するプログラムのオブジェクト配置処理に応じて、物理メモリが割り当てられていないメモリページが必要になると、メモリ領域２５へのメモリ割当要求を生成し、物理メモリ処理部３０に対してそのメモリ割当要求を送信する（後記する図８（ａ）のサブルーチンを呼び出す）。
Ｓ１０４として、物理メモリ管理部３１は、要求を受け、未使用の物理メモリを検索して割り当てる（例えば、図４（ｂ）のＰ１３）。割当可能な領域がない場合には、割り当てられない旨のメッセージをアプリケーション部２０に返答する。
Ｓ１０５として、Ｊａｖａ ＶＭ８４は、Ｓ１０４の返答により、物理メモリの割り当て処理が成功したときには、Ｓ１０３の配置対象のオブジェクトを使用位置１４５に配置するとともに、使用位置１４５を配置された領域の次の位置に更新する。
Ｓ１１１〜Ｓ１１３は、メモリ解放処理である。
Ｓ１１１として、割当処理部１０の状況通知受信部１２は、所定間隔で、動作状況通知部２１からの通知内容（状況通知）を処理状況管理テーブル１３およびメモリ割当管理テーブル１４に登録し、物理メモリ状況通知部３２からの通知内容（状況通知）をメモリ割当管理テーブル１４に登録する。
Ｓ１１２として、割当制御部１１は、処理状況管理テーブル１３およびメモリ割当管理テーブル１４の登録内容をもとに、メモリ割当管理テーブル１４に登録されている各アプリケーションのアプリケーション部２０に対して、メモリ解放要求を送信する。
このように、割当処理部１０の側から能動的にメモリの解放要求を送信することによって、アプリケーションのメモリが不足する前に、予防的にメモリをアプリケーション間で融通することができるので、アプリケーションのメモリ不足に伴う性能低下を事前に回避することができる。
Ｓ１１３として、各アプリケーション部２０は、メモリ解放要求を受け、収容するメモリ領域２５に割り当てられている物理メモリを解放することで、利用可能な物理メモリの容量を増やす（後記する図９のサブルーチンを呼び出す）。
Ｓ１１１として、割当処理部１０の状況通知受信部１２は、所定間隔で、動作状況通知部２１からの通知内容（状況通知）を処理状況管理テーブル１３およびメモリ割当管理テーブル１４に登録し、物理メモリ状況通知部３２からの通知内容（状況通知）をメモリ割当管理テーブル１４に登録する。
Ｓ１１２として、割当制御部１１は、処理状況管理テーブル１３およびメモリ割当管理テーブル１４の登録内容をもとに、メモリ割当管理テーブル１４に登録されている各アプリケーションのアプリケーション部２０に対して、メモリ解放要求を送信する。
このように、割当処理部１０の側から能動的にメモリの解放要求を送信することによって、アプリケーションのメモリが不足する前に、予防的にメモリをアプリケーション間で融通することができるので、アプリケーションのメモリ不足に伴う性能低下を事前に回避することができる。
Ｓ１１３として、各アプリケーション部２０は、メモリ解放要求を受け、収容するメモリ領域２５に割り当てられている物理メモリを解放することで、利用可能な物理メモリの容量を増やす（後記する図９のサブルーチンを呼び出す）。
以上説明したメモリ割当処理（Ｓ１０３〜Ｓ１０５）と、割当済のメモリを解放する処理（Ｓ１１１〜Ｓ１１３）とは、互いに並行処理することとしてもよい。この２つの処理を繰り返すことにより、限られた計算機リソースである物理メモリが、必要なときに必要なアプリケーションへと配分されることで、物理メモリのリソースが複数の仮想計算機８２にまたがって循環し、メモリの利用効率を向上させ続けることが可能となる。さらに、割当済のメモリの解放処理が、アプリケーションのメモリ不足時より前に随時実施されることにより、アプリケーションのメモリ不足の発生を事前に抑制でき、アプリケーションの性能劣化を防止することができる。
図７は、起動初期化部２２が実行する、メモリ領域２５の初期化処理（Ｓ１０１）を示すフローチャートである。
Ｓ２０１として、最小位置１４２から最大位置１４４までの領域について、物理メモリの割り当てをＯＳメモリ管理部２４に要求する。ＯＳメモリ管理部２４は、要求を受け、最小位置１４２から最大位置１４４までの領域について、物理メモリを割り当てる。
Ｓ２０２として、最小位置１４２から最大位置１４４までの領域の各メモリページについて、そのメモリページに対してＳ２０１で割り当てた物理メモリの各メモリページに対するＯＳ８３やそのＯＳ８３上の各プロセスからのアクセスを禁止する旨のアクセス権設定処理をＯＳメモリ管理部２４に、また、割り当てられた物理メモリの解放を物理メモリ管理部３１に対して要求する。ＯＳメモリ管理部２４は、要求を受け、指定されたメモリページに対して、ＯＳ８３のシステムコールを呼び出すことで、物理メモリに対するアクセス権を禁止に設定する。
このＳ２０２の処理により、メモリ領域２５の各メモリページは、領域が割当されているが物理メモリが割りあたっていない状態となり、ＯＳメモリ管理部２４の管理対象外となる。
このＳ２０２の処理により、メモリ領域２５の各メモリページは、領域が割当されているが物理メモリが割りあたっていない状態となり、ＯＳメモリ管理部２４の管理対象外となる。
Ｓ２０３として、使用位置１４５の初期値に、最小位置１４２を設定する。
図８は、アプリケーション部２０のメモリ領域２５へのアクセス処理の詳細を説明するフローチャートである。
図８（ａ）は、アプリケーション部２０が実行する、メモリ領域２５上のオブジェクト配置処理を示すフローチャートである。このフローチャートは、配置対象のオブジェクトを指定して実行される。
図８（ａ）は、アプリケーション部２０が実行する、メモリ領域２５上のオブジェクト配置処理を示すフローチャートである。このフローチャートは、配置対象のオブジェクトを指定して実行される。
Ｓ３０１として、配置対象のオブジェクトをメモリ領域２５の使用位置１４５に配置できるか否かを判定する。具体的には、使用位置１４５から配置対象のオブジェクト分の領域に、未使用の物理メモリが割り当てられているときには、配置可能と判定する。例えば、図４（ａ）の使用位置１４５がＰ１３に達していると、未使用の物理メモリが割り当てられていない（「○」印がない）ため、配置できないと判定する。Ｓ３０１でＹｅｓなら本フローチャートから呼び出し元へと戻り、ＮｏならＳ３０２へ進む。
Ｓ３０２として、使用位置１４５が最大位置１４４に到達しているか否かを判定する。Ｓ３０２でＹｅｓならＳ３０４へ進み、ＮｏならＳ３０３へ進む。
Ｓ３０３として、物理メモリ管理部３１に対して、空き物理メモリが存在しているか否かを問い合わせ、その結果、ＧＣ処理により、空き物理メモリを増やすか否かを判定する。Ｓ３０３でＹｅｓならＳ３０５へ進み、ＮｏならＳ３０４へ進む。
Ｓ３０４として、ＧＣ制御部２３が実行するメモリ領域２５のＧＣ処理（図８（ｂ））を呼び出す。
Ｓ３０３として、物理メモリ管理部３１に対して、空き物理メモリが存在しているか否かを問い合わせ、その結果、ＧＣ処理により、空き物理メモリを増やすか否かを判定する。Ｓ３０３でＹｅｓならＳ３０５へ進み、ＮｏならＳ３０４へ進む。
Ｓ３０４として、ＧＣ制御部２３が実行するメモリ領域２５のＧＣ処理（図８（ｂ））を呼び出す。
Ｓ３０５として、使用位置１４５の次のメモリページ（例えば、図４（ａ）のＰ１３）に、物理メモリの割り当てをする旨の割り当て要求を、物理メモリ管理部３１に送信する。
図８（ｂ）は、ＧＣ制御部２３が実行する、メモリ領域２５に対するＧＣ処理を示すフローチャートである。このフローチャートは、ＧＣ制御部２３が起動しているＪａｖａ ＶＭ８４のアプリＩＤ１４１を指定して、実行される。
Ｓ３１１として、ＧＣ処理を実行するか否かを判定する。例えば、指定されたアプリＩＤ１４１に対応する使用位置１４５が、判定位置１４３を超過していないときには（例えば、図４（ａ）のＰ１２）、メモリ領域２５がまだあまり使用されていないため、ＧＣ処理により新たなメモリ領域を確保することがあまり期待できず、ＧＣ処理を実行しないと判定する。Ｓ３１１でＹｅｓならＳ３１２へ進み、Ｎｏなら本フローチャートの呼び出し元へと戻る。
Ｓ３１２において、指定されたアプリＩＤ１４１一致する処理状況管理テーブル１３のアプリＩＤ１３１を含むレコードについて、そのレコードのＧＣ中フラグ１３４を「True」に設定する。
Ｓ３１２において、指定されたアプリＩＤ１４１一致する処理状況管理テーブル１３のアプリＩＤ１３１を含むレコードについて、そのレコードのＧＣ中フラグ１３４を「True」に設定する。
Ｓ３１３において、メモリ領域２５内の最小位置１４２から使用位置１４５までの領域を対象として、ＧＣ処理を実行して、ＧＣ境界位置を求める。このＧＣ処理により、最小位置１４２から使用位置１４５までの領域のうちの未使用な領域（不要なオブジェクトの配置領域など）が細切れになっているときには、使用領域（必要なオブジェクトの配置領域など）を最小位置１４２から詰めて移動することにより、一続きの未使用領域を確保することができる。
ＧＣ処理によって、最小位置１４２から使用位置１４５までの領域が、使用領域と、未使用領域とに分けられる。そして、この両領域の境界位置を、ＧＣ境界位置とする。
ＧＣ処理によって、最小位置１４２から使用位置１４５までの領域が、使用領域と、未使用領域とに分けられる。そして、この両領域の境界位置を、ＧＣ境界位置とする。
Ｓ３１４において、メモリ領域２５内のＧＣ境界位置から使用位置１４５までに割り当てられている物理メモリの解放処理を実行する。そのため、ＧＣ制御部２３は、物理メモリ管理部３１に対して、物理メモリの解放要求を送信すると、物理メモリ管理部３１は、その要求で指定された領域のメモリページに割り当てられている物理メモリを解放する。
なお、Ｓ３１４の処理で、ＧＣ境界位置から使用位置１４５までの領域のすべての物理メモリを解放する代わりに、所定量の物理メモリを解放せずに確保しておき、その残りの物理メモリを解放することとしてもよい。これにより、Ｊａｖａ ＶＭ８４間で共有できるメモリ量を制限することができる。
さらに、Ｓ３１４の処理を省略することとしてもよい。これにより、Ｊａｖａ ＶＭ８４内には、物理メモリが割り当てられているメモリページが残ったままの状態となる。
このように、Ｊａｖａ ＶＭ８４内に未使用のメモリページを残しておくことで、メモリ不足によるメモリの割当回数を少なくすることができるので、メモリの割当処理にかかるオーバーヘッドを抑制することができる。この未使用のメモリページは、後記する図９のＳ４０５の処理で適宜解放されるため、メモリの利用効率を低下させる要因とはならない。
さらに、Ｓ３１４の処理を省略することとしてもよい。これにより、Ｊａｖａ ＶＭ８４内には、物理メモリが割り当てられているメモリページが残ったままの状態となる。
このように、Ｊａｖａ ＶＭ８４内に未使用のメモリページを残しておくことで、メモリ不足によるメモリの割当回数を少なくすることができるので、メモリの割当処理にかかるオーバーヘッドを抑制することができる。この未使用のメモリページは、後記する図９のＳ４０５の処理で適宜解放されるため、メモリの利用効率を低下させる要因とはならない。
Ｓ３１５において、指定されたアプリＩＤ１４１に対応する使用位置１４５に、ＧＣ境界位置を代入することで、使用位置１４５を更新する。
Ｓ３１６において、Ｓ３１２でＧＣ中フラグ１３４を「True」に設定したレコードについて、ＧＣ中フラグ１３４を「False」に戻す。
Ｓ３１６において、Ｓ３１２でＧＣ中フラグ１３４を「True」に設定したレコードについて、ＧＣ中フラグ１３４を「False」に戻す。
図９は、割当制御部１１が実行する、能動的なメモリの解放要求処理の詳細を示すフローチャートである。
Ｓ４０１において、選択中ＶＭとして、メモリ割当管理テーブル１４に登録されているＪａｖａ ＶＭ８４を１つずつ選択するループを開始する。
Ｓ４０２において、物理メモリ管理部３１が管理する未割当の物理メモリが充分に存在するか否かを判定する。Ｓ４０２でＹｅｓなら終了し、ＮｏならＳ４０３へ進む。
Ｓ４０３において、選択中ＶＭの負荷が大きいか否かを判定する。具体的には、処理状況管理テーブル１３の選択中ＶＭに対応するＣＰＵ使用率１３３が所定閾値（例えば、７０％）以上であるときに、負荷が大きいと判定する。選択中ＶＭの負荷が大きいときには、優先度の低いメモリの解放処理の実行を行わないことで、選択中ＶＭの処理を妨げないようにする。Ｓ４０３でＹｅｓならＳ４０８へ進み、ＮｏならＳ４０４へ進む。
なお、選択中ＶＭの負荷評価値について、ＣＰＵ使用率１３３の代わりに、Ｊａｖａ ＶＭ８４上で動作しているアプリケーションがアプリケーションサーバの場合は、処理中のリクエスト数など、負荷を評価するための任意の指標を用いてもよい。
Ｓ４０２において、物理メモリ管理部３１が管理する未割当の物理メモリが充分に存在するか否かを判定する。Ｓ４０２でＹｅｓなら終了し、ＮｏならＳ４０３へ進む。
Ｓ４０３において、選択中ＶＭの負荷が大きいか否かを判定する。具体的には、処理状況管理テーブル１３の選択中ＶＭに対応するＣＰＵ使用率１３３が所定閾値（例えば、７０％）以上であるときに、負荷が大きいと判定する。選択中ＶＭの負荷が大きいときには、優先度の低いメモリの解放処理の実行を行わないことで、選択中ＶＭの処理を妨げないようにする。Ｓ４０３でＹｅｓならＳ４０８へ進み、ＮｏならＳ４０４へ進む。
なお、選択中ＶＭの負荷評価値について、ＣＰＵ使用率１３３の代わりに、Ｊａｖａ ＶＭ８４上で動作しているアプリケーションがアプリケーションサーバの場合は、処理中のリクエスト数など、負荷を評価するための任意の指標を用いてもよい。
Ｓ４０４において、選択中ＶＭ内のメモリ領域２５において、未使用領域が充分存在するか否かを判定する。ここで、未使用領域とは、使用位置１４５の次の位置から最大位置１４４までの領域の内の物理メモリが割当済みの領域を指す（例えば、図４（ａ）のＰ３２）。Ｓ４０４でＹｅｓならＳ４０５へ進み、ＮｏならＳ４０６へ進む。
Ｓ４０５において、選択中ＶＭ内の未使用領域を戻す。そして、Ｓ４０８に進む。
Ｓ４０５において、選択中ＶＭ内の未使用領域を戻す。そして、Ｓ４０８に進む。
Ｓ４０６において、選択中ＶＭで、既にＧＣが実行中か否かを判定する。具体的には、処理状況管理テーブル１３の選択中ＶＭに対応するＧＣ中フラグ１３４が「True」であるときに、ＧＣが実行中であると判定する。そして、ＧＣが実行中であるときには、重複してＧＣ処理を実行しないように、ＧＣ処理を実行しないと判定する。Ｓ４０６でＹｅｓならＳ４０８へ進み、ＮｏならＳ４０７へ進む。
Ｓ４０７において、図８（ｂ）のサブルーチンを呼び出すことで、選択中ＶＭ内でＧＣを実行し、未使用領域を解放する。
Ｓ４０８において、Ｓ４０１からの選択中ＶＭのループを終了する。
Ｓ４０７において、図８（ｂ）のサブルーチンを呼び出すことで、選択中ＶＭ内でＧＣを実行し、未使用領域を解放する。
Ｓ４０８において、Ｓ４０１からの選択中ＶＭのループを終了する。
以上説明した第１実施形態によれば、割当処理部１０は、メモリ領域２５のうち、主記憶装置９２の物理メモリが割り当てられているにもかかわらず、未使用の領域（または、ＧＣ処理を起動することで新たに割当できた領域）を物理メモリ管理部３１に返却するように能動的に制御することで、物理メモリ管理部３１が割り当て可能な物理メモリの容量を増やすことができる。
そして、物理メモリ管理部３１は、空き物理メモリを他のＪａｖａ ＶＭ８４に再割当することで、メモリの有効利用が可能となる。つまり、ある分割されたメモリ領域に含まれる空きメモリを別のメモリ領域を管理するシステムへ融通することで、メモリを有効活用できる。
さらに、ＧＣ処理を起動する契機を、そのＪａｖａ ＶＭ８４の負荷が低いときとする（Ｓ４０３）ことにより、ＧＣによる停止時間の影響を少なく抑えることが可能となる。つまり、空きメモリの解放をプログラムの負荷状況に応じて制御することが可能となる。
（第２実施形態、リソースとして、物理ディスクを割り当てる）
以下、本発明の第２実施形態を、図面を参照して詳細に説明する。
以下、本発明の第２実施形態を、図面を参照して詳細に説明する。
図１０は、仮想計算機環境８が構築される物理計算機９を示す構成図である。図１０では、図１および図２と同様に、下位層から上位層にむかって接続する矢印を示すことにより、仮想計算機環境８のレイヤモデルを示している。
以下、第２実施形態の構成（図１０）と、第１実施形態の構成（図１、図２）との違いについて説明する。
階層（１）の物理層（物理計算機９の階層）は、補助記憶装置９５のひとつとしてディスク装置９７を含めて構成される。
階層（２）の仮想計算機環境８を構成するハイパーバイザ部８１は、物理ディスク処理部４０を含めて構成される。物理ディスク処理部４０は、物理計算機９のディスク装置９７を制御することにより、ディスク資源を管理し、仮想計算機８２が使用する仮想ディスク１６（図１１で後記）に対するディスク容量の割り当ておよび解放を実行する。
階層（１）の物理層（物理計算機９の階層）は、補助記憶装置９５のひとつとしてディスク装置９７を含めて構成される。
階層（２）の仮想計算機環境８を構成するハイパーバイザ部８１は、物理ディスク処理部４０を含めて構成される。物理ディスク処理部４０は、物理計算機９のディスク装置９７を制御することにより、ディスク資源を管理し、仮想計算機８２が使用する仮想ディスク１６（図１１で後記）に対するディスク容量の割り当ておよび解放を実行する。
階層（４）のＤＢＭＳ８６（Data Base Managment System）は、アプリケーション部２０、および、割当処理部１０を含めて構成される。アプリケーション部２０は、ＤＢＭＳ８６が使用するリソースの割り当ておよび解放を制御する。なお、ＤＢＭＳ８６が動作する仮想計算機８２の台数は、同じ物理計算機９内に複数台存在するものとする。
図１１は、図１０で示した各処理部（割当処理部１０、アプリケーション部２０、物理ディスク処理部４０）の詳細を示す構成図である。
割当処理部１０は、割当制御部１１と、状況通知受信部１２と、処理状況管理テーブル１３と、ディスク領域管理テーブル１５と、を含めて構成される。
割当制御部１１は、処理状況管理テーブル１３およびディスク領域管理テーブル１５にそれぞれ格納されているリソースの使用状況に応じて、リソースの割り当てをＤＢＭＳ８６に指示することで、リソースの使用を効率化する。
状況通知受信部１２は、ＤＢＭＳ８６におけるリソース（ＣＰＵ９１、データ領域２９、データ領域２９を格納する仮想ディスク１６など）の使用状況（使用量、使用率など）の通知を受ける。
処理状況管理テーブル１３には、状況通知受信部１２が動作状況通知部２１から受信した情報のうちの処理に関する情報（再編処理中か否かなど）が格納される。
ディスク領域管理テーブル１５には、状況通知受信部１２が動作状況通知部２１および物理ディスク状況通知部４２から受信した情報（補助記憶装置９５の物理ディスクの使用状況）が格納される。
割当制御部１１は、処理状況管理テーブル１３およびディスク領域管理テーブル１５にそれぞれ格納されているリソースの使用状況に応じて、リソースの割り当てをＤＢＭＳ８６に指示することで、リソースの使用を効率化する。
状況通知受信部１２は、ＤＢＭＳ８６におけるリソース（ＣＰＵ９１、データ領域２９、データ領域２９を格納する仮想ディスク１６など）の使用状況（使用量、使用率など）の通知を受ける。
処理状況管理テーブル１３には、状況通知受信部１２が動作状況通知部２１から受信した情報のうちの処理に関する情報（再編処理中か否かなど）が格納される。
ディスク領域管理テーブル１５には、状況通知受信部１２が動作状況通知部２１および物理ディスク状況通知部４２から受信した情報（補助記憶装置９５の物理ディスクの使用状況）が格納される。
アプリケーション部２０は、問合せ部２６と、アクセス処理部２７と、動作状況通知部２１と、起動初期化部２２と、再編成制御部２８と、仮想ディスク１６（データ領域２９）と、を有する。
動作状況通知部２１は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、ＤＢＭＳ８６の状態（仮想ディスク１６内のデータ領域２９の使用状況や、再編成制御部２８による再編成処理が実行中か否かという情報など）を、状況通知受信部１２に通知する。
問合せ部２６は、ＤＢＭＳ８６へのリクエスト（検索要求などの問い合わせ）を処理する。
アクセス処理部２７は、問合せ部２６の要請を受けて、データ領域２９へのデータの格納、もしくは、データ領域２９中のデータを読み出す。
動作状況通知部２１は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、ＤＢＭＳ８６の状態（仮想ディスク１６内のデータ領域２９の使用状況や、再編成制御部２８による再編成処理が実行中か否かという情報など）を、状況通知受信部１２に通知する。
問合せ部２６は、ＤＢＭＳ８６へのリクエスト（検索要求などの問い合わせ）を処理する。
アクセス処理部２７は、問合せ部２６の要請を受けて、データ領域２９へのデータの格納、もしくは、データ領域２９中のデータを読み出す。
起動初期化部２２は、ＤＢＭＳ８６の起動時に、そのＤＢＭＳ８６が使用するデータ領域２９の使用状況などを他のＤＢＭＳ８６へ通知し、また、他のＤＢＭＳ８６から通知を受ける。
データ領域２９は、ＤＢＭＳ８６により管理されるデータベースのデータを格納する領域であり、物理ディスク処理部４０により、ディスク装置９７から領域が割り当てられた仮想ディスク１６上に格納される。また、このデータ領域２９は、ある決まった大きさの領域（ページ）の集まりとして管理される。
データ領域２９は、ＤＢＭＳ８６により管理されるデータベースのデータを格納する領域であり、物理ディスク処理部４０により、ディスク装置９７から領域が割り当てられた仮想ディスク１６上に格納される。また、このデータ領域２９は、ある決まった大きさの領域（ページ）の集まりとして管理される。
アクセス処理部２７は、ページにデータが格納できなくなった場合に、新たなページを確保する（つまり、データ領域２９の容量を拡大する）。また、アクセス処理部２７は、データ領域に格納されているデータが消去される場合に、他の格納されているデータの移動は行わない。そのため、データ領域２９中には、ディスク領域が確保されているが、使用されていない領域（未回収領域）が散在するようになる。
再編成制御部２８は、ＤＢＭＳ８６で管理するデータ領域２９の未回収領域などを回収する再編成処理を実施する。
再編成制御部２８は、ＤＢＭＳ８６で管理するデータ領域２９の未回収領域などを回収する再編成処理を実施する。
物理ディスク処理部４０は、物理ディスク管理部４１と、物理ディスク状況通知部４２と、を備える。
物理ディスク管理部４１は、ディスク装置９７のディスク領域から所定サイズの領域を仮想計算機８２が認識するディスク領域として割り当てる。また、物理ディスク管理部４１は、ＤＢＭＳ８６などからの要求に応じて、要求に応じて割り当てるディスク領域の容量を拡張、あるいは、削減する。
物理ディスク状況通知部４２は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（ディスク装置９７の物理ディスクの空き容量など）を、状況通知受信部１２に通知する。
物理ディスク管理部４１は、ディスク装置９７のディスク領域から所定サイズの領域を仮想計算機８２が認識するディスク領域として割り当てる。また、物理ディスク管理部４１は、ＤＢＭＳ８６などからの要求に応じて、要求に応じて割り当てるディスク領域の容量を拡張、あるいは、削減する。
物理ディスク状況通知部４２は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（ディスク装置９７の物理ディスクの空き容量など）を、状況通知受信部１２に通知する。
図１２は、図１１で示した処理状況管理テーブル１３およびディスク領域管理テーブル１５を示す構成図である。
処理状況管理テーブル１３は、仮想計算機８２のＩＤであるＤＢＭＳＩＤ１４７と、ＣＰＵ９１のＣＰＵ使用率１３３と、再編成制御部２８が再編成処理を起動している（True）か否か（False）を示す再編成中フラグ１４８と、を対応づけて構成する。
ディスク領域管理テーブル１５は、ＤＢＭＳＩＤ１４７と、データ領域２９の現在容量１４９と、データ領域２９を格納する仮想ディスク１６空き容量１５０と、を対応づけて構成する。このディスク領域管理テーブル１５に登録されているＤＢＭＳＩＤ１４７のＤＢＭＳ８６が、状況通知受信部１２による状況通知の対象である。
再割当前のディスク領域管理テーブル１５では、３つのＤＢＭＳ８６（ＤＢＭＳＩＤ＝Ａ１，Ａ２，Ａ３）のそれぞれが使用する３つのデータ領域２９と仮想ディスク１６に対する割当状況が保持されている。今、ＤＢＭＩＤ＝Ａ１のＤＢＭＳ８６に対して、データの格納処理が発生した場合、Ａ１のディスク容量不足が発生する。また、物理ディスク処理部４０が管理するディスク装置９７にも空き容量がないとする。このため、ＤＢＭＳＩＤ＝Ａ１のＤＢＭＳ８６に対してディスク容量を割り当てるには、他のＤＢＭＳ８６（Ａ２，Ａ３）の容量を再割当する必要がある。
再割当後のディスク領域管理テーブル１５では、再割当前のディスク領域管理テーブル１５の状況に対して、再割当処理を実行した後のデータ領域２９の容量を示している。まず、ＤＢＭＳＩＤ１４７＝Ａ２のＤＢＭＳ８６は、充分の空き容量がない、つまり、最大容量に対する一定の割合を超えている（ここでは、９０％を想定）ため、再割当の対象から除外する。
次に、ＤＢＭＳＩＤ１４７＝Ａ３のＤＢＭＳ８６は、空き容量が充分に存在する。そのため、このデータ領域２９の容量を一定の量（ここでは５ＧＢ）削減することで、一旦ディスク装置９７へ返却し、その容量分だけ、ＤＢＭＳＩＤ＝Ａ１のデータ領域２９を拡張することにより、ディスク容量不足を解消することができる。この再割当処理は、割当処理部１０の制御にしたがって、実行される。
図１３は、図１０の物理計算機９の動作を示すフローチャートである。
このフローチャートの開始状態として、１つのハイパーバイザ部８１と、１つ以上の仮想計算機８２とからなる仮想計算機環境８が、物理計算機９に構築され、そのハイパーバイザ部８１内で物理ディスク処理部４０が動作し、その仮想計算機８２上でＤＢＭＳ８６（ＤＢ１）が起動しているとする。また、ＤＢＭＳ８６が使用するデータ領域２９はあらかじめ構築されているものとする。さらに、各仮想計算機８２上には、ＯＳ８３が起動している。
このフローチャートの開始状態として、１つのハイパーバイザ部８１と、１つ以上の仮想計算機８２とからなる仮想計算機環境８が、物理計算機９に構築され、そのハイパーバイザ部８１内で物理ディスク処理部４０が動作し、その仮想計算機８２上でＤＢＭＳ８６（ＤＢ１）が起動しているとする。また、ＤＢＭＳ８６が使用するデータ領域２９はあらかじめ構築されているものとする。さらに、各仮想計算機８２上には、ＯＳ８３が起動している。
新たにＤＢＭＳ８６（ＤＢ２）が起動されると、Ｓ５０１として、起動初期化部２２が初期化処理を実行する（後記する図１４のサブルーチンを呼び出す）。
Ｓ５０２およびＳ５０３として、各ＤＢＭＳ８６の割当処理部１０の状況通知受信部１２は、所定間隔で、同一の物理計算機９上の仮想計算機８２上で動作する各ＤＢＭＳ８６の動作状況通知部２１からの通知内容（状況通知）を処理状況管理テーブル１３およびディスク領域管理テーブル１５に登録し、物理ディスク状況通知部４２からの通知内容（状況通知）をディスク領域管理テーブル１５に登録する。
Ｓ５０２およびＳ５０３として、各ＤＢＭＳ８６の割当処理部１０の状況通知受信部１２は、所定間隔で、同一の物理計算機９上の仮想計算機８２上で動作する各ＤＢＭＳ８６の動作状況通知部２１からの通知内容（状況通知）を処理状況管理テーブル１３およびディスク領域管理テーブル１５に登録し、物理ディスク状況通知部４２からの通知内容（状況通知）をディスク領域管理テーブル１５に登録する。
Ｓ５１１〜Ｓ５１３は、ディスク領域の削減処理である。
Ｓ５１１として、割当制御部１１は、自ら属するＤＢＭＳ８６が管理するデータ領域２９を格納する仮想ディスク１６の空き容量がない、あるいは、不足していると判定される場合や、ディスク装置９７の空き容量が少ないと判定される場合は、処理状況管理テーブル１３およびディスク領域管理テーブル１５の登録内容をもとに、ディスク領域管理テーブル１５に登録されている各ＤＢＭＳ８６のアプリケーション部２０に対して、ディスク領域削減要求を送信する。
Ｓ５１１として、割当制御部１１は、自ら属するＤＢＭＳ８６が管理するデータ領域２９を格納する仮想ディスク１６の空き容量がない、あるいは、不足していると判定される場合や、ディスク装置９７の空き容量が少ないと判定される場合は、処理状況管理テーブル１３およびディスク領域管理テーブル１５の登録内容をもとに、ディスク領域管理テーブル１５に登録されている各ＤＢＭＳ８６のアプリケーション部２０に対して、ディスク領域削減要求を送信する。
このように、割当処理部１０の側から能動的にディスク領域の削減要求を送信することによって、ＤＢＭＳ８６のディスク容量が不足する前に、予防的にディスクをＤＢＭＳ８６間で融通することができるので、ＤＢＭＳ８６のディスク容量不足に伴う性能低下、あるいは、ＤＢＭＳ８６の停止を事前に回避することができる。
Ｓ５１２として、各アプリケーション部２０は、ディスク領域解放要求を受け、可能なら、データ領域２９の容量を削減したのち（Ｓ５１３）、仮想ディスク１６の容量を削減することにより、利用可能な物理ディスクの容量を増やす（後記する図１６のサブルーチンを呼び出す）。
Ｓ５１２として、各アプリケーション部２０は、ディスク領域解放要求を受け、可能なら、データ領域２９の容量を削減したのち（Ｓ５１３）、仮想ディスク１６の容量を削減することにより、利用可能な物理ディスクの容量を増やす（後記する図１６のサブルーチンを呼び出す）。
Ｓ５２１〜Ｓ５２３は、ディスク領域の割当処理である。
Ｓ５２１として、ＤＢＭＳ８６は、問合せ部２６が受けた要求によって、アクセス処理部２７がデータを格納するためのデータ領域２９の容量が不足すると（つまり、仮想ディスク１６の空き容量が不足すると）、仮想ディスク１６へのディスク領域割当要求を生成し、物理ディスク処理部４０に対して、仮想ディスク１６に対する領域拡張要求を送信する。（後記する図１５のサブルーチンを呼び出す）。
Ｓ５２２として、物理ディスク管理部４１は、要求を受け、ディスク装置９７の未使用領域を用いて、指定された仮想ディスク１６を指定された容量だけ拡張する。ディスク装置９７に、拡張に利用できる領域がない場合には、拡張できない旨のメッセージをアプリケーション部２０に返答する。
Ｓ５２３として、ＤＢＭＳ８６は、Ｓ５２２の返答により、仮想ディスク１６の拡張処理が成功したときには、データ領域２９に対して、データの格納を実施する。
Ｓ５２１として、ＤＢＭＳ８６は、問合せ部２６が受けた要求によって、アクセス処理部２７がデータを格納するためのデータ領域２９の容量が不足すると（つまり、仮想ディスク１６の空き容量が不足すると）、仮想ディスク１６へのディスク領域割当要求を生成し、物理ディスク処理部４０に対して、仮想ディスク１６に対する領域拡張要求を送信する。（後記する図１５のサブルーチンを呼び出す）。
Ｓ５２２として、物理ディスク管理部４１は、要求を受け、ディスク装置９７の未使用領域を用いて、指定された仮想ディスク１６を指定された容量だけ拡張する。ディスク装置９７に、拡張に利用できる領域がない場合には、拡張できない旨のメッセージをアプリケーション部２０に返答する。
Ｓ５２３として、ＤＢＭＳ８６は、Ｓ５２２の返答により、仮想ディスク１６の拡張処理が成功したときには、データ領域２９に対して、データの格納を実施する。
以上説明したディスク領域の割当処理（Ｓ５２１〜Ｓ５２３）と、ディスク領域の削減処理（Ｓ５１１〜Ｓ５１３）とは、互いに並行処理することとしてもよい。この２つの処理を繰り返すことにより、物理ディスクが、必要なときに必要なＤＢＭＳ８６へと配分されることで、物理ディスクのリソースが複数の仮想計算機８２にまたがって循環し、物理ディスクの利用効率を向上させ続けることが可能となる。さらに、ディスク領域の削減処理が、ＤＢＭＳ８６のデータ領域２９の容量の不足時より前に随時実施されることにより、ＤＢＭＳ８６のディスク不足の発生を事前に抑制でき、ＤＢＭＳ８６の性能劣化を防止することができる。
図１４は、図１１で示した起動初期化部２２が実行する、初期化処理（Ｓ５０１）を示すフローチャートである。
Ｓ６０１として、本初期化処理を実行中のＤＢＭＳ８６と同一の物理計算機９上に構築される仮想計算機８２を、ハイパーバイザ部８１から取得し、取得した各仮想計算機上で稼動しているＤＢＭＳ８６に対して、本初期化処理を実行中のＤＢＭＳ８６のＤＢＭＳＩＤ１４７、データ領域２９の現在の容量、データ領域２９を格納する仮想ディスク１６の空き容量を通知し、通知された各ＤＢＭＳ８６は、各ＤＢＭＳ８６が保持する処理状況管理テーブル１３、ディスク領域管理テーブル１５に通知された値を登録する。
Ｓ６０２として、Ｓ６０１において、初期化処理実行中のＤＢＭＳ８６から状況通知を受け取ったＤＢＭＳ８６は、自身のＤＢＭＳＩＤ１４７、現在容量１４９、空き容量１５０を、初期化処理起動中のＤＢＭＳ８６に対して送信し、初期化処理を実行中のＤＢＭＳ８６では、受け取った値を、自身の処理状況管理テーブル１３、ディスク領域管理テーブル１５へ格納する。
Ｓ６０２として、Ｓ６０１において、初期化処理実行中のＤＢＭＳ８６から状況通知を受け取ったＤＢＭＳ８６は、自身のＤＢＭＳＩＤ１４７、現在容量１４９、空き容量１５０を、初期化処理起動中のＤＢＭＳ８６に対して送信し、初期化処理を実行中のＤＢＭＳ８６では、受け取った値を、自身の処理状況管理テーブル１３、ディスク領域管理テーブル１５へ格納する。
図１５は、図１１で示したアプリケーション部２０が実行する、データ領域２９上へのデータの配置処理を示すフローチャートである。このフローチャートは、格納対象のデータを指定して実行される。
Ｓ７０１として、格納対象のデータをデータ領域２９へ格納できるか否かを判定する。具体的には、データ領域２９中にデータを格納する空き領域があるか、もしない場合は、データ領域２９を格納する仮想ディスク１６の空き容量が、データ領域２９の管理単位であるページを新たに確保するために十分かを判定する。Ｓ７０１でＹｅｓなら本フローチャートから呼び出し元へと戻り、ＮｏならＳ７０２へ進む。
Ｓ７０２として、物理ディスク管理部４１に対して、ディスク装置９７に空き領域が存在しているか否かを問い合わせ、その結果、再編成処理により、空き容量を増やすか否かを判定する。Ｓ７０２でＹｅｓならＳ７０３へ進み、ＮｏならＳ７０４へ進む。
Ｓ７０３として、物理ディスク管理部４１に対して、データ領域２９を格納する仮想ディスク１６の拡張を要求したのち、ＯＳ８３に対して拡張された領域をファイルシステムが管理する領域として認識するように要求する。
Ｓ７０３として、物理ディスク管理部４１に対して、データ領域２９を格納する仮想ディスク１６の拡張を要求したのち、ＯＳ８３に対して拡張された領域をファイルシステムが管理する領域として認識するように要求する。
Ｓ７０４として、再編成制御部２８が実行する再編成処理（図１５（ｂ））を実行する。
なお、図１５（ａ）のフローチャートでは、データ領域２９へデータを格納する時点において、データ領域２９を格納する仮想ディスク１６の拡張を判定し、必要なら、仮想ディスク１６の拡張を実施しているが、データの格納とは異なる時点において、仮想ディスク１６の拡張を実施してもよい。これにより、データ領域２９へデータを格納する時点でのオーバーヘッドを削減することができる。
図１５（ｂ）は、再編成制御部２８が実行する、データ領域２９に対する再編成処理を示すフローチャートである。このフローチャートはＤＢＭＳ８６のＤＢＭＳＩＤ１４７を指定して呼び出される。
なお、図１５（ａ）のフローチャートでは、データ領域２９へデータを格納する時点において、データ領域２９を格納する仮想ディスク１６の拡張を判定し、必要なら、仮想ディスク１６の拡張を実施しているが、データの格納とは異なる時点において、仮想ディスク１６の拡張を実施してもよい。これにより、データ領域２９へデータを格納する時点でのオーバーヘッドを削減することができる。
図１５（ｂ）は、再編成制御部２８が実行する、データ領域２９に対する再編成処理を示すフローチャートである。このフローチャートはＤＢＭＳ８６のＤＢＭＳＩＤ１４７を指定して呼び出される。
Ｓ７１１として、再編成処理を実行するか否かを判定する。例えば、データ領域２９の現在容量１４９が一定サイズより小さい場合は、再編成処理により新たな領域の確保があまり期待できないため、処理を実行しないと判断する。Ｓ７１１でＹｅｓならＳ７１２へ進み、Ｎｏなら本フローチャートの呼び出し元へと戻る。
Ｓ７１２において、指定されたＤＢＭＳＩＤ１４７に一致する処理状況管理テーブル１３のＤＢＭＳＩＤ１４７を含むレコードについて、そのレコードの再編成中フラグ１４８を「True」に設定する。
Ｓ７１２において、指定されたＤＢＭＳＩＤ１４７に一致する処理状況管理テーブル１３のＤＢＭＳＩＤ１４７を含むレコードについて、そのレコードの再編成中フラグ１４８を「True」に設定する。
Ｓ７１３において、データ領域２９に対して再編成処理を適用する。この再編成処理により、データ領域２９内でのデータの配置が細切れになっているときには、データの格納領域を移動させることにより、未使用領域を確保することができる。
Ｓ７１４において、与えられたＤＢＭＳＩＤ１４７に対応するディスク領域管理テーブル１５のレコードに格納される現在容量１４９を更新する。
Ｓ７１５において、Ｓ７１２で再編集中フラグ１４８を「True」に設定したレコードについて、再編成中フラグ１４８を「False」に戻す。
Ｓ７１５において、Ｓ７１２で再編集中フラグ１４８を「True」に設定したレコードについて、再編成中フラグ１４８を「False」に戻す。
なお、図１５に示したフローチャットにおけるＳ７１３の処理で、データ領域２９の再編成処理の代わりに、もしくは、再編処理と同時に、ＤＢＭＳ８６が管理しているファイルのうち、ＤＢＭＳ８６が削除可能と判定できるものは削除することもできる。例えば、ログファイルはファイルサイズもしくは、日付などのデータを元に、新しい物を一定サイズだけ残して残りを削除することができる。
図１６は、図１１で示した割当制御部１１が実行する、能動的なディスク領域の削除要求処理の詳細を示すフローチャートである。
Ｓ８０１において、選択中ＤＢＭＳとして、ディスク領域管理テーブル１５に登録されているＤＢＭＳ８６を１つずつ選択するループを開始する。
Ｓ８０２において、物理ディスク管理部４１が管理するディスク装置９７に未割当の領域が充分に存在するか否かを判定する。Ｓ８０２でＹｅｓなら終了し、ＮｏならＳ８０３へ進む。
Ｓ８０２において、物理ディスク管理部４１が管理するディスク装置９７に未割当の領域が充分に存在するか否かを判定する。Ｓ８０２でＹｅｓなら終了し、ＮｏならＳ８０３へ進む。
Ｓ８０３において、選択中ＤＢＭＳの負荷が大きいか否かを判定する。具体的には、処理状況管理テーブル１３の選択中ＤＢＭＳに対応するＣＰＵ使用率１３３が所定閾値（例えば、７０％）以上であるときに、負荷が大きいと判定する。選択中ＤＢＭＳの負荷が大きいときには、対象外とすることにより、選択中ＤＢＭＳの処理を妨げないようにする。Ｓ８０３でＹｅｓならＳ８０８へ進み、ＮｏならＳ８０４へ進む。
なお、選択中ＶＭの負荷評価値について、ＣＰＵ使用率１３３の代わりに、ＤＢＭＳ８６に対するリクエスト数（検索要求数）など、負荷を評価するための任意の指標を用いてもよい。
なお、選択中ＶＭの負荷評価値について、ＣＰＵ使用率１３３の代わりに、ＤＢＭＳ８６に対するリクエスト数（検索要求数）など、負荷を評価するための任意の指標を用いてもよい。
Ｓ８０４において、選択中ＤＢＭＳ内のデータ領域２９を格納する仮想ディスク１６において、領域の空きが充分存在するか否かを判定する。Ｓ８０４でＹｅｓならＳ８０７へ進み、ＮｏならＳ８０５へ進む。
Ｓ８０５において、選択中ＤＢＭＳで、既に再編成処理が実行中か否かを判定する。具体的には、処理状況管理テーブル１３の選択中ＤＢＭＳに対応する再編成中フラグ１４８が「True」であるときに、再編成処理が実行中であると判定する。そして、再編成処理が実行中であるときには、重複して再編成処理を実行しないように、再編成処理を実行しないと判定する。Ｓ８０５でＹｅｓならＳ８０８へ進み、ＮｏならＳ８０６へ進む。
Ｓ８０６において、図１５（ｂ）の処理を呼び出すことにより、選択中ＤＢＭＳで再編成処理を実行する。
Ｓ８０７において、選択ＤＢＭＳのデータ領域２９を格納する仮想ディスク１６の容量を削減する要求を物理ディスク管理部４１へ送信する。より、具体的には、ディスク装置９７へ返却可能な仮想ディスク１６のセクタに対して印を付け、物理ディスク管理部４１では、印のあるセクタに対する物理ディスク領域の割当を解除する。
Ｓ８０８において、Ｓ８０１からの選択中ＤＢＭＳのループを終了する。
Ｓ８０７において、選択ＤＢＭＳのデータ領域２９を格納する仮想ディスク１６の容量を削減する要求を物理ディスク管理部４１へ送信する。より、具体的には、ディスク装置９７へ返却可能な仮想ディスク１６のセクタに対して印を付け、物理ディスク管理部４１では、印のあるセクタに対する物理ディスク領域の割当を解除する。
Ｓ８０８において、Ｓ８０１からの選択中ＤＢＭＳのループを終了する。
以上説明した第２実施形態によれば、割当処理部１０は、ディスク装置９７のうち、ＤＢＭＳ８６のデータ領域２９を格納する仮想ディスク１６へ割当てているが使用されていない領域、または、再編成処理などを起動することで新たに確保できた領域を物理ディスク管理部４１に返却するように能動的に制御することで、物理ディスク管理部４１が割り当て可能なディスク装置の容量を増やすことができる。
そして、物理ディスク管理部４１は、空き領域を他のＤＢＭＳ８６がデータ領域２９を格納している仮想ディスクへ再割当することで、ディスクの有効利用が可能となる。つまり、ある分割されたディスク領域に含まれる空き領域を、仮想計算機８２上で動作するアプリケーションであるＤＢＭＳ８６からディスク資源の割当を制御することにより、別のディスク資源を管理するシステムへ融通することで、ディスク資源を有効活用できる。
（第３実施形態、リソースとして、ＣＰＵ資源、ネットワーク資源を割り当てる）
以下、本発明の第３実施形態として、ＣＰＵ資源、ネットワーク資源を管理する場合を説明する。これらの資源の管理の場合も、第１実施形態に示したメモリ資源の管理、および、第２実施形態に示したディスク資源の管理と同様に行うことができる。
以下、本発明の第３実施形態として、ＣＰＵ資源、ネットワーク資源を管理する場合を説明する。これらの資源の管理の場合も、第１実施形態に示したメモリ資源の管理、および、第２実施形態に示したディスク資源の管理と同様に行うことができる。
第３実施形態においては、第１実施形態および第２実施形態で示した図１、図１０などのレイヤモデルで示される構成上で実施される。ハイパーバイザ部８１では、物理ＣＰＵ処理部４３、および、物理ネットワーク処理部４６を含む。
物理ＣＰＵ処理部４３は、物理計算機９のＣＰＵ９１を制御することにより、ＣＰＵ資源を管理し、仮想計算機８２が使用する仮想ＣＰＵに対する資源の割当、および、解放を実行する。
物理ネットワーク処理部４６は、物理計算機９の通信装置９４を制御することにより、ネットワーク資源を管理し、仮想計算機８２が使用する仮想ネットワークに対する資源の割当、および、解放を実行する。
物理ＣＰＵ処理部４３は、物理計算機９のＣＰＵ９１を制御することにより、ＣＰＵ資源を管理し、仮想計算機８２が使用する仮想ＣＰＵに対する資源の割当、および、解放を実行する。
物理ネットワーク処理部４６は、物理計算機９の通信装置９４を制御することにより、ネットワーク資源を管理し、仮想計算機８２が使用する仮想ネットワークに対する資源の割当、および、解放を実行する。
図１７は、第３実施形態における各処理部（アプリケーション部２０と、割当処理部１０、物理ＣＰＵ処理部４３、および、物理ネットワーク処理部４６）の詳細を示す構成図である。
割当処理部１０は、資源管理用のテーブルとして、ＣＰＵ資源の割当量を管理するＣＰＵ管理テーブル１７、および、ネットワーク資源の割当量を管理するネットワーク管理テーブル１８を含む。なお、資源管理用のテーブルとして、第１実施形態ではメモリ割当管理テーブル１４を有し、あるいは、第２実施形態ではディスク領域管理テーブル１５を有することは、既に説明した。
物理ＣＰＵ処理部４３は、物理ＣＰＵ管理部４４、物理ＣＰＵ状況通知部４５と、を備える。
物理ＣＰＵ管理部４４は、ＣＰＵ９１から所定のプロセッサ資源を仮想計算機８２が認識する仮想ＣＰＵとして割り当てる。また、物理ＣＰＵ管理部４４は、アプリケーションからの要求に応じて、割り当てるプロセッサ資源の追加、あるいは、削減する。なお、ここでは、ＣＰＵ資源の割当管理の単位をプロセッサのコア数として管理するが、使用率の割合など別の指標を用いてもよい。
物理ＣＰＵ状況通知部４５は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（ＣＰＵ９１の使用状況など）を、状況通知受信部１２に通知する。
物理ＣＰＵ管理部４４は、ＣＰＵ９１から所定のプロセッサ資源を仮想計算機８２が認識する仮想ＣＰＵとして割り当てる。また、物理ＣＰＵ管理部４４は、アプリケーションからの要求に応じて、割り当てるプロセッサ資源の追加、あるいは、削減する。なお、ここでは、ＣＰＵ資源の割当管理の単位をプロセッサのコア数として管理するが、使用率の割合など別の指標を用いてもよい。
物理ＣＰＵ状況通知部４５は、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（ＣＰＵ９１の使用状況など）を、状況通知受信部１２に通知する。
物理ネットワーク処理部４６は、物理ネットワーク管理部４７と、物理ネットワーク状況通知部４８を備える。
物理ネットワーク管理部４７は、通信装置９４から所定のネットワーク資源を仮想計算機８２が認識する仮想ネットワークとして割り当てる。また、物理ネットワーク管理部４７は、アプリケーションからの要求に応じて、割り当てるネットワーク資源を追加、あるいは、削減する。なお、ここでは、ネットワーク資源の割当管理の単位をネットワークカードの数として管理するが、ネットワークの使用帯域など別の指標を用いてもよい。
物理ネットワーク状況通知部４８は、物理ネットワーク管理部４７、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（通信装置９４の使用状況など）を、状況通知受信部１２に通知する。
物理ネットワーク管理部４７は、通信装置９４から所定のネットワーク資源を仮想計算機８２が認識する仮想ネットワークとして割り当てる。また、物理ネットワーク管理部４７は、アプリケーションからの要求に応じて、割り当てるネットワーク資源を追加、あるいは、削減する。なお、ここでは、ネットワーク資源の割当管理の単位をネットワークカードの数として管理するが、ネットワークの使用帯域など別の指標を用いてもよい。
物理ネットワーク状況通知部４８は、物理ネットワーク管理部４７、状況通知受信部１２からの要求に応じて、または、要求が無くても能動的に、物理計算機９の状態（通信装置９４の使用状況など）を、状況通知受信部１２に通知する。
図１８は、図１７で示したＣＰＵ管理テーブル１７の詳細を示す構成図である。
ＣＰＵ管理テーブル１７は、実行中のアプリケーションを識別するためのアプリＩＤ１５１と、そのアプリＩＤで示されるアプリケーションが使用中のプロセッサ数である使用数１５２、アプリＩＤで示されるアプリケーションに割当済みのプロセッサ数である割当済数１５３を含む。
ＣＰＵ管理テーブル１７は、実行中のアプリケーションを識別するためのアプリＩＤ１５１と、そのアプリＩＤで示されるアプリケーションが使用中のプロセッサ数である使用数１５２、アプリＩＤで示されるアプリケーションに割当済みのプロセッサ数である割当済数１５３を含む。
図１９は、図１７で示したネットワーク管理テーブル１８の詳細を示す構成図である。
ネットワーク管理テーブル１８は、実行中のアプリケーションを識別するためのアプリＩＤ１５４と、そのアプリＩＤで示されるアプリケーションが使用中のネットワーク装置数である使用数１５５、アプリＩＤで示されるアプリケーションに割当済みのネットワーク装置数である割当済数１５６を含む。
ネットワーク管理テーブル１８は、実行中のアプリケーションを識別するためのアプリＩＤ１５４と、そのアプリＩＤで示されるアプリケーションが使用中のネットワーク装置数である使用数１５５、アプリＩＤで示されるアプリケーションに割当済みのネットワーク装置数である割当済数１５６を含む。
また、アプリケーションは、使用する資源量に応じて、ＣＰＵ管理テーブル１７の使用数１５２、および、ネットワーク管理テーブル１８の使用数１５５を更新する。例えば、マルチスレッドのアプリケーションにおいて、実行するスレッドに対して１つのプロセッサ、および、１つのネットワーク装置を割り当てる場合、アプリケーションが実行するスレッドの数が使用量となる。
以上の構成による物理計算機９上のアプリケーション部２０と割当処理部１０を含むアプリケーションにおける資源の割当処理、および、資源の解放処理について説明する。
資源の解放処理おいては、あるアプリケーションが使用する資源が不足する場合、もしくは、物理計算機９上の空き資源が不足する場合において、同一の物理計算機９上で動作する別のアプリケーションに対して空き資源の解放要求を通知する。
アプリケーションが使用する資源の不足は、ＣＰＵ管理テーブル１７の使用数１５２が割当済数１５３に対する所定の割合を上回る場合に不足すると判定できる。同様に、ネットワーク資源においては、ネットワーク管理テーブル１８の使用数１５５が割当済数１５６に対する所定の割合を上回る場合に不足すると判定できる。
資源の解放共有を受けたアプリケーションでは、通知を受けた資源の種別に応じて、ＣＰＵ管理テーブル１７、もしくは、ネットワーク管理テーブル１８を参照し、割当済みであるが、未使用である資源（例えば、ＣＰＵ資源の場合、割当済数１５３から使用数１５２を引いた数）のうち、所定の個数のプロセッサ、もしくは、ネットワーク装置の割当の解除要求を、物理ＣＰＵ管理部４４、もしくは、物理ネットワーク管理部４７に対して、送信することにより、アプリケーションが動作している仮想計算機８２から解除し、ハイパーバイザ部８１が管理する未使用の資源とする。
次に、資源の割当処理では、アプリケーションで新たな資源の確保が必要になった場合に、資源種別に応じて、物理ＣＰＵ管理部４４、もしくは、物理ネットワーク管理部４７に対して必要な資源の割当を要求し、アプリケーションが稼動する仮想計算機８２に対して必要となる資源の追加を行う。なお、資源の割当処理においては、物理ＣＰＵ管理部４４もしくは、物理ネットワーク管理部４７からの資源の割当に失敗した場合、つまり、物理計算機９に空き資源がない場合は、その場で、他のアプリケーションに対して、資源の解放要求を送信してもよい。
以上説明した第３実施形態によれば、割当処理部１０は、仮想計算機８２に割り当てられているが使用されていないＣＰＵ資源の仮想計算機８２への割当を解除するように能動的に制御することで、物理ＣＰＵ処理部４３が割り当て可能なＣＰＵ資源の容量を増やすことができる。
そして、物理ＣＰＵ管理部４４は、空き領域を他のアプリケーションが実行されている仮想計算機８２へ再割当することで、ＣＰＵ資源の有効利用が可能となる。つまり、ある分割されているＣＰＵ資源の空き容量を、仮想計算機８２上で動作するアプリケーションからＣＰＵ資源の割当を制御することにより、別のＣＰＵ資源を管理するシステムへ融通することで、ＣＰＵ資源を有効活用できる。また、ネットワーク資源に対しても同様の方式により、有効活用することができる。
以上説明した第１実施形態〜第３実施形態では、それぞれ割当制御部１１が計算機資源（リソース）の使用状況に応じて、リソースの割り当てを制御することで、リソースの使用を効率化することを特徴とする。
例えば、割当制御部１１は、未割当のリソース（プールされているリソース）が少ないときに、使用されていないリソースの解放指示を各アプリケーション部２０に送信する。
または、割当制御部１１は、アプリケーション部２０が使用するリソースに対して、そのアプリケーション部２０に割り当て済みのリソースが少ないときに（換言すると、リソース不足のアプリケーション部２０が存在するときに）、使用されていないリソースの解放指示を各アプリケーション部２０に送信する。
例えば、割当制御部１１は、未割当のリソース（プールされているリソース）が少ないときに、使用されていないリソースの解放指示を各アプリケーション部２０に送信する。
または、割当制御部１１は、アプリケーション部２０が使用するリソースに対して、そのアプリケーション部２０に割り当て済みのリソースが少ないときに（換言すると、リソース不足のアプリケーション部２０が存在するときに）、使用されていないリソースの解放指示を各アプリケーション部２０に送信する。
８ 仮想計算機環境
９ 物理計算機（資源管理装置）
１０ 割当処理部
１１ 割当制御部
１２ 状況通知受信部
１３ 処理状況管理テーブル
１４ メモリ割当管理テーブル
１５ ディスク領域管理テーブル
１６ 仮想ディスク
１７ ＣＰＵ管理テーブル
１８ ネットワーク管理テーブル
２０ アプリケーション部
２１ 動作状況通知部
２２ 起動初期化部
２３ ＧＣ制御部
２４ ＯＳメモリ管理部
２５ メモリ領域
２６ 問合せ部
２７ アクセス処理部
２８ 再編成制御部
２９ データ領域
３０ 物理メモリ処理部
３１ 物理メモリ管理部
３２ 物理メモリ状況通知部
４０ 物理ディスク処理部
４１ 物理ディスク管理部
４２ 物理ディスク状況通知部
４３ 物理ＣＰＵ処理部
４４ 物理ＣＰＵ管理部
４５ 物理ＣＰＵ状況通知部
４６ 物理ネットワーク処理部
４７ 物理ネットワーク管理部
４８ 物理ネットワーク状況通知部
８１ ハイパーバイザ部
８２ 仮想計算機
８３ ＯＳ
８４ Ｊａｖａ ＶＭ
８５ プログラム実行部
８６ ＤＢＭＳ
９１ ＣＰＵ
９２ 主記憶装置
９３ 入出力装置
９４ 通信装置
９５ 補助記憶装置
９６ バス
９７ ディスク装置
１３１ アプリＩＤ
１３２ アプリ名称
１３３ ＣＰＵ使用率
１３４ ＧＣ中フラグ
１４１ アプリＩＤ
１４２ 最小位置
１４３ 判定位置
１４４ 最大位置
１４５ 使用位置
１４６ メモリ割当ページ
１４７ ＤＢＭＳＩＤ
１４８ 再編成中フラグ
１４９ 現在容量
１５０ 空き容量
１５１，１５４ アプリＩＤ
１５２，１５５ 使用数
１５３，１５６ 割当済数
９ 物理計算機（資源管理装置）
１０ 割当処理部
１１ 割当制御部
１２ 状況通知受信部
１３ 処理状況管理テーブル
１４ メモリ割当管理テーブル
１５ ディスク領域管理テーブル
１６ 仮想ディスク
１７ ＣＰＵ管理テーブル
１８ ネットワーク管理テーブル
２０ アプリケーション部
２１ 動作状況通知部
２２ 起動初期化部
２３ ＧＣ制御部
２４ ＯＳメモリ管理部
２５ メモリ領域
２６ 問合せ部
２７ アクセス処理部
２８ 再編成制御部
２９ データ領域
３０ 物理メモリ処理部
３１ 物理メモリ管理部
３２ 物理メモリ状況通知部
４０ 物理ディスク処理部
４１ 物理ディスク管理部
４２ 物理ディスク状況通知部
４３ 物理ＣＰＵ処理部
４４ 物理ＣＰＵ管理部
４５ 物理ＣＰＵ状況通知部
４６ 物理ネットワーク処理部
４７ 物理ネットワーク管理部
４８ 物理ネットワーク状況通知部
８１ ハイパーバイザ部
８２ 仮想計算機
８３ ＯＳ
８４ Ｊａｖａ ＶＭ
８５ プログラム実行部
８６ ＤＢＭＳ
９１ ＣＰＵ
９２ 主記憶装置
９３ 入出力装置
９４ 通信装置
９５ 補助記憶装置
９６ バス
９７ ディスク装置
１３１ アプリＩＤ
１３２ アプリ名称
１３３ ＣＰＵ使用率
１３４ ＧＣ中フラグ
１４１ アプリＩＤ
１４２ 最小位置
１４３ 判定位置
１４４ 最大位置
１４５ 使用位置
１４６ メモリ割当ページ
１４７ ＤＢＭＳＩＤ
１４８ 再編成中フラグ
１４９ 現在容量
１５０ 空き容量
１５１，１５４ アプリＩＤ
１５２，１５５ 使用数
１５３，１５６ 割当済数
Claims (17)
- １つ以上の仮想計算機と、その仮想計算機を動作させるためのハイパーバイザ部とを有して構成される仮想計算機環境を物理計算機上に構築するとともに、前記仮想計算機上のＯＳ上で動作するアプリケーション部が使用する計算機資源に対して、前記物理計算機の計算機資源を割り当てる資源管理方法であって、
前記仮想計算機は、割当処理部および前記アプリケーション部を動作させ、
前記アプリケーション部は、前記物理計算機の計算機資源を、前記アプリケーション部が使用する計算機資源として割り当てさせ、
前記割当処理部は、前記アプリケーション部が使用する計算機資源に対して、そのアプリケーション部に割り当て済みの計算機資源が少ないときに、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの計算機資源から、使用されていない計算機資源の解放指示を送信し、
前記アプリケーション部は、前記使用されていない計算機資源の解放指示を受信すると、前記アプリケーション部に割り当てられている計算機資源のうちの前記使用されていない計算機資源を解放するように、前記ハイパーバイザ部に指示することを特徴とする
資源管理方法。 - 前記割当処理部は、前記物理計算機の未割当の計算機資源が少ないときに、前記使用されていない計算機資源の解放指示を送信することを特徴とする
請求項１に記載の資源管理方法。 - 前記割当処理部は、
前記各アプリケーション部から、前記各アプリケーション部の負荷値の通知を受けて、その結果を記憶手段に記憶し、
前記使用されていない計算機資源の解放指示を送信する前記アプリケーション部から、前記記憶手段に記憶されている負荷値が所定値以上の前記アプリケーション部を除外することを特徴とする
請求項１に記載の資源管理方法。 - 前記割当処理部は、前記各アプリケーション部の負荷値として、前記各アプリケーション部のＣＰＵ使用率を前記記憶手段に記憶することを特徴とする
請求項３に記載の資源管理方法。 - 前記割当処理部は、前記各アプリケーション部の負荷値として、前記各アプリケーション部で処理中のリクエスト数を前記記憶手段に記憶することを特徴とする
請求項３に記載の資源管理方法。 - 前記アプリケーション部は、前記アプリケーション部が使用する前記物理計算機の計算機資源としてのメモリ領域について、前記仮想計算機からの物理メモリの割当処理および開放処理を禁止し、前記物理メモリを割り当てる旨の要求を、前記ハイパーバイザ部内の物理メモリ処理部に送信することで、前記物理メモリ処理部に未割当の前記物理メモリを前記メモリ領域に対して割り当てさせ、
前記割当処理部は、前記計算機資源の解放指示処理として、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの前記メモリ領域から、前記物理メモリが割り当てられているが、使用されていない前記メモリ領域内のメモリページの解放指示を送信することを特徴とする
請求項１に記載の資源管理方法。 - 前記アプリケーション部は、前記メモリページの解放指示を受信すると、前記アプリケーション部に割り当てられている前記メモリ領域内の前記メモリページのうち、前記アプリケーション部の使用中のオブジェクトが未配置の前記メモリページに割り当てられている前記物理メモリを解放するように、前記物理メモリ処理部に指示することを特徴とする
請求項６に記載の資源管理方法。 - 前記アプリケーション部は、
前記メモリページの解放指示を受信すると、前記アプリケーション部に割り当てられている前記メモリ領域内の前記メモリページのうち、前記アプリケーション部のオブジェクトが配置済の前記メモリページを対象としてガベージコレクション処理を実行することで、前記アプリケーション部の使用中のオブジェクトが未配置の前記メモリページを確保し、
その確保した前記メモリページに割り当てられている前記物理メモリを解放するように、前記物理メモリ処理部に指示することを特徴とする
請求項６または請求項７に記載の資源管理方法。 - 前記アプリケーション部は、前記アプリケーション部がデータを保持する前記物理計算機の計算機資源としての仮想ディスクへ追加の領域を割り当てる旨の要求を、前記ハイパーバイザ部内の物理ディスク処理部に送信することで、前記物理ディスク処理部に未割当の物理ディスクのデータ領域を前記仮想ディスクに対して割り当てさせ、
前記割当処理部は、計算機資源の解放指示処理として、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの前記仮想ディスクのデータ領域から、使用されていないデータ領域の解放指示を送信することを特徴とする
請求項１に記載の資源管理方法。 - 前記アプリケーション部は、前記仮想ディスクのデータ領域の解放指示を受信すると、前記アプリケーション部に割り当てられている前記仮想ディスク内のデータ領域のうち、前記アプリケーション部の使用中のデータが未配置のデータ領域に割り当てられている前記物理ディスクのデータ領域を削減するように、前記物理ディスク処理部に指示することを特徴とする
請求項９に記載の資源管理方法。 - 前記アプリケーション部は、前記仮想ディスクのデータ領域の解放指示を受信すると、前記仮想ディスクのデータ領域に格納されている前記アプリケーション部のデータに対して不要なデータ領域の削減処理を実行することで、前記アプリケーション部の使用中のデータが記録されていない空きデータ領域を確保し、前記空きデータ領域を解放するように、前記物理ディスク処理部に指示することを特徴とする
請求項９または請求項１０に記載の資源管理方法。 - 前記アプリケーション部は、前記アプリケーション部が使用する前記物理計算機の計算機資源としてのＣＰＵ資源を割り当てる旨の要求を、前記ハイパーバイザ部内の物理ＣＰＵ処理部に送信することで、前記物理ＣＰＵ処理部に未割当の前記ＣＰＵ資源を前記アプリケーション部に対して割り当てさせ、
前記割当処理部は、計算機資源の解放指示処理として、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの前記ＣＰＵ資源から、使用されていない前記ＣＰＵ資源の解放指示を送信することを特徴とする
請求項１に記載の資源管理方法。 - 前記アプリケーション部は、前記ＣＰＵ資源の解放指示を受信すると、前記アプリケーション部に割り当てられている前記ＣＰＵ資源のうち、前記アプリケーション部から使用されていない前記ＣＰＵ資源を削減するように、前記物理ＣＰＵ処理部に指示することを特徴とする
請求項１２に記載の資源管理方法。 - 前記アプリケーション部は、前記アプリケーション部が使用する前記物理計算機の計算機資源としてのネットワーク資源を割り当てる旨の要求を、前記ハイパーバイザ部内の物理ネットワーク処理部に送信することで、前記物理ネットワーク処理部に未割当の前記ネットワーク資源を前記アプリケーション部に対して割り当てさせ、
前記割当処理部は、計算機資源の解放指示処理として、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの前記ネットワーク資源から、使用されていない前記ネットワーク資源の解放指示を送信することを特徴とする
請求項１に記載の資源管理方法。 - 前記アプリケーション部は、前記ネットワーク資源の解放指示を受信すると、前記アプリケーション部に割り当てられている前記ネットワーク資源のうち、前記アプリケーション部から使用されていない前記ネットワーク資源を削減するように、前記物理ネットワーク処理部に指示することを特徴とする
請求項１４に記載の資源管理方法。 - １つ以上の仮想計算機と、その仮想計算機を動作させるためのハイパーバイザ部とを有して構成される仮想計算機環境を物理計算機である資源管理装置上に構築するとともに、前記仮想計算機上のＯＳ上で動作するアプリケーション部が使用する計算機資源に対して、前記物理計算機の計算機資源を割り当てる前記資源管理装置に、
前記仮想計算機が、割当処理部および前記アプリケーション部を動作させる機能と、
前記アプリケーション部が、前記物理計算機の計算機資源を、前記アプリケーション部が使用する計算機資源として割り当てさせる機能と、
前記割当処理部が、前記アプリケーション部が使用する計算機資源に対して、そのアプリケーション部に割り当て済みの計算機資源が少ないときに、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの計算機資源から、使用されていない計算機資源の解放指示を送信する機能と、を実現させ、
前記アプリケーション部に対して、前記使用されていない計算機資源の解放指示を受信すると、前記アプリケーション部に割り当てられている計算機資源のうちの前記使用されていない計算機資源を解放するように、前記ハイパーバイザ部に指示させることを特徴とする
資源管理プログラム。 - １つ以上の仮想計算機と、その仮想計算機を動作させるためのハイパーバイザ部とを有して構成される仮想計算機環境を物理計算機である資源管理装置上に構築するとともに、前記仮想計算機上のＯＳ上で動作するアプリケーション部が使用する計算機資源に対して、前記物理計算機の計算機資源を割り当てる前記資源管理装置であって、
前記仮想計算機が、割当処理部および前記アプリケーション部を動作し、
前記アプリケーション部が、前記物理計算機の計算機資源を、前記アプリケーション部が使用する計算機資源として割り当て、
前記割当処理部が、前記アプリケーション部が使用する計算機資源に対して、そのアプリケーション部に割り当て済みの計算機資源が少ないときに、１つ以上の前記仮想計算機でそれぞれ動作している前記各アプリケーション部に対して、前記各アプリケーション部が動作する前記仮想計算機に割り当て済みの計算機資源から、使用されていない計算機資源の解放指示を送信し、
前記アプリケーション部が、前記使用されていない計算機資源の解放指示を受信すると、前記アプリケーション部に割り当てられている計算機資源のうちの前記使用されていない計算機資源を解放するように、前記ハイパーバイザ部に指示することを特徴とする
資源管理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010100477A JP5466568B2 (ja) | 2009-04-27 | 2010-04-26 | 資源管理方法、資源管理プログラム、および、資源管理装置 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009107783 | 2009-04-27 | ||
| JP2009107783 | 2009-04-27 | ||
| JP2010100477A JP5466568B2 (ja) | 2009-04-27 | 2010-04-26 | 資源管理方法、資源管理プログラム、および、資源管理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010277581A JP2010277581A (ja) | 2010-12-09 |
| JP5466568B2 true JP5466568B2 (ja) | 2014-04-09 |
Family
ID=42993120
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010100477A Active JP5466568B2 (ja) | 2009-04-27 | 2010-04-26 | 資源管理方法、資源管理プログラム、および、資源管理装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20100274947A1 (ja) |
| JP (1) | JP5466568B2 (ja) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE112011103979T5 (de) * | 2010-11-30 | 2013-08-29 | International Business Machines Corporation | Computerprogramm und System für ein Verfahren zur Optimierung der Speicherverwaltung einer auf einer virtuellen Maschine ausgeführten Anwendung |
| US10346276B2 (en) | 2010-12-16 | 2019-07-09 | Microsoft Technology Licensing, Llc | Kernel awareness of physical environment |
| US8943260B2 (en) * | 2011-03-13 | 2015-01-27 | International Business Machines Corporation | Dynamic memory management in a virtualized computing environment |
| CN102306126B (zh) * | 2011-08-24 | 2014-06-04 | 华为技术有限公司 | 内存管理方法、装置和系统 |
| US9152548B2 (en) * | 2012-01-17 | 2015-10-06 | Vmware, Inc. | Controlling access to a privileged resource in user-mode system level mobile virtualization using a ptrace () system call |
| TW201339838A (zh) * | 2012-03-16 | 2013-10-01 | Hon Hai Prec Ind Co Ltd | 虛擬機記憶體管理系統及方法 |
| US8924640B2 (en) * | 2012-05-14 | 2014-12-30 | Alcatel Lucent | Dynamic allocation of records to clusters in a ternary content addressable memory |
| US9703582B1 (en) * | 2012-09-07 | 2017-07-11 | Tellabs Operations, Inc. | Share access of allocated storage space via in-memory file system between virtual machines |
| JP2014081709A (ja) * | 2012-10-15 | 2014-05-08 | Fujitsu Ltd | リソース管理プログラム、リソース管理方法、及び情報処理装置 |
| US9256469B2 (en) | 2013-01-10 | 2016-02-09 | International Business Machines Corporation | System and method for improving memory usage in virtual machines |
| US9639399B2 (en) * | 2013-02-01 | 2017-05-02 | Tencent Technology (Shenzhen) Company Limited | Method, apparatus and terminal for releasing memory |
| JP6089783B2 (ja) * | 2013-02-27 | 2017-03-08 | 富士通株式会社 | 制御装置、リソース制御プログラムおよびリソース制御方法 |
| WO2014171002A1 (ja) * | 2013-04-19 | 2014-10-23 | 株式会社日立製作所 | メモリ管理方法、計算機及び記録媒体 |
| WO2015045046A1 (ja) * | 2013-09-26 | 2015-04-02 | 株式会社日立製作所 | 計算機システムおよび計算機システムのメモリ割当調整方法 |
| US9798567B2 (en) | 2014-11-25 | 2017-10-24 | The Research Foundation For The State University Of New York | Multi-hypervisor virtual machines |
| CN104915151B (zh) * | 2015-06-02 | 2018-12-07 | 杭州电子科技大学 | 多虚拟机系统中一种主动共享的内存超量分配方法 |
| JP6374845B2 (ja) * | 2015-08-07 | 2018-08-15 | 株式会社日立製作所 | 計算機システム及びコンテナ管理方法 |
| US10346050B2 (en) | 2016-10-26 | 2019-07-09 | International Business Machines Corporation | Virtualization of memory compute functionality |
| US10445009B2 (en) * | 2017-06-30 | 2019-10-15 | Intel Corporation | Systems and methods of controlling memory footprint |
| US11016798B2 (en) | 2018-06-01 | 2021-05-25 | The Research Foundation for the State University | Multi-hypervisor virtual machines that run on multiple co-located hypervisors |
| US11934857B2 (en) * | 2021-03-16 | 2024-03-19 | Vmware, Inc. | Supporting execution of a computer program by using a memory page of another computer program |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6898564B1 (en) * | 2000-05-23 | 2005-05-24 | Microsoft Corporation | Load simulation tool for server resource capacity planning |
| JP2002202959A (ja) * | 2000-12-28 | 2002-07-19 | Hitachi Ltd | 動的な資源分配をする仮想計算機システム |
| US7047358B2 (en) * | 2001-12-26 | 2006-05-16 | Boon Storage Technologies, Inc. | High-performance log-structured RAID |
| JP2008225520A (ja) * | 2007-03-08 | 2008-09-25 | Nec Corp | 仮想マシン環境においてメモリ資源を配置するメモリ資源配置制御方法、仮想マシンシステム及びプログラム |
| US8312201B2 (en) * | 2008-06-09 | 2012-11-13 | International Business Machines Corporation | Managing memory allocations loans |
-
2010
- 2010-02-10 US US12/703,691 patent/US20100274947A1/en not_active Abandoned
- 2010-04-26 JP JP2010100477A patent/JP5466568B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US20100274947A1 (en) | 2010-10-28 |
| JP2010277581A (ja) | 2010-12-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5466568B2 (ja) | 資源管理方法、資源管理プログラム、および、資源管理装置 | |
| JP5235989B2 (ja) | 仮想マシンのメモリを管理するためのシステム、方法、及びコンピュータ・プログラム | |
| JP4769484B2 (ja) | 仮想計算機をマイグレーションするための方法およびシステム | |
| EP2791806B1 (en) | Working set swapping using a sequentially ordered swap file | |
| TWI539280B (zh) | 用於分析未經特定設計以提供記憶體分配資訊之應用程式及擷取記憶體分配資訊的方法、及其電腦系統和電腦可讀儲存媒體 | |
| JP4748950B2 (ja) | 記憶領域管理方法及びシステム | |
| KR20150139408A (ko) | 이종의 저장 매체들을 이용하는 분산 파일 시스템을 구동하는 전자 시스템, 및 그것의 데이터 저장 방법 및 관리 방법 | |
| JP6165964B2 (ja) | 計算機 | |
| KR20180045347A (ko) | 가상화 환경에서의 자원 관리 방법 및 이를 지원하는 장치 | |
| KR20070090649A (ko) | 멀티 코어 시스템에서 협력적 스케줄링을 제공하는 장치 및방법 | |
| Chen et al. | Pufferfish: Container-driven elastic memory management for data-intensive applications | |
| Min et al. | Vmmb: Virtual machine memory balancing for unmodified operating systems | |
| JP5820525B2 (ja) | 仮想計算機のスケジュールシステム及びその方法 | |
| CN115617542A (zh) | 内存交换方法、装置、计算机设备及存储介质 | |
| JP2022034455A (ja) | 計算機システムおよび管理方法 | |
| JP5178778B2 (ja) | 仮想計算機およびｃｐｕ割り当て方法 | |
| JP6543219B2 (ja) | 仮想マシン配置装置およびリソース管理方法 | |
| CN107832097B (zh) | 数据加载方法及装置 | |
| JP6135392B2 (ja) | キャッシュメモリ制御プログラム，キャッシュメモリを内蔵するプロセッサ及びキャッシュメモリ制御方法 | |
| JP5158576B2 (ja) | 入出力制御システム、入出力制御方法、及び、入出力制御プログラム | |
| WO2010070529A2 (en) | A method, apparatus and computer program for moving data in memory | |
| EP3293625B1 (en) | Method and device for accessing file, and storage system | |
| JP4862770B2 (ja) | 仮想計算機システムにおけるメモリ管理方式及びその方法、およびプログラム | |
| JP5334048B2 (ja) | メモリ装置および計算機 | |
| JP2008139907A (ja) | ジョブ割当プログラム及びジョブ割当方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130903 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130904 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20131011 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20140114 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20140124 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 5466568 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |