JP5922703B2 - ハイパーバイザ環境内の仮想マシン間で非常駐リソースの使用を同期させるためのシステムおよび方法 - Google Patents

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる題材を含んでいる。著作権の所有者は、特許商標庁の包袋または記録に掲載されるように特許文献または特許情報開示を誰でも複製できることに対して異議はないが、その他の点では何があってもすべての著作権を保有する。

発明の分野：
本発明は一般にアプリケーションサーバおよび仮想マシンに関し、特にハイパーバイザ内で実行される仮想マシン（たとえば、ＪＶＭ）間で非常駐リソースの使用を同期させるためのシステムおよび方法に関する。

背景：
ハイパーバイザを用いたサーバ仮想化は、サーバの動作コストを削減しかつエネルギ効率を改善するための有益な技術である。標準的なオペレーティングシステムを有する標準的なサーバおよび異なるサーバアプリケーションは、それら全体が常時使用されるということは滅多にない。ソフトウェアがアイドリング状態にあるときには現行のサーバハードウェアはエネルギ消費量を大幅に減少させることはないので、これはエネルギの無駄に繋がることになる。サーバ仮想化によって、多くの仮想サーバを単一の物理サーバ上で実行でき、したがって、以前は無駄になっていたプロセッサ（ｃｐｕ）サイクルおよびメモリ）を、その代わりに別の仮想サーバのために用いることができる。これを可能にするソフトウェアのことを本明細書ではハイパーバイザと称する。

オペレーティングシステムおよびサーバアプリケーションが物理ハードウェア上に仮想化されるときには、サーバアプリケーションによりｃｐｕサイクルの使用および／またはメモリの使用が急増する状況に対処するために安全マージンを設けなければならない。サーバアプリケーションリソースの使用がどれほど不安定であるかによって、このマージンは小さい場合もあれば、大きい場合もある。ハイパーバイザ内で実行されるすべての仮想サーバの全体的な不安定さが低ければ、マージンを小さく抑えることができ、より多くの仮想サーバを同一の物理ハードウェア上で信頼性を持って実行できるので、これは一般により大きな余裕をもたらすことになる。

米国特許出願公開第２００８／０３０７１８３号明細書 国際公開第２００８／０１９３８０号

現在のところ、多くのサーバアプリケーションは高級言語Ｊａｖａ（登録商標）で書かれている。このようなアプリケーションは、Ｊａｖａ（登録商標）仮想マシン（Java Virtual Machines）（ＪＶＭs）とともに実行される。残念ながら、ＪＶＭのｃｐｕサイクルおよびメモリの使用は、かなり不安定であり得て、サーバアプリケーション自体から独立している可能性がある。これは、ＪＶＭがＪａｖａヒープをガベージコレクトしなければならず、ホットであると検出されたコードを最適化しなければならないという事実のためである。これらのリソースの使用は、一時的なものであり、相当のものであり得る。

このため、仮想化されたＪａｖａアプリケーションは他のサーバアプリケーションよりも大きな安全マージンを必要とし、これは、仮想化されたＪａｖａサーバアプリケーションの仮想化の余裕が他の種類のサーバアプリケーションの仮想化の余裕よりも少ないことを意味している。これが、本発明の実施例が取組もうとしている分野である。

概要：
ハイパーバイザ内で実行される仮想マシン、たとえばＪａｖａ仮想マシン（ＪＶＭ）間で非常駐リソースの使用を同期させるためのシステムおよび方法が本明細書に開示されている。実施例によれば、このシステムは、非常駐プロセッサ（ｃｐｕ）およびメモリの使用を減らすためにガベージコレクションおよびコード最適化を同期させることができる。実施例によれば、このシステムは、コンピュータと、各々がＪＶＭを実行する仮想サーバを動作させるためのハイパーバイザと、仮想サーバ間の通信チャネルとを備え、各仮想サーバはさらに、常駐および非常駐メモリと、同期モジュールとを備える。実施例によれば、同期モジュールは、重複を最小限に抑えるためにガベージコレクトおよびコード最適化をスケジュールし、それによって、ピーク時の非常駐メモリおよびｃｐｕの使用を減らし、結果として生じるコンピュータ内の非常駐リソースの使用の不安定さを減少させる。別の実施例によれば、クラウドマネージャは、クラウド内のコンピュータの不安定さを最適化するために、仮想サーバをコンピュータ間で移動させることができる。

図面の簡単な説明：

実施例に係る非常駐リソースの使用を同期させるためのシステムの図である。 実施例に係る、ガベージコレクションをいかに前進させることができるかを示すグラフである。 実施例に係る、ラウンドロビンスキームを用いて別個のＪＶＭにおける同時実行のコード最適化をいかに防ぐことができるかを示す図である。 実施例に係る、ガベージコレクトを前進させてコード最適化を延期することによって３つのＪＶＭ間で同期をいかに達成するかを示す図である。 実施例に係る、達成された同期および低い不安定さを異なる尺度で示す図である。 実施例に係る非常駐リソースの使用を同期させる方法のフローチャートである。 実施例に係る、重複を回避するためにガベージコレクトを前進させる方法のフローチャートである。 実施例に係る、コンピュータの不安定さを減少させるためにクラウドマネージャが一群のコンピュータをいかに制御できるかを示す図である。 実施例に係る、コンピュータリソースの使用を減らすためにクラウドマネージャが一群のコンピュータをいかに制御できるかを示す図である。

詳細な説明：
ハイパーバイザ内で実行される仮想マシン、たとえばＪＶＭ間で非常駐リソースの使用を同期させるためのシステムおよび方法が本明細書に記載されている。本明細書に記載されているように、より多くの仮想サーバを同一のハイパーバイザ内で安全に実行できるようにするために各仮想サーバのリソースの使用の不安定さを低くすることが望ましい。残念ながら、ＪＶＭは、相当量のメモリおよびプロセッサ（ｃｐｕ）リソースを消費し得るガベージコレクトおよびコード最適化のために、不安定さがかなり高い。

実施例に従って、異なるＪＶＭにおけるプロセスの実行を前進させるかまたは延期することによって非常駐リソースの使用を同期させることができ、それによって非常駐リソースの使用のピークを回避し、したがって不安定さを低くし、同一の安全マージンでより多くの仮想サーバを単一のハイパーバイザ内で実行できるシステムおよび方法を提供する。これは以下の理由で可能である。すなわち、ガベージコレクションおよびコード最適化が、実行中のシステムの性能に大幅に影響を及ぼすことなくガベージコレクションを前進させることができ、コード最適化を延期できるプロセスである、という理由である。

重複するプロセスを回避することは必ずしも可能であるとは限らない。一定期間にわたって重複する非常駐プロセスの数は、コンピュータの全体的な不安定さの表れである。実施例によれば、この数は、コンピュータが優れた安全マージンを有しているか否かを評価するために用いることができる。別の実施例によれば、不安定さが高いサーバの不安定さを減少させ、不安定さが非効率的に低いサーバの不安定さを増大させるために、仮想サーバをクラウド内のコンピュータ間で移動させることができる。別の実施例によれば、リソースを求めて競い合う他の可能なプロセスがないという理由で、単一のＪＶＭのみを実行できる特化したオペレーティングシステムは仮想サーバの不安定さを減少させることができる。

図１は、実施例に係るシステムの図である。図１に示されるように、このシステムの実施例は一般にハイパーバイザ１０２を有するコンピュータ１００を備えており、そこでは複数の仮想サーバ１０４，１０５，１０７が実行中である。

各仮想サーバは、内部メモリ１０６，１０９，１１１を機能させる必要があるＪＶＭを実行する。各仮想サーバはさらに、アプリケーションサーバコードを実行することが求められるＪａｖａヒープ１０８，１１３，１１５を含んでいる。内部メモリおよびヒープは両方とも、仮にあったとしても、サイズをゆっくりと変化させる常駐メモリ１１０であると考えられる。

ガベージコレクションなどの短寿命プロセスは、メモリ１１２を動作させる必要がある。短寿命プロセスの他の例はコード最適化であり、それに必要なメモリ１１４を動作させる必要がある。これらの短寿命プロセスに必要なメモリは、非常駐メモリ１１６であると考えられる。

各仮想サーバは、同期モジュール１１８，１１９，１２０を含んでいる。これらの同期モジュールのうちの１つは、ランダムにマスター同期モジュール１２０に選ばれる。マスター同期モジュールは、通信チャネル１２２を用いて、ハイパーバイザ内で実行されるすべての仮想サーバの非常駐リソースの使用を同期させる。これは、異なる仮想サーバにおけるガベージコレクションおよびコード生成が同時に実行されることを防ぎ、それによって非常駐メモリおよびｃｐｕサイクルのピーク時の使用を減らすために用いることができる。

図２は、実施例に係る、ガベージコレクションをいかに前進させることができるかを示すグラフである。図２に示されるように、図表２００は、Ｊａｖａヒープの使用されるメモリ２０２が時間とともにいかに増えていくかの例を示している。

使用されるメモリにおける各々の小さな落ち込み２０４は、高速でありかつｃｐｕおよびメモリの使用をほとんど必要としないナーサリーガーベジコレクション（nursery garbage collection）の結果である。

使用されるメモリにおける大きな落ち込み２０６は、相当量のｃｐｕおよびメモリの使用を必要とし得るホールヒープガーベジコレクション（whole heap garbage collection）の結果である。ホールヒープガーベジコレクションは、時刻２０８においてすべてのＪａｖａヒープを使い尽くしたときに強制的に行なわれる。実施例によれば、この時刻は、Ｊａｖａヒープ使用グラフの傾きを線形近似し、この線がＪａｖａヒープサイズ２１０と交わるまでこの線を延ばすことで予測できる。ガベージコレクトの終了時刻は、開始時刻＋同一のＪＶＭにおける以前のガベージコレクトの長さであると予測できる。

ガベージコレクトは、２０８以前であればいつでも開始できる。すなわち、ガベージコレクトは、Ｊａｖａヒープがいっぱいであるときである自然実行時間より前に前進させられる。時刻２１２において、マスター同期モジュールは、予測されたガベージコレクトを時刻２０８から時刻２１４まで前進させる必要がある。実施例によれば、それは、ＧＣが確実に時刻２１４より前に起こるようにするための好適な期限とともに通信チャネル１２２を用いて開始ＧＣトークン２１６を送ることによってなされる。

図３は、実施例に係る、マスター同期モジュールによって制御されるラウンドロビンスキームを用いて別個のＪＶＭにおける同時実行のコード最適化をいかに防ぐことができるかを示す図である。図３に示されるように、３つの最適化キュー３００，３０１，３０３が設けられ、複数のＪＶＭの各々に対して１つの最適化キューが設けられ、各キューは、そのＪＶＭについて最適化が必要な方法の一覧を含んでいる。最適化されたコードは通常、異なるＪＶＭ間では共有されない。なぜなら、最適化は時には、ＪＶＭ間で異なり得るランタイム挙動に依存するためである。最適化されたコードが異なるＪＶＭ間で共有されない別の理由は、最適化されたコードがまた、その特定のＪＶＭ内でのみ有効な固定アドレスへのいくつかのランタイム参照をコード化する、というものである。もし異なるＪＶＭ間で最適化されたコードを移動させれば、これらの参照を再び結びつけなければならないであろう。この例に示されるように、第１のＪＶＭが方法Buyer.toString３０２を最適化した後、同期モジュールは最適化トークン３０４を第２のＪＶＭに転送する。最適化トークンは、多くても最適化トークンによって規定された一定の時間にわたって、この例では１秒間にわたって方法を最適化する権利をＪＶＭに与える。一旦方法が最適化されると、最適化トークンは別のＪＶＭに提供されることができ、プロセスはストライピングの態様で複数のＪＶＭにわたって続いていく。

事実上、ＪＶＭが最適化トークンを受取るまで、ＪＶＭにおけるあらゆる最適化は延期される。ＪＶＭが割当てられた時間内に最適化を完了できなければ、ＪＶＭは、この例では中止された最適化３０６によって示されるように最適化を中止しなければならず、ＪＶＭがその後新たな最適化トークンを与えられると、その後最適化を再開させる。最適化を完了できなかったことは同期モジュールに報告され、この同期モジュールは、この例では２秒である元のタイムスロットの長さを２倍にする修正最適化トークン３０８をＪＶＭに送ることができる。このようにして、MusicPurchase.sampleの最適化をその後再開でき３１０、完了の見込みがより高くなる。

図４は、実施例に係る、ガベージコレクトを前進させてコード最適化を延期することによって３つのＪＶＭ間で同期をいかに達成するかを示す図である。図４に示されるように、ガベージコレクトおよびコード最適化のスケジュールは、スケジュール４００，４０２，４０４，４０６〜４０８の異なるインスタンスから次々に展開する。ガベージコレクトは長方形として視覚化されており、コード最適化は楕円形として視覚化されている。

示される例では、スケジュール４００の第１のインスタンスでは、時刻４１２において、マスター同期モジュールが、時刻４１２において開始し時刻４１６において終了する予測されたガベージコレクト４１４をＪＶＭ１から受取った。マスター同期モジュールはまた、コード最適化４１８をスケジュールした。ＪＶＭ３がガベージコレクト４２０を予測し、ＪＶＭ２がコレクト４２２を予測した。

時刻４２４において、マスター同期モジュールは、ＪＶＭに新たな予測を要求し、その元のインスタンス４００から修正インスタンス４０２にスケジュールを更新する。この例では、スケジュールは、ＪＶＭ１のための新たな予測されたガベージコレクト４２６で更新される。マスター同期モジュールはまた、ガベージコレクト４２２の予測開始時刻が４２８に移動しており、したがって現在予測されているガベージコレクト４２０と重複していることを検出する。

これを解決するために、マスター同期モジュールは、スケジュール４０４を更新し、ガベージコレクト４２０を、重複を回避するのに十分な新たな時刻４３０まで前進させる。それは、好適な開始ＧＣトークンをＪＶＭ３に送ることによってなされる。残念ながら、予定されている最適化４１８を延期しなければならない。なぜなら、短縮した時間枠内では完了しないことを従前の最適化統計が示しているので、予定されている最適化４１８を開始させることができないためである。したがって、予定されている最適化４１８は時刻４３２に移動される。

時刻４３４において、マスター同期モジュールは再び最新の予測をＪＶＭから取得し、したがってスケジュール４０６，４０８を更新でき、新たな最適化４３６をスケジュールできる。

図５は、実施例に係る、達成された同期および低い不安定さを異なる尺度で示す図である。図５に示されるように、スケジュール５００は、現実世界の値を反映する尺度５０２（この例では、２０秒）で実際のガベージコレクションおよびコード最適化を示している。ガベージコレクトはここでも長方形５０４として視覚化されており、コード最適化は楕円形５０６として視覚化されている。示される例では、２つのガベージコレクトが同時に起こるようにスケジュールされている５０８、および、１つのガベージコレクトと１つのコード最適化とが同時に起こる５１０を除けば、ガベージコレクトおよびコード最適化の大半は重複していない。２つのコード最適化が同時に起こるようにスケジュールされていない、ということは注目に値する。したがって、重複の数は２個であり、これは２０秒という期間のコンピュータの不安定さである。

図６は、実施例に係る非常駐リソースの使用を同期させる方法のフローチャートである。図６に示されるように、ステップ６００において、マスター同期モジュールは、ガベージコレクトまたはコード最適化が開始または終了したという、任意のＪＶＭからの通知を待つ。ＪＶＭはまた、以前に報告されたガベージコレクション予測時刻が変化したことをマスター同期モジュールに通知し得る。ステップ６０２において、マスター同期モジュールは、ハイパーバイザ内で実行されるすべてのＪＶＭにガベージコレクトの開始および終了時刻の予測を要求する。マスター同期モジュールは、それに応じてスケジュールを更新する。ステップ６０４において、マスター同期モジュールは、ガベージコレクションの重複を検出し、予測されたガベージコレクトの開始時刻を前進させることによって重複を最小限に抑える。ＪＶＭが予測よりも早く強制的にガベージコレクトを行なう場合、または、ガベージコレクトを前進させることができない場合、依然として重複が存在し得る。これは、アプリケーションの挙動が突然変化する場合に起こる可能性がある。ステップ６０６において、マスター同期モジュールは、コード最適化とガベージコレクトとの重複を検出し、何らかの重複を発見すると、重複を回避するためにコード最適化が延期される。ＪＶＭが予測よりも早く強制的にガベージコレクトを行なう場合、以前として重複が存在し得る。ステップ６０８において、マスター同期モジュールは、ラウンドロビンスキームを用いて新たなコード最適化をスケジュールする。ステップ６１０において、マスター同期モジュールは再び待ち状態に入る。

図７は、実施例に係る、重複を回避するためにガベージコレクトを前進させる方法のフローチャートである。図７に示されるように、ステップ７００において、マスター同期モジュールは、各ガベージコレクトの各開始時点および終了時点について繰返し適用する。各時点において、マスター同期モジュールは、その特定の時点においていくつの他のガベージコレクトがアクティブであるかを数える。マスター同期モジュールは、同時にアクティブであるガベージコレクションの最大数を記憶する。ステップ７０２において、記憶された数が０であるか否かが確認される。なぜなら、０であれば、重複しているガベージコレクションがなく、方法は終了する７０４ためである。重複しているガベージコレクトがあれば７０６、ステップ７０８において、方法は、その他のものと重複する各ガベージコレクトについて、同時に重複しているガベージコレクトの最大数が減少するまでにどれほどガベージコレクトを前進させなければならないかを計算する。どれほど前進させようとも同時実行のガベージコレクトの最大数を減らすことができないガベージコレクトは、前進不可能なガベージコレクトである。すべてのガベージコレクトが前進不可能であれば７１２、方法は終了する。前進可能なガベージコレクトがあれば７１４、システムは最小量の前進を必要とするものを選択し、このガベージコレクトを前進させる。次いで、ステップ７００において方法が再開する。

図７に示される方法は、繰返すごとに同時実行のガベージコレクトの最大数を減らすことになる（ステップ７１６）ので、最終的には終了しなければならない。同時実行のガベージコレクトの数を減らすことができなければ、この方法は、重複しているガベージコレクトがないステップ７０２、または、改善を行なうことができないステップ７１０で終了する。

図８は、実施例に係る、コンピュータの不安定さを減少させるためにクラウドマネージャが一群のコンピュータをいかに制御できるかを示す図である。図８に示されるように、一群のコンピュータ８００は個々のコンピュータ８０２，８０４，８０６を備えており、各々は、１つ以上のＪＶＭ８０８を動作させる複数の仮想サーバを動作させる。各々の単一のコンピュータ内のＪＶＭは、そのコンピュータのマスター同期モジュール８１０，８１２，８１４に関連付けられている。実施例によれば、マスター同期モジュールはクラウド不安定さマネージャ８１６によって制御され、このクラウド不安定さマネージャ８１６は、一般にこのようなクラウド環境が備わった他の管理ツール８１８とともに動作し得る。第１のコンピュータ８０２の全体的な不安定さが高く、すなわち、このコンピュータ上で実行される仮想サーバ間でガベージコレクトとコード最適化とのコリジョンが多く存在し、第２のコンピュータ８０４の全体的な不安定さが低い場合、クラウド不安定さマネージャ８１６は、仮想サーバ８２０および８２２のためのコンピュータホスト８２４を切換えるまたは変更することを決定し得る。コンピュータ８０２の全体的な不安定さの減少が８０４の全体的な不安定さの増大よりも多くなければ、この切換えは元に戻されるであろう。実施例によれば、この切換えに先行して、仮想サーバ８２０が仮想サーバ８２２よりも予測不可能な挙動を有していることを確認する。これは、たとえば、ガベージコレクト間の距離の標準偏差によって測定可能である。

図９は、実施例に係る、コンピュータリソースの使用を減らすためにクラウドマネージャが一群のコンピュータをいかに制御できるかを示す図である。図９に示されるように、一群のコンピュータ９００は個々のコンピュータ９０２，９０４，９０６を備えており、各々は、１つ以上のＪＶＭを動作させる複数の仮想サーバを動作させる。各ＪＶＭは、常駐メモリ使用量９０８と、非常駐メモリ使用量９１０とを有している。メモリおよびｃｐｕの使用量の最大の余裕を達成するために、クラウド不安定さマネージャが、非常駐メモリおよびｃｐｕの使用量が同一である仮想サーバを同一のコンピュータ上に位置付けることも重要である。したがって、すべてのコンピュータ９０２，９０４および９０６が同一の大量の非常駐メモリを必要とするので、クラウド９００は準最適である。仮想サーバを新たなクラウド構成９１１に再配置することによって、サーバ９１２の非常駐メモリの最大使用量は元の構成９０２とほぼ同等になる。しかしながら、非常駐メモリの最大使用量は、元の構成９０４および９０６と比較して、９１４および９１６では大幅に減少する。実施例によれば、このような再配置は、仮想サーバの非常駐メモリ使用量の平均値および標準偏差に基づいている。非常駐メモリ使用量が減少するので、コンピュータ９１４および９１６上により多くの仮想サーバを配置できる。

本発明は、本開示の教示に従ってプログラムされた１つ以上の従来の汎用または専用デジタルコンピュータ、計算装置、マシンまたはマイクロプロセッサを用いて、都合よく実現されてもよい。ソフトウェア分野の当業者に明らかであるように、本開示の教示に基づいて、熟練したプログラマーによって適切なソフトウェアコード化を容易に準備できる。

いくつかの実施例では、本発明は、本発明のプロセスのいずれかを実行するようにコンピュータをプログラムするために用いることができる、命令を記憶させた記憶媒体またはコンピュータ可読媒体であるコンピュータプログラム製品を含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブおよび光磁気ディスクを含む任意のタイプのディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリデバイス、磁気もしくは光カード、（分子記憶ＩＣを含む）ナノシステム、または命令および／もしくはデータの記憶に好適な任意のタイプの媒体もしくはデバイスを含み得るが、それらに限定されない。

本発明の上記の説明は、例示および説明の目的でなされてきた。本発明の上記の説明は、網羅的なものであることを意図したものではなく、本発明を開示されている厳密な形態に限定することを意図したものではない。多くの変形例および変更例が当業者に明らかである。本発明の原理およびその実際の用途を最もよく説明するように実施例を選択して説明し、それによって、当業者は、さまざまな実施例についておよび意図された特定の使用に適したさまざまな変形例とともに、本発明を理解できるようになる。本発明の範囲は、以下の特許請求の範囲およびその等化物によって規定されることが意図されている。

１００，８００，８０２，８０４，８０６，９００，９０２，９０４，９０６，９１４ コンピュータ、１０２ ハイパーバイザ、１０４，１０５，１０７，８２０，８２２ 仮想サーバ、１０６，１０９，１１１ 内部メモリ、１０８，１１３，１１５ ヒープ、１１０ 常駐メモリ、１１２，１１４，２０２ メモリ、１１６ 非常駐メモリ、１１８，１１９，１２０ 同期モジュール、１２０，８１０，８１２，８１４ マスター同期モジュール、１２２ 通信チャネル、３００，３０１，３０３ 最適化キュー、３０４ 最適化トークン、３０６，４１８，４３６ 最適化、３０８ 修正最適化トークン、４００，４０２，４０４，４０６，４０８，５００ スケジュール、４００ インスタンス、４０２ 修正インスタンス、４１４，４２０，４２２，４２６ ガベージコレクト、４１８ コード最適化、４２２ コレクト、８０２ 第１のコンピュータ、８０４ 第２のコンピュータ、８１６ クラウド不安定さマネージャ、８１８ 管理ツール、８２４ コンピュータホスト、９００ クラウド、９０２，９０４ 構成、９０８ 常駐メモリ使用量、
９１０ 非常駐メモリ使用量、９１１ クラウド構成、９１２ サーバ。

Claims (15)

1. 仮想サーバ間で一時的なリソース使用のタイミングを調整するためのシステムであって、
   クラウド内に設けられた１つ以上のコンピュータを備え、前記１つ以上のコンピュータの各々は、
   プロセッサと、
   複数の仮想サーバとを含み、前記複数の仮想サーバの各々は、その関連付けられた仮想サーバにおける、ガベージコレクション、コード最適化、および他のプロセスの時刻を予測する同期モジュールを含み、
   特定の同期モジュールがマスター同期モジュールとして動作するように選択され、前記マスター同期モジュールは、
   他の同期モジュールからの予測を要求し、
   前記予測を用いて、ガベージコレクション、コード最適化、および他のプロセスのスケジュールを更新し、さらに
   前記複数の仮想サーバ間の同期を可能にする通信チャネルを含み、
   前記仮想サーバは、それらに関連付けられた同期モジュールおよび通信チャネルを用いて、そこで実行されている前記ガベージコレクション、コード最適化、および他のプロセスの実行を繰上げまたは延期させることを含みつつ、前記仮想サーバの間で一時的なリソース使用のタイミングを調整する、システム。
2. 各仮想サーバは、１つ以上のＪａｖａ仮想マシン（ＪＶＭ）を実行する、請求項１に記載のシステム。
3. 前記仮想サーバの１つ以上は、単一のＪＶＭのみを実行するように適合されたオペレーティングシステムを含む、請求項１または２に記載のシステム。
4. 一時的に使用されるリソースは、ガベージコレクションプロセスのために使用されるメモリである、請求項１〜３のいずれか１項に記載のシステム。
5. 一時的に使用されるソースは、コード最適化プロセスのために使用されるメモリである、請求項１〜３のいずれか１項に記載のシステム。
6. 一時的に使用されるリソースは、ガベージコレクションプロセスのために使用され、前記同期モジュールは、ガベージコレクションを繰上げて、他のガベージコレクションとの重複を避ける、請求項１〜３のいずれか１項に記載のシステム。
7. 一時的に使用されるリソースは、コード最適化プロセスのために使用され、前記同期モジュールは、コード最適化プロセスを延期させて、ガベージコレクションおよび他のコード最適化との重複を避ける、請求項１〜３のいずれか１項に記載のシステム。
8. 各同期モジュールは、前記通信チャネルを用いて、前記複数の仮想サーバ間で情報を遣り取り、前記仮想サーバ間で一時的なリソース使用のタイミングを調整する、請求項１に記載のシステム。
9. 各同期モジュールは、
   仮想サーバからの通知を待つステップと、
   他の仮想サーバからのガベージコレクション予測を要求するステップと、
   必要に応じてガベージコレクションを繰上げることによって、同時に実行されるガベージコレクションの検出された数を最小化するステップと、
   必要に応じてコード最適化を延期することによって、同時に実行されるコード最適化の検出された数を最小化するステップと、
   ガベージコレクション、コード最適化、または他のプロセスをスケジュールして、前記複数の仮想サーバ間で一時的なリソース使用のタイミングを調整するステップとを実行する、請求項１に記載のシステム。
10. 前記１つ以上のコンピュータは、前記１つ以上の仮想サーバを動作させるための、前記コンピュータ上で実行されるハイパーバイザを含む、請求項１に記載のシステム。
11. 前記システムは、仮想サーバのクラウドにおける一時的に使用されるリソースの使用量に関連付けられる不安定さを制御するためのコンポーネントとして用いられ、前記システムはさらに、
    前記クラウド内のコンピュータの不安定さを監視するクラウド不安定さマネージャと、
    前記クラウドに参加する複数のコンピュータとを備え、１つ以上のコンピュータの各々はさらに、測定されたリソース使用に起因する不安定さを伴うとともに、前記複数の仮想サーバ間で一時的なリソース使用のタイミングを調整するように構成された仮想サーバを含み、
    前記クラウド不安定さマネージャは、前記クラウド内の不安定さを改善するために、前記クラウドに参加する前記複数のコンピュータのうちの第１のコンピュータから、前記クラウドに参加する前記複数のコンピュータのうちの第２のコンピュータへ、仮想サーバを切換えまたは移動させることができる、請求項１に記載のシステム。
12. 前記特定の同期モジュールが前記マスター同期モジュールとして動作するように、複数の同期モジュールからランダムに選択される、請求項１に記載のシステム。
13. 前記マスター同期モジュールは、前記予測を用いて、元のスケジュールから、ガベージコレクション、コード最適化、および他のプロセスの修正後のスケジュールに更新する、請求項１に記載のシステム。
14. 仮想サーバ間で一時的なリソース使用のタイミングを調整する方法であって、
    クラウド内に１つ以上のコンピュータを設けるステップを備え、前記１つ以上のコンピュータの各々は、
    プロセッサと、
    複数の仮想サーバとを含み、前記複数の仮想サーバの各々は、その関連付けられた仮
    想サーバにおける、ガベージコレクション、コード最適化、および他のプロセスの時刻を予測する同期モジュールを含み、
    特定の同期モジュールがマスター同期モジュールとして動作するように選択され、前記マスター同期モジュールは、
    他の同期モジュールからの予測を要求し、
    前記予測を用いて、ガベージコレクション、コード最適化、および他のプロセスのスケジュールを更新し、さらに
    前記複数の仮想サーバ間の同期を可能にする通信チャネルを含み、
    前記仮想サーバは、それらに関連付けられた同期モジュールおよび通信チャネルを用いて、そこで実行されている前記ガベージコレクション、コード最適化、および他のプロセスの実行を繰上げまたは延期させることを含みつつ、前記仮想サーバの間で一時的なリソース使用のタイミングを調整する、方法。
15. プロセッサを含む１つ以上のコンピュータによって読取られて実行されると、前記１つ以上のコンピュータに以下の環境を実現させるプログラムであって、前記１つ以上のコンピュータの各々は、
    複数の仮想サーバを含み、前記複数の仮想サーバの各々は、その関連付けられた仮想サーバにおける、ガベージコレクション、コード最適化、および他のプロセスの時刻を予測する同期モジュールを含み、
    特定の同期モジュールがマスター同期モジュールとして動作するように選択され、前記マスター同期モジュールは、
    他の同期モジュールからの予測を要求し、
    前記予測を用いて、ガベージコレクション、コード最適化、および他のプロセスのスケジュールを更新し、さらに
    前記複数の仮想サーバ間の同期を可能にする通信チャネルを含み、
    前記仮想サーバは、それらに関連付けられた同期モジュールおよび通信チャネルを用いて、そこで実行されている前記ガベージコレクション、コード最適化、および他のプロセスの実行を繰上げまたは延期させることを含みつつ、前記仮想サーバの間で一時的なリソース使用のタイミングを調整する、プログラム。

Images