(57)【要約】      （修正有）【課題】共有リソースの迅速な増加を要するアプリケーションの要請に応える共用リソース管理。【解決手段】リソースを必要とするアプリケーションに予備リソース割り当てを確立するステップと、予備リソース割り当てに属さず、利用もないリソースの一部を他のアプリケーションと共有するステップと、アプリケーションがリソースの使用量増加を要求する場合に、アプリケーションによる予備リソース割り当ての消費を許可するステップと、アプリケーションが予備リソース割り当てを消費する際に、リソースの共有可能部分によって予備リソース割り当てを補充するステップと、を含む。これにより、データ処理リソースが、他のアプリケーションがリソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するためにアプリケーションに利用可能になるように、予備リソース割り当てを効果的に管理できる。【選択図】図１
2008041100.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システムのアプリケーション作業負荷管理方法であって、
データ処理リソースを利用する必要があるデータ処理アプリケーション用に前記データ処理リソースに関する予備リソース割り当てを確立するステップと、
前記予備リソース割り当てに属さず、かつ、前記アプリケーションによる利用もない前記データ処理リソースの一部を他のアプリケーションと共有するステップと、
前記アプリケーションが前記データ処理リソースの使用量増加を要求することに応答して、前記アプリケーションによる前記予備リソース割り当ての消費を許可するステップと、
前記アプリケーションが前記予備リソース割り当てを消費する場合に、前記データ処理リソースの前記共有可能部分によって前記予備リソース割り当てを補充するステップとを有し、
前記他のアプリケーションが前記データ処理リソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するために、前記データ処理リソースが前記アプリケーションに利用可能になるように、前記予備リソース割り当てを効果的に管理させ得る方法。
【請求項２】
前記予備リソース割り当てが、前記他のアプリケーションに対して前記リソースを再要求することにより補充される、請求項１に記載の方法。
【請求項３】
前記予備リソース割り当てのサイズが一定である、請求項１又は２に記載の方法。
【請求項４】
前記予備リソース割り当てのサイズが可変であり、前記アプリケーションによる前記データ処理リソースの利用レベルに応じて前記サイズが変更される、請求項１又は２に記載の方法。
【請求項５】
前記予備リソース割り当てが、所定の時間量スケジュールに従って管理される、請求項１乃至４のいずれかに記載の方法。
【請求項６】
前記予備リソース割り当てが、前記アプリケーションの動作状態に従って管理される、請求項１乃至５のいずれかに記載の方法。
【請求項７】
前記予備リソース割り当てが、規定のポリシーに従って管理される、請求項１乃至６のいずれかに記載の方法。
【請求項８】
前記予備リソース割り当てが、自律型自己調節技術を用いて管理される、請求項１乃至７のいずれかに記載の方法。
【請求項９】
前記アプリケーションに対して最小リソース割り当ておよび最大リソース割り当てを指定するステップをさらに含む、請求項１乃至８のいずれかに記載の方法。
【請求項１０】
データ処理リソースと、
前記データ処理リソースを利用する必要があるデータ処理アプリケーション用に前記データ処理リソースに関する予備リソース割り当てを確立する手段と、
前記予備リソース割り当てに属さず、また、前記アプリケーションによる利用もない前記データ処理リソースの一部を他のアプリケーションと共有する手段と、
前記アプリケーションが前記データ処理リソースの使用量増加を要求する場合に、前記アプリケーションによる前記予備リソース割り当ての消費を許可する手段と、
前記アプリケーションが前記予備リソース割り当てを消費する際に、前記データ処理リソースの前記共有可能部分によって前記予備リソース割り当てを補充する手段とを備え、
、
前記他のアプリケーションが前記データ処理リソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するために、前記データ処理リソースが前記アプリケーションに利用可能になるように、前記予備リソース割り当てを効果的に管理可能なデータ処理システム。
【請求項１１】
コンピュータに請求項１乃至９のいずれかに記載の方法を実行させるコンピュータ・プログラム。
【請求項１２】
データ処理プラットフォーム上で実行させることによりアプリケーション作業負荷の管理を支援するコンピュータ・プログラムであり、
データ処理システムで動作するデータ処理アプリケーション用に割り当て可能なようにデータ処理リソースを管理するインターフェースを提供し、
データ処理アプリケーションが利用可能であるとともに、他のアプリケーションと潜在的に共有可能であるリソース・プールを規定する第１リソース割り当てパラメータを、前記インターフェースを介して受信し、
前記リソース・プールにおける前記リソースの最小割り当てであって、前記アプリケーションが占有するとともに前記他のアプリケーションとは共有されない前記最小割り当てを規定する第２リソース割り当てパラメータを、前記インターフェースを介して受信し、
前記アプリケーション用に前記リソース・プールの予備リソース割り当てを規定する第３リソース割り当てパラメータを、前記インターフェースを介して受信し、
前記第３予備リソース割り当てパラメータを用いることにより、前記アプリケーションによる前記リソースの利用レベルに応じて一定または可変となる前記予備リソース割り当てのサイズを決定し、
前記予備リソース割り当てに属さず、また、前記アプリケーションによる利用もない前記データ処理リソースの一部を他のアプリケーションと共有し、
前記アプリケーションが前記データ処理リソースの使用量増加を要求する場合に、前記アプリケーションによる前記予備リソース割り当ての消費を許可し、
前記アプリケーションが前記予備リソース割り当てを消費する際に、前記データ処理リソースの前記共有可能部分によって前記予備リソース割り当てを補充するように構成されており、
前記他のアプリケーションが前記データ処理リソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するために前記データ処理リソースが前記アプリケーションに利用可能になるように、前記予備リソース割り当てを効果的に管理させ得るコンピュータ・プログラム。
【請求項１３】
データ処理プラットフォーム上で実行されることによりアプリケーション作業負荷の管理を支援するコンピュータ・プログラムであって、
データ処理リソースを利用するデータ処理アプリケーションが利用可能であるとともに、他のアプリケーションと潜在的に共有可能である前記データ処理リソースのプールを規定し、
前記アプリケーション用に前記リソース・プールの前記リソースに関する予備リソース割り当てを確立し、
前記予備リソース割り当てに属さず、また、前記アプリケーションによる利用もない前記データ処理リソースの一部を他のアプリケーションと共有し、
前記アプリケーションが前記データ処理リソースの使用量増加を要求する場合に、前記アプリケーションによる前記予備リソース割り当ての消費を許可し、
前記アプリケーションのリソース使用量が変化する間、前記予備リソース割り当てを所望のサイズに動的に維持するように構成されており、
前記他のアプリケーションが前記データ処理リソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するために前記データ処理リソースが前記アプリケーションに利用可能になるように、前記予備リソース割り当てを効果的に管理させ得るコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユニプロセッサ・コンピュータ環境または共有マルチプロセッサ・コンピュータ環境におけるアプリケーション作業負荷の管理に関する。特に、本発明は、同時実行中の作業負荷間において共有データ処理リソースを割り当てる技術を対象としている。
【背景技術】
【０００２】
背景として、ユニプロセッサ・システムまたは共有マルチプロセッサ・システムにおける作業負荷管理では、複数のアプリケーション間におけるデータ処理リソースのインテリジェント共有が行われる。この際、１つのアプリケーションでリソースを独占してしまうことはないため、ピア・アプリケーションの動作が低下することもない。このような方式で管理可能なリソースの例としては、ＣＰＵ時間、メモリ、ディスクＩ／Ｏ帯域幅、およびネットワーク帯域幅等が挙げられる。作業負荷管理システムによっては、リソースを利用するすべてのアプリケーションで必要となる所与のリソース量の判定を行う場合がある（通常はシステム管理者が行う）。そして、リソースは、それぞれがリソースの一部を表す個別の専用リソース・プールに割り当てられる。各専用リソース・プールは、単一のアプリケーションまたは一連の関連アプリケーションが指定することによって、独占使用が可能となる。便宜上、「アプリケーション」という用語は以降、１または複数のアプリケーションを意味するものとする。
【０００３】
各専用リソース・プールはそれぞれのアプリケーションが常に利用可能であるため、固定割り当て方式によれば、アプリケーション応答時間を確実に予測可能となる。ただし、アプリケーションが実際に必要とするリソースは、専用リソース・プールが提供するリソース量よりも少ないことが多いため、リソースの一部が使用されないまま占有されることによって、リソースの利用が最適とはならない場合がある。この問題を是正するため、競合アプリケーション間でのリソース共有を可能にした作業負荷管理システムがある。このシステムでは、固定リソース割り当てを指定する代わりに、すべてのアプリケーション間で共有可能な非専用リソース・プールにおける最低限のリソースがアプリケーションに保証される。この作業負荷管理方法の目的は、一方では、アプリケーションのリソース利用レベルが最低保証レベルを下回らないように保証するとともに、他方では、最低保証レベルを超えるリソースを一時的に必要とする他のアプリケーションとリソースの未割り当て部分を共有可能とすることによって、リソース割り当ての公平性を促進することにある。また、各アプリケーションに付与されるリソースの最大利用を規定するため、最大リソース割り当てを行うこともできる。一部の例では、最大リソース割り当ては固定されるが、他の例では、各アプリケーションが利用可能な全リソース量とその他のアプリケーションによる実際のリソース使用量との差を単純に表す。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記のリソース共有法は、各アプリケーションに最初に付与されるリソースの保証レベルが、リソース最大利用期間に実際に必要となるレベルよりも低くなるのが欠点である。アプリケーションが必要レベル以上のリソースを取得可能となるためには、他のアプリケーションと共有する指定リソース・プールの領域を活用することが唯一の方法である。これは、リソースの使用量が急上昇する期間に、アプリケーションの応答性を予測できなくなる場合があることを意味する。特に、共有リソース・プールが１００％利用されており、アプリケーションによる共有リソース・プールの使用量増加が可能かつ所望の場合は、その要求アプリケーションに追加割り当てを付与可能となる前に、リソース割り当てを担うソフトウェアにより他のアプリケーションに対してリソースを再要求しなければならない。したがって、共有リソース・プールから要求アプリケーションへの追加リソースの割り当てには時間がかかる場合がある。たとえば、リソースがメモリの場合は、データをディスクに移してメモリを解放もしくは再要求可能とする間、アプリケーションの待ち時間が発生することになる。そのようなリソース割り当てにおける遅延は、要求を発するアプリケーションの性能および応答時間に影響を及ぼす可能性がある。
【課題を解決するための手段】
【０００５】
したがって、過大な専用リソース・プールを設けてリソースを浪費する作業負荷管理方法がある一方、共有リソース・プールからの割り当てが不十分で、それ以上のリソースを取得する場合に待ち時間が発生してアプリケーション性能に影響を及ぼす作業負荷管理方法もある。本発明は、後者のようなアプリケーション作業負荷管理における改良を対象としており、リソース共有に固有の問題を回避するためのものである。特に必要となるのは、リソース共有量の迅速な増加を必要とするアプリケーションに不利益をもたらすことなく、データ処理リソースの共有を可能とする技術である。
【０００６】
上記問題の解決および当該技術の進展は、データ処理リソースに関する動的に維持可能な予備リソース割り当ての概念を用いてデータ処理システムのアプリケーション作業負荷を管理する新規な方法、システム、およびコンピュータ・プログラム製品によって達成される。本発明の技術は、上記リソースを利用する必要があるデータ処理アプリケーション用に予備リソース割り当てを確立するステップと、予備リソース割り当てに属さず、また、上記アプリケーションによる利用もない上記リソースの一部を他のアプリケーションと共有するステップと、上記アプリケーションが上記リソースの使用量増加を要求する場合に、アプリケーションによる上記予備リソース割り当ての消費を許可するステップと、上記アプリケーションが上記予備リソース割り当てを消費する際に、上記リソースの共有可能部分によって予備リソース割り当てを補充するステップと、を含む。これにより、前記データ処理リソースが、前記他のアプリケーションが前記データ処理リソースを利用する能力を損なうことなくアプリケーション待ち時間を短縮するために前記アプリケーションに利用可能になるように、上記予備リソース割り当てを効果的に管理できるという利点がある。
【発明の効果】
【０００７】
例示的な実施形態によれば、上記予備リソース割り当てのサイズは、一定または可変とすることができる。後者の場合、予備リソース割り当てのサイズは、上記アプリケーションによる上記リソースの利用レベルに応じて変更する構成であってもよい。また、必要ならば、所定の時間量スケジュールに従って予備リソース割り当てを管理する構成であってもよい。あるいは、上記アプリケーションの動作状態に従って予備リソース割り当てを管理する構成であってもよい。さらに、予備リソース割り当ての管理は、規定のポリシーに従って、または、自律型自己調節技術を用いて行ってもよい。また、予備リソース割り当てのほか、上記アプリケーションに対して最小リソース割り当ておよび最大リソース割り当てを指定することもできる。
【発明を実施するための最良の形態】
【０００８】
次に図面の説明に移行するが、すべての図面において、同様の符号は同様の構成要素を示すものとする。図１は、作業負荷管理システム４をホスティングする例示的なデータ処理システム２を示したものである。データ処理システム２は、シングルプロセッサ・コンピュータまたはマルチプロセッサ・コンピュータ（たとえば、ＳＭＰまたはＮＵＭＡ等）、コンピュータ・クラスタ、あるいはその他所望する任意のコンピュータ・アーキテクチャのいずれであってもよい。作業負荷管理システム４は、複数のアプリケーション８１〜８ｎ用に一連のデータ処理リソース６１〜６ｎを管理する。ただし、数字の「ｎ」は、いずれにおいても任意である。作業負荷管理システム４の役目は、全有効リソース６１〜６ｎの一部を表す一連のリソース割り当て１０を作成することによって、アプリケーション８１〜８ｎ間でリソース６１〜６ｎを共有することである。リソース割り当て１０の付与対象は、個別のアプリケーションまたは一連のアプリケーションのいずれであってもよい。たとえば、アプリケーション８１および８２が個別のリソース割り当て１０１および１０２を有する一方で、アプリケーション８３〜８ｎは、これらアプリケーションにまとめて指定された共通のリソース割り当て１０３を有する。各アプリケーション８１〜８ｎは、プロセス、タスク、スレッド等の従来の実行コンテクスト形式を表し、その動作管理は、データ処理システム２によって行われる。
【０００９】
作業負荷管理システム４は、本発明の高度な作業負荷管理機能を提供するように改良された従来の作業負荷管理ソフトウェアを用いて実施することができる。このような従来の作業負荷管理ソリューションの例としては、ＩＢＭ（登録商標）ＡＩＸ（登録商標）５Ｌ  Ｗｏｒｋｌｏａｄ  ＭａｎａｇｅｒおよびＬｉｎｕｘ（登録商標）ＣＫＲＭ（Ｃｌａｓｓ−ｂａｓｅｄ  Ｋｅｒｎｅｌ  Ｒｅｓｏｕｒｃｅ  Ｍｏｎｉｔｏｒ）フレームワークが挙げられる。いずれの作業負荷管理システムも、アプリケーション・グループに基づくオペレーティング・システム・リソース割り当てをサポートしており、また、システム管理者による手動制御または作業負荷管理ミドルウェアを介した自動制御を可能にするユーザ・インターフェース（たとえば、Ｌｉｎｕｘ（登録商標）ＣＫＲＭのＲｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ（ＲＣＦＳ）インターフェース等）を含む。また、ＣＰＵ時間、メモリ・ページ、ディスクＩ／Ｏ帯域幅、およびネットワーク帯域幅等のリソースに対するポリシー駆動の分化サービス・アクセスを可能にするオペレーティング・システムのカーネル機構も提供される。たとえば、各割り当てリソース・タイプに対してリソース・コントローラ（スケジューラ）を実行することにより、リソース使用量を監視するとともに、各アプリケーションがそれぞれに規定されたリソース共有を確実に享受できるようにする。さらに、リソース使用量およびその他の動作情報をユーザ・インターフェース経由でシステム管理者に報告するためのレポート機構も提供される。システム管理者は、各アプリケーションに対するリソース共有設定を許可されている。各アプリケーションは、共通の動作目的および共通のリソース要求を有する１または複数のタスク群（たとえば、プロセス、スレッド等）を有する構成であってもよい。ユーザ・インターフェースは、システムまたはライブラリ呼び出し、ソケット、ＨＡＬ（ハードウェア分離層）呼び出し、メッセージ通過ＡＰＩ等の任意の適切な技術を用いることにより提供可能である。また、リソース制御ファイル・システム理論を用いてユーザ・インターフェースを提供することも可能である。リソース制御ファイル・システムは、ツリー構造のネーム空間を有しており、各ディレクトリがそれぞれアプリケーションを表す。ユーザは、新しいディレクトリを作成することで新たなアプリケーション・リソース割り当てを作成可能であり、各ディレクトリは、アプリケーションが使用する１または複数のリソースのリソース共有を規定する仮想ファイルを含んでいる。この仮想ファイルには、各リソースの最小リソース割り当ておよび最大リソース割り当て等のパラメータを含んでもよい。また、アプリケーション作業の重要度に基づいて各アプリケーションのリソース共有を自動的に設定する自動作業負荷管理コントローラを、ユーザ・インターフェースを介して構築することができる。そのような適応コントローラは、作業負荷管理システムのレポート機構がフィードバックするリソース使用量の情報を用いることにより、リソース割り当てポリシーを生成することができる。なお、ユーザ・インターフェースを用いれば、システム管理者の手動によってリ��ース割り当てポリシーを作成することもできる。
【００１０】
カーネルベースのソリューションを用いる代わりに、作業負荷管理システム４は、管理するリソースへのアプリケーションのアクセスを制御するオペレーティング・システム・パラメータを変更・監視するために従来のオペレーティング・システム呼び出しを利用するユーザ・デーモンや共用ライブラリ等のユーザレベルのアプリケーション・ソフトウェアを用いて実施することもできる。このような実施方法では、ＩＢＭ（登録商標）ＡＩＸ（登録商標）５Ｌ  Ｗｏｒｋｌｏａｄ  ＭａｎａｇｅｒやＬｉｎｕｘ（登録商標）ＣＫＲＭフレームワークといったカーネル・リソース管理システムが不要となる。また、作業負荷管理を想定していない標準的なオペレーティング・システムを用いることも可能である。実施に関するその他の選択肢としては、オペレーティング・システムおよびユーザレベルのアプリケーション機能の両者を含むハイブリッド・システムとして作業負荷管理システム４を設計する方法が挙げられる。
【００１１】
リソース６１〜６ｎは、アプリケーション８１〜８ｎが利用可能な任意のリソースとすることができる。図１には、ほんの一例として、よく知られた４つのリソース、すなわち、ＣＰＵリソース６１、メモリ・リソース６２、ディスクＩ／Ｏ帯域幅リソース６３、およびネットワーク帯域幅リソース６４を示している。また、管理上の必要性および要望に応じて、追加のリソースをいくつでも（たとえば、６ｎまで）管理することができる。これらのリソースには、アプリケーション８１〜８ｎ間で共有可能ないかなる所望のハードウェア要素、ファームウェア要素、またはソフトウェア要素であっても含むことができる。ＣＰＵリソース６１は、ＣＰＵ時間、アプリケーション当たりのタイムスライス、スケジュール待ち時間（たとえば、実時間アプリケーション用）等を表すことができる。ＣＰＵリソース割り当てが大きなアプリケーションは、ＣＰＵリソース割り当てが小さなアプリケーションと比べて、より多くのＣＰＵ時間が確保されるか、より多くのタイムスライスが割り当てられるか、または、スケジュール待ち時間がより短くなり、その逆も同様である。ＣＰＵの利用は、１つのアプリケーションのスケジューリング優先順位を他のアプリケーションに対して変化させることにより、作業負荷管理システム４において制御することができる。メモリ・リソース６２は、物理メモリ・アドレス空間を表すことができる。メモリ・リソース割り当てが大きなアプリケーションは、メモリ・リソース割り当てが小さなアプリケーションと比べて、より多くの物理メモリが割り当てられ、その逆も同様である。物理メモリは、１つのアプリケーションに割り当てられた物理ページまたは論理ページの数を他のアプリケーションに対して変化させることにより、作業負荷管理システム４において制御することができる。ディスクＩ／Ｏ帯域幅リソース６３は、経時的なディスク・ブロック転送を表すことができる。ディスクＩ／Ｏ帯域幅リソース割り当てが大きなアプリケーションは、ディスクＩ／Ｏ帯域幅リソース割り当てが小さなアプリケーションと比べて、ディスクＩ／Ｏ転送がより高速に行われ、その逆も同様である。ディスクＩ／Ｏ帯域幅は、たとえば先読みキャッシング、バッファリング、ディスク書き出しキャッシング、およびマルチパスＩ／Ｏサブシステムにおける有効パス数、もしくは、先読みキャッシング、バッファリング、ディスク書き出しキャッシング、またはマルチパスＩ／Ｏサブシステムにおける有効パス数を調整する等、１つのアプリケーションのディスクＩ／Ｏ要求を他のアプリケーションに対して優先させることにより、作業負荷管理システム４において制御することができる。ネットワークＩ／Ｏ帯域幅リソース６４は、ネットワーク・スループット、待ち時間、優先度、またはネットワーク接続速度に関するその他の経時的な制限等を表すことができる。ネットワークＩ／Ｏ帯域幅リソース割り当てが大きなアプリケーションは、ネットワークＩ／Ｏ帯域幅リソース割り当てが小さなアプリケーションと比べて、ネットワークＩ／Ｏ転送速度がより速く、その逆も同様である。ネットワークＩ／Ｏスループットは、１つのアプリケーションのソケット割り当て速度の制限、ソケットによる接続処理速度の制限、ＩＰ優先度の管理、ＳＣＴＰパケット／輻輳制御の調整等を他のアプリケーションに対して行うことにより、作業負荷管理システム４において制御することができる。
【００１２】
背景として上述したように、リソースの共有を行う従来の作業負荷管理システムでは、所与のリソースに関して、アプリケーションに対する最小リソース制限および最大リソース制限の指定を行う。また、最小リソース割り当てを超えるリソースの部分（最大リソース割り当てまで）は、他のアプリケーションと共有することができる。この手法は、アプリケーションの実際のリソース使用量が通常、最小リソース割り当てと最大リソース割り当ての間のどこかに存在するという欠点がある。各アプリケーションは、リソース要求が最小リソース割り当てを超え始めた時はいつでも、リソース要求が増加している期間、他のアプリケーションと共有する指定リソース・プールの領域を活用することによって、自らのリソース割り当てを増加させることができる。これにより、たとえばリソースの再要求が必要な場合は、データをディスクに移してメモリを解放するために、アプリケーション待ち時間が発生する可能性がある。
【００１３】
図２を用いて説明する。図２は、リソースが共有可能なプールに属するために、他のアプリケーションに対して再要求する必要がある追加リソース割り当てをアプリケーションが要求する場合に起こり得る待ち時間を示したものである。この問題は、予備リソース割り当ての概念を導入することにより対処可能である。いかなる所与のリソースに関しても、アプリケーションが予備リソース割り当てを利用可能となることによって、実効的な待ち時間を発生することなくアプリケーションのリソース使用量の急上昇に対応することができる。図３に示すように、予備リソース割り当ては他のアプリケーションと共有しないため、リソース使用量の増加に伴って発生する待ち時間は、図２に示す従来の待ち時間から大幅に短縮される。特に、アプリケーションが予備リソース割り当てを活用することによって短縮された待ち時間は、アプリケーションが最小リソース割り当てを利用することに伴う待ち時間と比べても遜色はない。
【００１４】
次に図４を参照して、予備リソース割り当ては、アプリケーションの現在の（経時的に変化する）リソース使用量と最大リソース割り当てとの間に存在する２つの割り当て要素のうち一方である。他方の要素は、他のアプリケーションが利用可能な共有可能割り当てである。共有可能割り当ては、予備リソース割り当てを有するアプリケーションに割り当てられておらず、また、予備リソース割り当てにも属さない所与のリソースの一部を表している。このリソース部分はすべて、最大リソース割り当てまで共用可能である。また、予備リソース割り当ては、明らかに共有不可能であって、大きな待ち時間の発生なくアプリケーションのリソース使用量を増加させることができるため、保証された最小リソース割り当ての漸増を必要に応じて可能にするものと考えられる。ただし、予備リソース割り当ては、最小リソース割り当てとは異なり、（アプリケーションおよびシステム全体もしくはアプリケーションまたはシステム全体による）対象リソースの利用レベルおよびアプリケーション要求とリソース可用性を考慮に入れたポリシーに基づいて、動的に指定、削除、増加、削減、または維持可能である。
【００１５】
例示的なアプリケーションのリソース使用量を示す図４において、Ｔ０〜Ｔ１の時間区分は、サイズＭＩＮの保証された最小リソース割り当てが存在するが、予備リソース割り当ては指定されていない期間を表す。予備リソース割り当ては、Ｔ１まで指定されない。この時点で、予備リソース割り当てのサイズは、リソース利用レベルＲ１と最小リソース割り当てＭＩＮとの差（Ｒ１−ＭＩＮ）である。時刻Ｔ２において、実際のリソース使用量は、レベルＲ１まで増加する。追加リソースは、予備リソース割り当てを活用することにより（この場合は、予備リソース割り当てをすべて消費することにより）、大きな待ち時間の発生なく得られる。作業負荷管理システム４は、予備リソース容量を維持するため、リソース・プールの共有可能部分によって予備リソース割り当てを補充することができる。この際、必要に応じて、必要なリソース量を他のアプリケーションに再要求する。
【００１６】
さらに図５に示すように、このリソース補充処理では、リソース利用レベルＲ２とアプリケーションの現在のリソース利用レベルＲ１との差に等しいサイズとなるように、予備リソース割り当てを動的に維持する。時刻Ｔ２後の予備リソース割り当てのサイズは、現行の予備リソース管理ポリシー（以下参照）に応じて、時刻Ｔ２前の予備リソース割り当てよりも小さく、等しく、または大きくすることができる。上記補充処理では、リソース・プールの残余部分が単に共有可能であるだけでなく実際に共有されていることによりリソース再要求が必要な場合に、時刻Ｔ２からＴ２’までの待ち時間が発生する（図５参照）。ただし、アプリケーションが要求するリソース増加はすでに達成されており、直後に増加を再度要求する可能性も低いため、この待ち時間は通常、許容範囲内となる。この手法の利点は、作業負荷管理システム４がリソース補充を開始できるのに対して、リソース増加を要求しているアプリケーションのリソース要求量が現在の予備リソース・レベルを超えない限り、当該アプリケーションのブロックが発生しないということである。このように、アプリケーションは、予備リソース割り当てが指定された状態である限り、大きな待ち時間の発生なくリソース使用量を常に増加させることができる。
【００１７】
さらに図４に示すように、実際のリソース使用量の２回目の増加が時刻Ｔ３に発生し、３回目の増加が時刻Ｔ４に発生する。いずれにおいても、アプリケーションは、大きな待ち時間の発生なく予備リソース割り当てを活用する。同時に、予備リソース割り当てを消費した場合は、予備リソースを補充してその容量を所望のレベルに維持するために、作業負荷管理システム４がリソースの再要求を行う。時刻Ｔ３において、予備リソース割り当てのサイズは、リソース利用レベルＲ３およびＲ２間の差に等しいサイズまで増加する。また、時刻Ｔ４において、予備リソース割り当てのサイズは、リソース利用レベルＲ４およびＲ３間の差に等しいサイズまで増加する。時刻Ｔ５およびＴ６では、アプリケーションのリソース使用量が減少する。これに対応して、作業負荷管理システム４は、予備リソース割り当てを所望のレベルに維持し続けることができる。時刻Ｔ７では、作業負荷管理システム４によって予備リソース割り当てがアプリケーションから削除される。
【００１８】
各期間Ｔ１〜Ｔ７において、他のアプリケーションは、上記アプリケーションが利用可能な最大リソース割り当ての残余部分を共有することができる。さらに、時刻Ｔ０やＴ７のように予備リソース割り当てが指定されていない場合はいつでも、アプリケーションが使用していない最小リソース割り当て以上の最大リソース割り当てをすべて共用可能である。このように、大きな待ち時間の発生を伴わない追加リソースへのアクセスに関するアプリケーション要求と、同じリソースに対する他のアプリケーションの競合可能性との間で動的なバランスが保たれる。
【００１９】
図６は、作業負荷管理システム４における付加的な作業負荷管理パラメータとして予備リソース割り当てを論理的に表現可能な様式を図示したものである。図６においては、図１に示したアプリケーション８１に対応するリソース割り当て１０１が示されている。ＣＰＵリソース、メモリ・リソース、ディスクＩ／Ｏ帯域幅リソース、ネットワークＩ／Ｏ帯域幅リソース、および「その他」のリソースのそれぞれについて、最大サイズが最大リソース割り当てパラメータＭＡＸによって規定されたリソース・プールが存在する。一方、最小リソース割り当てパラメータＭＩＮは、最小リソース割り当てのサイズを規定する。予備リソース割り当てパラメータＲＥＳは、予備リソース割り当てのサイズを規定するものとして、作業負荷管理システム４により追加で定義可能である。
【００２０】
予備リソース割り当てのサイズは、予備リソース管理ポリシーが規定する予備リソース管理要求に応じて、ＲＥＳパラメータを用いることにより種々の方法で規定することができる。たとえば、ＲＥＳパラメータは、最大リソース割り当てＭＡＸとアプリケーションの現在のリソース使用量との差に占める割合（すなわち、残存リソース容量の割合）を表す数値とすることができる。これにより、アプリケーションの現在のリソース使用量が全リソース・プールの２０％である場合、残りの利用可能または共有可能なリソース空間のサイズは８０％となる。ここで、予備リソース・パラメータＲＥＳを５０％に設定すると、８０％の共有可能部分の５０％すなわち全リソース・プールの４０％の予備リソース割り当てが作成される。このため、予備リソース割り当てによってリソース・プールの４０％が他のアプリケーションと共有されず、リソース・プールの残り４０％の非指定部分のみが共用可能となる。そして、アプリケーションが実際のリソース使用量を全リソース・プールの２０％から６０％に増加させる必要がある場合、要求された４０％の増加は、予備リソース割り当て全体を活用することによって即座に達成される。その後、予備リソース割り当てを残存容量の５０％レベルに維持することにより５０％のＲＥＳパラメータ値を満足するため、全リソース・プールの２０％の新たな予備リソース割り当てを指定する（すなわち、リソース・プールの残り４０％の５０％）。したがって、予備リソース割り当てのサイズは、全リソース・プールの４０％から２０％に減少する。他のアプリケーションが利用可能な共有可能部分についても、全リソース・プールの２０％に減少する。当然のことながら、この予備リソース維持方法では、アプリケーションが全リソース・プールの１００％を活用しようとする場合、予備リソース割り当てのサイズが漸減する。
【００２１】
予備リソース割り当てパラメータ「ＲＥＳ」を提供する代替技術として、アプリケーションのリソース使用量増加に対応可能な状態を維持する必要のある固定量リソースを規定する方法が挙げられる。これは、全リソース・プールに占める割合として表すことができる。したがって、２０％のＲＥＳパラメータ値は、アプリケーションの現在のリソース使用量に加えて、全リソース・プールの２０％を予備として維持しなければならないことを意味する。たとえば、アプリケーションの現在のリソース使用量が全リソース・プールの３０％、５０％、または７０％のいずれであるかに関わらず、全リソース・プールのさらに２０％が予備リソース割り当てに属する予備として維持される（プールには十分なリソース容量が残存する場合）。また、この種のＲＥＳパラメータは、アプリケーションに対応可能な状態を維持する必要のある実際の物理リソース・ユニットを規定可能である。たとえば、図１に示したメモリ・リソース６２の予備リソース割り当ては、ＲＡＭの「ｘ」メガバイト（０＜ｘ＜＝最大有効メモリ）とすることができる。当然のことながら、この予備リソース維持方法では、予備リソース割り当てを規定のサイズに維持するのに十分なリソース容量がプールに存在しなくなる上限に達するまでは少なくとも、アプリケーションの実際のリソース使用量に関わりなく予備リソース割り当てのサイズを保存する。
【００２２】
予備リソース割り当てパラメータ「ＲＥＳ」を提供するさらに別の技術として、予備リソース割り当てのサイズを決定する正確なステップ関数として表現する方法が挙げられる。ステップ関数の入力には、アプリケーションの現在の実リソース使用量、リソース使用量の増加速度、最低保証割り当てＭＩＮ、最大割り当てＭＡＸ、およびリソースの共有可能部分の全利用可能量（すなわち、実際に共有されていない部分）を含むことができる。たとえば、アプリケーションのリソース使用量が高速に増加している場合は、アプリケーションが規定のリソース利用レベルに達するか、またはリソース使用量の増加速度が低下するまで、予備リソース割り当てを指数関数的に増加させることができる。
【００２３】
任意の時刻においてアプリケーションが利用可能な予備リソース割り当ての実際のサイズは、アプリケーションまたはシステム２全体の運用条件に基づいて予備リソース割り当てを管理する動的手法を反映したポリシーによって規定することができる。たとえば、（優先度の高いアプリケーション要求によって）堅牢な予備リソース割り当てをアプリケーションに与えるのに適した特定の時間、および予備リソース割り当てが減少または完全に解除される別の時間（たとえば、リソースに対する他の対象アプリケーションの競合が過大となる時間）を設けてもよい。
【００２４】
任意数の予備リソース管理ポリシーを作業負荷管理システム４により採用して、予備リソース割り当てを経時的に調整することができる。例示的な一手法として、予備リソース管理ポリシーを同期した時間量スケジュールに基づいて実施する方法が挙げられる。たとえば、午前９時〜午前１０時および午後１時から午後５時の１日２回というように、リソースの最大使用が予想される２４時間１周期の所定時間に、作業負荷管理システム４によって予備リソース割り当てをアプリケーションに指定可能である。なお、予備リソース割り当てのサイズは、指定するタイミングに応じて変更してもよい。たとえば、例示的な同期時間量手法として、アプリケーション起動後にはアプリケーション用の初期予備リソース・ポリシーを使用し（たとえば、システム起動後の最初の２０分間）、アプリケーションが定常モードに移行する際には定常状態予備リソース・ポリシーに復帰する方法がある。この初期ポリシーにより、アプリケーションの予備リソース割り当てを非常に大きくすることができるため、システム起動処理の初期化中においても、アプリケーションを急速に立ち上げ可能となる。そして、作業負荷管理システム４は、予備リソース割り当てをごく少量に制限する定常状態ポリシーに復帰させる。アプリケーションが定常モードからバックアップ・モードに切り替わった場合等は、予備リソース割り当て量は大きく変更となるか、または完全に無効化される。また、第３の手法としては、日中のデータ処理および夜間のバッチ処理において、コンピュータ・システムを用いたデータ処理を許可する方法がある。このように、夜間のバッチ処理のスループットを向上させるために増加させた予備リソース割り当てを数個の主要なアプリケーションそれぞれに持たせる一方、日中の対話型処理またはデータ処理用の予備リソースを縮小または無効化する構成であってもよい。
【００２５】
また、作業負荷管理システム４は、アプリケーションの最大使用形態と比較して実際のリソース使用量を考慮に入れたイベント駆動型予備リソース管理ポリシーを提供することもできる。たとえば、別の例示的な手法として、対象アプリケーションの動作状態の検出結果に基づいて非同期的に予備リソース割り当てを指定するポリシーを採用する方法が挙げられる。例として、アプリケーションの最小割り当ての１０％超あるいは全リソース・プールの５０％等、アプリケーションが所定のリソース使用量閾値に到達した場合に予備リソース割り当てが指定されるようにポリシーを規定することができる。予備リソース割り当ての指定には、その他のユーザ定義アプリケーション状態イベントを用いることもできる。その後は、後続のトリガ状態を用いて予備リソース割り当てを削減または削除することができる。
【００２６】
次に図７および８を参照する。これらの図は、作業負荷管理システム４の例示的な実施形態４Ａおよび４Ｂをそれぞれ示しており、アプリケーションに付与する予備リソース割り当てを動的に管理するポリシーが静的に規定されている。このような規定を可能にするため、作業負荷管理システム４Ａおよび４Ｂは、ユーザ・インターフェース１２を備えるとともに、一連の予備リソース管理ポリシー１４を格納するか（システム４Ａ）、もしくは、ポリシー・セット１４を格納した作業負荷管理ミドルウェア・システム１６と相互作用する（システム４Ｂ）。前述の通り、作業負荷管理システム４Ａおよび４Ｂは、オペレーティング・システム・カーネルの一部として、ユーザレベルのアプリケーションとして、あるいはオペレーティング・システムおよびユーザ・アプリケーション機能の両者を含むハイブリッド・システムとして動作可能である。
【００２７】
両作業負荷管理システム４Ａおよび４Ｂのユーザ・インターフェース１２は、システムまたはライブラリ呼び出し、ソケット、ＨＡＬ（ハードウェア分離層）呼び出し、メッセージ通過ＡＰＩ、あるいはＩＢＭ（登録商標）ＡＩＸ（登録商標）５Ｌ  Ｗｏｒｋｌｏａｄ  ＭａｎａｇｅｒおよびＬｉｎｕｘ（登録商標）ＣＫＲＭ（Ｃｌａｓｓ−ｂａｓｅｄ  Ｋｅｒｎｅｌ  Ｒｅｓｏｕｒｃｅ  Ｍｏｎｉｔｏｒ）フレームワーク（上述）といったファイル・システム理論等の任意の適切な技術を用いることにより提供可能である。また、ポリシー・セット１４は、アプリケーションによる予備リソース割り当ての利用を管理するポリシーを含む。たとえば、そのようなポリシーは、アプリケーションによる実際のリソース使用量の変化および他の運用条件（上述）に応じて、予備リソース割り当てのサイズの増減量（またはサイズの維持）を規定することができる。別のポリシーでは、アプリケーションに対して予備リソース割り当て機能を有効にするスケジュールまたは条件を規定することができる。
【００２８】
作業負荷管理システム４Ａはポリシー・セット１４を格納するため、このシステムのインターフェース１２は、システムへのポリシー入力用としてシステム管理者が使用可能である。ポリシー入力は、予備リソース割り当てＲＥＳパラメータの規格、あるいは経時的または現行のシステム条件に基づいて予備リソース割り当ての制御等を行うポリシー・ルールの規格等、任意の適切なフォーマットが可能である。また、作業負荷管理システム４Ａのポリシー処理エンジン１８を用いてポリシー・セット１４を処理することもできる。この処理では、予備リソース割り当てのサイズを動的に設定し、予備リソース割り当て機能の動作状態を管理する。
【００２９】
作業負荷管理システム４Ｂでは、ポリシー・セット１４が作業負荷管理ミドルウェア・システム１６に格納される。このミドルウェア・システム１６もまた、ポリシー・ルールを処理するポリシー処理エンジン１８を含む。このポリシー処理の出力は、インターフェース１２を介して作業負荷管理システム４Ｂに提供される。作業負荷管理システム４Ｂもインターフェース１２を用いて、動作フィードバックをポリシー処理エンジン１８に提供する。
【００３０】
次に図９および１０を参照する。これらの図は、作業負荷管理システム４の例示的な実施形態４Ｃおよび４Ｄをそれぞれ示しており、アプリケーションに対して予備リソース割り当てを指定するポリシーが自己調節技術を用いて自律的に最適化されている。このような動的な決定を可能にするため、作業負荷管理システム４Ｃおよび４Ｄは、ユーザ・インターフェース２０を備えるとともに、遺伝的調節エンジン２２を実装するか（システム４Ｃ）、もしくは、遺伝的調節エンジン２２を実装した作業負荷管理ミドルウェア・システム２４と相互作用する（システム４Ｄ）。ここで再度、前述の通り、作業負荷管理システム４Ｃおよび４Ｄは、オペレーティング・システム・カーネルの一部として、ユーザレベルのアプリケーションとして、あるいはオペレーティング・システムおよびユーザ・アプリケーション機能の両者を含むハイブリッド・システムとして動作可能である。
【００３１】
作業負荷管理システム４Ｃおよび４Ｄの遺伝的調節エンジン２２は、管理されたリソースを利用するアプリケーションの動作を示すアプリケーション監視入力を受信する。このような入力は、アプリケーション自体、オペレーティング・システム、もしくはその両者から受信可能である。また、遺伝的調節エンジン２２は、現在のリソース割り当ておよび利用データを表すリソース割り当て入力も受信する。このような入力は、作業負荷管理システム４Ｃまたは４Ｄ自体から受信可能である。
【００３２】
アプリケーション監視入力は、１または複数のアプリケーションの動作および作業負荷診断を含む構成であってもよい。また、リソース割り当て入力は、最小リソース割り当てＭＩＮ、最大リソース割り当てＭＡＸ、現在のリソース利用レベル、および予備リソース割り当てＲＥＳといった情報を含む構成であってもよい。アプリケーション監視入力およびリソース割り当て入力は、遺伝的調節エンジン２２に渡されて処理される。遺伝的調節エンジン２２は、従来の遺伝的調節技術を用いることにより、数世代の調節サイクルを実行するようにプログラミングすることができる。遺伝的調節エンジン２２は、各世代に対して、（１）アプリケーションに対する予備リソース割り当てを管理する一連のパラメータを選択し、（２）１または複数の上記パラメータを変更して予備リソース割り当てを調整し、（３）予備リソース割り当ての調整後に受信するアプリケーション監視入力を評価し、（４）前世代の評価結果に対する上記評価結果の好適性を算定することができる。予備リソース割り当てパラメータの新たな世代は、最も好適な評価結果に基づいて作成するとともに、この新たな世代に対しても上記処理を繰り返す。このように、アプリケーションの最適な予備リソース割り当てパラメータ・セットを得ることができる。
【００３３】
以上の通り、一時的に指定可能な予備リソース割り当てを用いてデータ処理システムのアプリケーション作業負荷を管理する技術を開示した。当然のことながら、上記の概念は、データ処理システム、コンピュータ実装方法、およびデータ処理システムを制御して要求された機能を実行するために１または複数のコンピュータ読み取り可能媒体によってプログラミング・ロジックが提供されたコンピュータ・プログラム製品のいずれかにおいて種々実施可能である。そのようなプログラミング・ロジックを提供するコンピュータ読み取り可能媒体の例を符号１００として図１１に示す。媒体１００は、コンパクト・ディスク−読み出し専用メモリ（ＣＤ−ＲＯＭ）ディスク、コンパクト・ディスク−読み書き可能（ＣＤ−Ｒ／Ｗ）ディスク、およびデジタル多用途ディスク（ＤＶＤ）等ソフトウェアの市販に従来利用されている種類の携帯型光学式記憶ディスクとして示してある。このような媒体では、本発明のプログラミング・ロジックを、単独、もしくは要求された機能を組み込んだ別のソフトウェア製品と一緒に格納できる。また、プログラミング・ロジックは、携帯型磁気媒体（たとえば、フロッピー・ディスク、フラッシュ・メモリ・スティック等）、ドライブ・システムと組み合わせた磁気媒体（たとえば、ディスク・ドライブ等）、もしくはランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、またはその他の半導体メモリあるいは固体メモリ等のデータ処理プラットフォーム内蔵型媒体によっても提供可能である。より広義には、任意の電子式、磁気式、光学式、電磁式、赤外線式、半導体式システム、装置、またはデバイス、伝送信号、伝播信号、または信号搬送媒体（たとえば、ネットワーク等）、もしくはデータ処理システム、コンピュータ、あるいはその他の命令実行システム、装置、またはデバイスでの使用もしくはこれらと接続して使用するためにプログラミング・ロジックを包含、格納、通信、伝播、または伝送可能なその他の要素等によって上記媒体を構成することもできる。
【００３４】
本発明の種々実施形態を説明したが、多くの変形例および他の実施例を本発明に従って提供可能であることは明らかである。したがって当然のことながら、本発明は、添付した請求の主旨およびその同等物以外によって何ら制限され得るものではない。
【図面の簡単な説明】
【００３５】
本発明の上記ならびにその他の特徴および利点については、添付の図面に示すように、本発明の例示的な実施形態に関する以下の詳細な説明により明らかとなる。
【図１】本発明に従ってアプリケーション作業負荷の管理を行うように構成されたデータ処理システムを示す機能ブロック図である。
【図２】リソースの再要求が必要な場合に、アプリケーションに対するリソース割り当ての増加に伴って発生した実質的な待ち時間をグラフ表示したものである。
【図３】本発明に従って予備リソース割り当てが提供された場合に、アプリケーションに対するリソース割り当ての増加に伴って発生した待ち時間が短縮した様子をグラフ表示したものである。
【図４】アプリケーションによる実際のリソース使用量が経時変化する際の予備リソース割り当ての維持をグラフ表示したものである。
【図５】予備リソース割り当てを消費するアプリケーションによる実際のリソース使用量の増加に追従して、リソース再要求により当該予備リソース割り当てを維持する場合をグラフ表示したものである。
【図６】本発明に係る予備リソース割り当てを含む、アプリケーションに対する一連のリソース割り当てをグラフ表示したものである。
【図７】本発明に係る作業負荷管理システムの第１の例示的実施形態を示すブロック図である。
【図８】図７に示した第１の例示的実施形態の改良を示すブロック図である。
【図９】本発明に係る作業負荷管理システムの第２の例示的実施形態を示すブロック図である。
【図１０】図９に示した第２の例示的実施形態の改良を示すブロック図である。
【図１１】本発明に係る作業負荷管理システムを実施するためのコンピュータ・プログラム製品の提供に使用可能な物理媒体を示す概略図である。
【図１】
2008041100.tif 000003
【図２】
2008041100.tif 000004
【図３】
2008041100.tif 000005
【図４】
2008041100.tif 000006
【図５】
2008041100.tif 000007
【図６】
2008041100.tif 000008
【図７】
2008041100.tif 000009
【図８】
2008041100.tif 000010
【図９】
2008041100.tif 000011
【図１０】
2008041100.tif 000012
【図１１】
2008041100.tif 000013