(57)【要約】  コモディティオペレーションシステム、および一部の、知的所有権下にあり、これまで受け継がれてきたオペレーティングシステムの使用が、アプリケーションプログラムの使用プロファイルを判断するための機能を与えることにより向上され得る。それらの使用プロファイルから、コンピュータリソースの実際の使用が推測される。ユーザに対するチャージバックを含む数多くのことがこの新たなリソースを用いて確立され得る。チャージバックは請求係数を前記プロファイルから形成しそれを実際のユーザ／アプリケーション使用時間に適用することにより改善される。
2007524913.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション作業負荷プロファイル化能力を有するコンピュータシステムであって、
前記コンピュータシステムにおいてリソースを使用するオブジェクトによる前記リソースの使用を追跡し、前記追跡のデータレコードを形成するためのオペレーティングシステム機能と、
前記コンピュータシステムの機能上の動作中に動作するすべての前記各オブジェクトに対し前記使用追跡データを捕捉するためのスナップショット捕捉プログラムとを含み、前記スナップショット捕捉プログラムは負荷下においてプロファイル化されるべきプログラムの使用中にリソースを使用するすべてのオブジェクトに対してアクティブ段階における使用追跡データを含む第１のスナップショット捕捉ファイルを捕捉し、前記スナップショット捕捉プログラムは、さらに、前記コンピュータシステムの第２の状態中にリソースを使用するすべてのオブジェクトに対しアクティブ段階中にリソースを使用するオブジェクトに対し使用追跡データの第２のスナップショット捕捉ファイルを捕捉することに対するものであり、前記コンピュータシステムはさらに、
前記第２のスナップショット捕捉ファイルを前記第１のスナップショット捕捉ファイルから減算するための演算処理を含む、コンピュータシステム。
【請求項２】
前記第２の状態はアイドル状態である、請求項１に記載のコンピュータシステム。
【請求項３】
前記第１の状態は、さらに、第２のアプリケーションプログラムを動作させており、前記第２の状態は、前記第２のアプリケーションプログラムを動作させているだけである、請求項１に記載のコンピュータプログラム。
【請求項４】
前記コンピュータシステムは、さらに、前記使用追跡の前記データレコードをレコードファイルに記録するためのクライアント機能を含む、請求項１に記載のコンピュータシステム。
【請求項５】
前記スナップショット捕捉プログラムは、前記第１および第２のスナップショットを、前記スナップショットに対する機能上の動作中における実質的に同一の時間量を用いて捕捉する、請求項１に記載のコンピュータシステム。
【請求項６】
前記リソース使用オブジェクトはＣＰＵ処理である、請求項１に記載のコンピュータシステム。
【請求項７】
前記リソース使用オブジェクトはＩ／Ｏの処理である、請求項１に記載のコンピュータシステム。
【請求項８】
前記リソース使用オブジェクトは複数のオブジェクトであり、前記複数のオブジェクトの各々に対する使用追跡データは識別可能である、請求項１に記載のコンピュータシステム。
【請求項９】
前記リソース使用オブジェクトは、すべて、リソース使用がオペレーティングシステム機能により追跡される処理である、請求項１に記載のコンピュータシステム。
【請求項１０】
アクティブ段階において用いられる主要処理および前記アプリケーションプログラムにより前記主要リソースにより使用されるリソースの量を明らかにするための手段と、前記明らかにされたデータから、前記アプリケーションプログラムに対する、リソース使用プロファイルを有する報告を作るための手段とを含む、請求項１に記載のコンピュータシス
テム。
【請求項１１】
前記アプリケーションプログラムに対し前記リソース使用プロファイルからのデータを用いて、前記アプリケーションプログラムの使用の請求に対するチャージバックを識別する請求プログラムを有する、請求項１０に記載のコンピュータシステム。
【請求項１２】
前記アプリケーションプログラムに対する前記リソース使用プロファイルから請求係数を作成し、前記請求係数を請求プログラムによるリソース使用の総量に適用して前記アプリケーションプログラムのユーザに対するチャージバックを生成する、請求項１０に記載のコンピュータシステム。
【請求項１３】
コモディティオペレーティングシステムとともに用いるためのアプリケーション作業負荷プロファイル化能力を有するコンピュータシステムであって、前記オペレーティングシステムは、前記コンピュータシステムにおける前記リソースのリソース使用を追跡し前記追跡のデータレコードを形成するためのオペレーティングシステム機能を有し、前記コンピュータプログラムは、
前記コンピュータシステムの機能上の動作中に動作するすべての前記各処理に対し前記使用追跡データを捕捉するためのスナップショット捕捉プログラムを含み、前記スナップショット捕捉プログラムは負荷下においてプロファイル化されるべきプログラムの使用中に動作するすべての処理に対してアクティブ段階における使用追跡データを含む第１のスナップショット捕捉ファイルを捕捉し、前記スナップショット捕捉プログラムは、さらに、異なる状態における前記コンピュータシステムのアクティブ段階中に動作する処理に対し使用追跡データの第２のスナップショット捕捉ファイルを捕捉し、前記コンピュータコンピュータプログラムはさらに、
前記第２のスナップショット捕捉ファイルを前記第１のスナップショット捕捉ファイルから減算するための演算機構を含む、コンピュータプログラム。
【請求項１４】
前記第２の状態はアイドル状態である、請求項１３に記載のコンピュータプログラム。
【請求項１５】
前記第１の状態は、さらに、第２のアプリケーションプログラムを動作させており、前記第２の状態は、単に、前記第２のアプリケーションプログラムを動作させている、請求項１３に記載のコンピュータプログラム。
【請求項１６】
汎用コンピュータシステムにロードされると前記汎用コンピュータに対し請求項１３のコンピュータプログラムの機能性を与えるプログラムが中に含まれるコンピュータ読取可能媒体。
【請求項１７】
汎用コンピュータシステムにロードされると前記汎用コンピュータシステムを請求項１に記載されるコンピュータシステムとして動作するよう構成するプログラムが中に含まれるコンピュータ読取可能媒体。
【請求項１８】
コンピュータシステムのユーザから、前記コンピュータシステム上における前記ユーザに対するアプリケーションプログラム作業負荷に基づいて、チャージバック請求量を確立するための方法であって、
前記アプリケーションプログラムによって用いられる各処理によるリソース使用を追跡するためのオペレーティングシステム機能からリソースによる前記処理使用のスナップショットを得ることと、
前記アプリケーションプログラムに対する予め定められた請求係数を前記スナップショットに対して適用することと、
前記アプリケーションから前記顧客に対して課金するためのチャージバック量を作るこ
ととを含む、方法。
【請求項１９】
前記予め定められた請求係数は前記アプリケーションプログラムのリソース使用プロファイルに基づいて判断される、請求項１８に記載の方法。
【請求項２０】
アプリケーションプログラム作業負荷プロファイル化の方法であって、
リソースを前記コンピュータシステムにおいて用いる各オブジェクトによる前記リソースの使用を追跡し、前記追跡のデータレコードを形成するためのオペレーティングシステム機能から、オブジェクト使用のデータレコードを得ることを含み、前記得ることは、
前記アプリケーションプログラムによる前記コンピュータシステムの機能上のアクティブ段階動作中に動作するすべての前記各オブジェクトに対する使用データの第１のスナップショットと、前記コンピュータシステムの機能上のアイドル段階中に動作するすべての前記各オブジェクトに対する使用データの第２のスナップショットとを捕捉し、さらに、
前記アイドル段階からの前記アイドル段階の第２のスナップショットを、前記アクティブ段階の前記アクティブ段階の第１のスナップショットと比較して、前記オブジェクトのうちのどれが前記アクティブ段階中に前記リソースを用いているかを明らかにすることを含む、方法。
【請求項２１】
前記アイドル段階スナップショットおよび前記アクティブ段階スナップショットは等しく持続する、請求項２０に記載の方法。
【請求項２２】
前記アクティブ段階において前記リソースを用いる前記明らかにされたオブジェクトは、リソース使用量について、比例した値により識別される、請求項２０に記載の方法。
【請求項２３】
リソース使用量について、前記比例した値を用いて、請求係数を確立する、請求項２２に記載の方法。
【請求項２４】
前記アプリケーションプログラムによるリソース使用量について、比例した値を用いて、前記アプリケーションプログラムに対するベースライン作業負荷プロファイルを確立する、請求項２３に記載の方法。
【請求項２５】
前記ベースライン作業負荷プロファイルを、商業的に用いられるシステムにおける、監視される作業負荷プロファイルと比較して、変化が前記プロファイルに生じているかどうかを判断する、請求項２４に記載の方法。
【請求項２６】
変化が前記作業負荷プロファイルにおいて生じている場合、メッセージを、前記コンピュータシステムに対し責任がある主体に送る、請求項２５に記載の方法。
【請求項２７】
前記リソース使用オブジェクトはＣＰＵ処理である、請求項２３に記載の方法。
【請求項２８】
前記リソース使用オブジェクトはＩ／Ｏ処理である、請求項２３に記載の方法。
【請求項２９】
前記リソース使用オブジェクトは複数のオブジェクトであり、前記複数のオブジェクトの各々に対する使用追跡データは識別可能である、請求項２３に記載の方法。
【請求項３０】
前記リソース使用オブジェクトは、すべて、リソース使用がオペレーティングシステム機能により追跡される処理である、請求項２１に記載の方法。
【請求項３１】
第１のアプリケーションプログラム作業負荷プロファイル化の方法であって、
リソースを前記コンピュータシステムにおいて用いる各オブジェクトによる前記リソー
スの使用を追跡し、前記追跡のデータレコードを形成するためのオペレーティングシステム機能から、オブジェクト使用のデータレコードを得ることを含み、前記得ることは、
前記第１のアプリケーションおよび第２のアプリケーションプログラムによる前記コンピュータシステムの機能上のアクティブ段階動作中に動作するすべての前記各オブジェクトに対する使用データの第１のスナップショットと、第２のアプリケーションプログラムによる前記コンピュータシステムの機能上のアクティブ段階中に動作するすべての前記各オブジェクトに対する使用データの第２のスナップショットとを捕捉し、さらに、
前記機能上のアイドル段階の第２のスナップショットを、前記機能上のアクティブ段階の第１のスナップショットと比較して、前記オブジェクトのうちのどれが前記アクティブ段階中に前記リソースを用いているかを明らかにすることを含む、方法。
【発明の詳細な説明】
【背景技術】
【０００１】
背景
コンピュータリソース使用に対する割当および消費制御はこれまでさまざまなパラメータタイプで測定されてきた。ＵＮＩＸ(登録商標）およびＬＩＮＵＸおよびWindows（登録商標） Operating System（ウインドウズ・オペレーティング・システム）環境において今や一般的な、１つのそのようなパラメータは,、ＣＰＵ（中央処理ユニット）時間へのアプリケーションリソース割当の測定を、一般に「性能監視」または「ソフトウェア監視」と呼ばれる機構を介して行なう。（これらのような、ＵＮＩＸ(登録商標）およびＬＩＮＵＸ、Windows（登録商標）および同様のオペレーティングシステムを動作させる環境は一般的には「コモディティ」オペレーティングシステム環境と呼ばれ、なぜならば、これは、それらを、これまでは知的所有権下にあるハードウェア、つまり知的所有権下にあるオペレーティングシステム上で動作してきたオペレーティングシステムから、対照的なものとするからである。知的所有権下にあるオペレーティングシステム（ＯＳ）の例にはＩＢＭ  ３６０およびユニシス（Unyisys）ＯＳ２２００が含まれる。最近までは、サン（Sun）の知的所有権下にある命令プロセッサチップ上でしか動作しなかったサンのソラリス（登録商標）（Solaris）オペレーティングシステムも知的所有権下にあると考えられるであろうが、しかしながら今やそれはインテル（Intel）のプロセッサチップに基づくコンピュータシステム上で動作するよう修正されおり、おそらく「コモディティ」オペレーティングシステムとして考えられるか、またはおそらくはハイブリッドＯＳとして考えられるかもしれない）。ソフトウェア監視の一例はフォーティン（Fortin）らに対して２０００年２月に発行された米国特許第６，０２６，２３６号に見られる。ソフトウェア性能監視は、さらに、ブレークポイントがコードに挿入されこれらを用いて性能の変動を捉えることに依存する米国特許第５，４８５，５７４号（ボロスキー（Bolosky）らにおいてある異なる態様で記載されている。別の例は、ソフトウェアを分析することに対して構築されているブラセインク（Blaseink）の米国特許第４，８４５，６１５号に見られる。（これらの特許は、ここに、それらのそれぞれの全体を、この引用により援用される。）
【発明の開示】
【発明が解決しようとする課題】
【０００２】
ＣＰＵ時間に対して請求することが一般的なメトリックであり各ユーザがアカウント番号を有するような、これまで受け継がれてきた、知的所有権下のメインフレームオペレーティングシステムでは、アカウント番号ごとのＣＰＵ時間の量を測定し報告した。これは、コンピュータサービスの使用に対する請求の根拠、つまりチャージバックを形成した。残念なことに、現在のコモディティオペレーティングシステム環境においては、このメトリックは追跡されない。このように、チャージバック、特に、ＣＰＵの使用に基づくチャージバックを可能にできないことは、コモディティＯＳを、メインフレームコンピュータシステムの数多くの旧来の使用に対して利用することを困難にする。
【０００３】
このメトリックの使用にはコモディティオペレーティングシステムを用いる現代のコンピュータシステムには利用できないさまざまな利点がある。それらの利点の中にあるのは、システムリソース使用に対する直接請求である。ユニシスによる２２００オペレーティングシステムでは、他のシステムリソース、たとえばＩ／Ｏ使用なども記録され請求の対象となり得た。アプリケーションのパフォーマンスに基づく請求と対照比較されると、この直接的なリソース使用測定は車の運転のスピードおよび時間の、走行距離計示数対複雑な示数との類似によって考えられ得る。走行距離計は、リソース使用測定のように、正確にどれぐらいその車が運転されたかを判断するために時間のある所与の点において検討さ
れる必要があるに過ぎない。一方、車が進んだ距離を判断するために必要とされるスピードおよび時間の継続的なチェックはコンピュータ的なリソースを継続的な監視と並んで必要とすることになる。この類似をコンピュータの世界に移し変えると、計算および監視リソースは、まさに、他の態様では、請求可能なサービスを提供し得るリソースであり、したがって、まさに請求することが望まれるリソースをさらに無駄にしている。
【０００４】
さらに、どのアカウントがある特定のリソースのうちのどれほどを用いているかを容易に示すものを、どのアプリケーションが動作しており、およびその動作がどれほどの期間のものであるかを容易に示すものの代わりに与えることにより、複数のアカウントが、１つのアプリケーションを用い得、それに対して容易に構築され得る。
【０００５】
さらに、この「走行距離計」型メトリックは、複数区分化された環境を伴うか否かにかかわらず現代のマルチプロセッサコンピュータシステムにおいて特に重要である診断および負荷平衡化機能において用いられ得る。現在、そのようなメトリックは、コンピュータシステムをコモディティオペレーティングシステムとともに動作させているときには容易に利用可能ではない。
【０００６】
さらに、リソースプロファイル化を呼出すこの「走行距離計」メトリックは、システムおよびアプリケーション特性に対する洞察を、アプリケーションの設計の、知的所有権下にある知識の恩恵なく与える。リソースプロファイルは、アプリケーションの振る舞いを、変動するシステム条件および構成に対してモデル化し予測するよう用いられる。リソースプロファイルはヘテロゴニーのアプリケーションミックスの分析において特に有効である。このリソースプロファイル化は、さらに、キャパシティプラニング、システム健全性監視などを含む数多くの問題にも適用され得る。この技術の第１の適用例は、しかしながら、今日の現代のビジネスにおけるサーバ統合プログラムを取扱うことにおける何らかの手助けを可能にするチャージバックシステムに対する。したがって、リソースプロファイル方法論を有することにより、コンピュータシステムアナリストは、単一の区分環境を有する統合されたサーバコンピュータの調査を、その統合されたサーバ上においてアプリケーションに対しホストとして機能する部門に対してチャージバックを公平に分配するような態様で行ない得る。コンピュータシステムサーバのスケールを増大させることの経済性がますます明らかになるにつれ、このようなツールはサーバ統合の過程を容易にし、したがって、ビジネスサイドにおける、数多くのより小さなサーバを１つのより大きなサーバに統合することに対する反対理由の多くを取除く。
【０００７】
したがって、コモディティオペレーティングシステム環境における作業負荷をプロファイル化する、リソース使用を測定する便利な方法を見付けることは、この欠如している特徴をコモディティオペレーティングシステムに与えるであろう。このリソースプロファイル化を用いることは、他の態様では、コモディティオペレーティングシステムを動作させるコンピュータシステムに対しては利用不可能であるかもしれない、改善された、コンピュータを利用するリソース利用、サーバ統合環境における改善された、かつより公正なチャージバック請求、診断能力および負荷平衡化能力を与えるはずである。
【０００８】
ＣＰＵ、Ｉ／Ｏおよび他のリソース使用について同様のデータを与える、知的所有権下にあるオペレーティングシステムが存在する場合、我々がここに記載するプロファイル化は知的所有権下にあるオペレーティングシステムの文脈においても有用であり得る。
【０００９】
最も使用されているコモディティオペレーティングシステムは、現在、マイクロソフト社のウインドウズ（登録商標）(Windows)オペレーティングシステムであり、したがって、これらの原理の、マイクロソフトのオペレーティングシステム環境に対する適用が、これらの思想が展開される第１の環境であるはずである。
【課題を解決するための手段】
【００１０】
発明の概要
リソースプロファイルの概念の第１の使用において、好ましい実施例は、ウインドウズ環境に存在し、その周知のクライアントプログラム、ウインドウズタスクマネージャ（Windows (登録商標）Task Manager）またはシステムモニタ（System Monitor）を介して最も一般に知られている、ウインドウズＮＴパフォーマンスモニタリングＡＰＩ(Windows (登録商標）Performance Monitoring API)と呼ばれる機構によりＣＰＵ使用を追跡するため、あるオペレーティングシステム機能に依存する。同様の機構が、他のコモディティＯＳに対し、ここにおける教示の利点を利用するよう用いられるはずである。アプリケーションＣＰＵ使用のプロファイルを確立するためには、プロファイル化されつつあるアプリケーションを負荷下で動作させ、ＣＰＵ使用の時間のスナップショットをそのときに動作している処理の各々に対して記録する。これのスナップショット捕捉をとり、絶対値を処理の各々に割当てる。あるベースラインシステムアイドル状態が好適な時間期間（好ましい実施例では、プロファイル化されつつあるプログラムを動作させる同じ時間期間）に対しても維持され、スナップショットを、ウインドウズＮＴパフォーマンスモニタリングＡＰＩを用いてとり、どの処理がオペレーティングシステムおよびコンピュータシステムによってシステムアイドル期間中に用いられるかを判断する。処理の各々により用いられるＣＰＵリソースの絶対値の測定値を初めてとる。次いで、アイドル段階（システムがアイドル中である時間）のスナップショット値をアクティブ段階（プロファイル化のためテスト中のアプリケーションを動作させている間のシステム）に対して導出される値から減算する。システムリソース利用に対する値を減算して出すことにより、アプリケーションに対するリソース利用の真の値が次いで決定される。このプロファイル化されたアプリケーションの処理のすべてが、次いで、パフォーマンスモニタリングＡＰＩから、それらのうちのどれほどが、そのアプリケーションがアクティブである間そのアプリケーションによって用いられる他のリソースに比例して用いられるかとともにわかる。
【００１１】
実験によって、任意のテストされる具体的なアプリケーション構成に対するリソース利用はそのリソース利用に影響する量または強度またはユーザ負荷にかかわらず、一様に留まる傾向がある、と我々は判断した。リソース利用の割合は、プログラムがますます多くのユーザを引受ける中、同じコンピュータシステムの物理的構成およびアプリケーション構成であれば、同じままである傾向がある。アプリケーション構成によって、そのアプリケーションによって必要とされる振る舞いまたは処理の組が本質的に同じままであることが意味される。たとえば、マイクロソフト・エクスチェンジ（Microsoft Exchange）アプリケーションがインターネット上の要求に対して企業間ＬＡＮを提供している場合、またはアンチウイルスオプションがオンである場合、負荷下における処理のミックスは構成におけるこれらの変化のどちらかとともに変動することになる。したがって、一旦、所与の作業負荷構成において、プログラムのためのリソース利用についてのプロファイルが得られると、その測定された処理から、その特定のアプリケーションに対する、測定されないＣＰＵ使用量を、推定し得る。
【００１２】
したがって、これを請求またはチャージバックに適用すると、そのアプリケーションの請求係数がそのプロファイルから導出される。プロファイルの請求係数は（プロファイル化によって明らかにされるように）明示的に測定され得る処理の百分率（または比率）の総計に等しい。次いで、この請求係数を用いてある特定のアプリケーションに対するＣＰＵ請求レートを増大させて、測定されない処理についてのＣＰＵ使用量を補償する。斯くして、請求レートを請求係数で除算してＣＰＵ時間単位に対する請求レートを得る。この同じ演算が、同様の測定能力を有する他のオペレーティングシステムにおいて同様に測定され用いられる他のリソースに対して、適用され得る。
【００１３】
さらに、プロファイルを確立するための、次いで判断を使用、チャージバック、リソースの割当、メンテナンスなどに基づかせるための、この発明の演算処理は、いくつかのこれまで受け継がれてきた、知的所有権下にあるオペレーティングシステムに対しては必要とはされない。そのようなシステムの多くはそれら自身の測定を行なってもよく、なぜならばそれらはアカウントの直接測定およびそれらの実際のＣＰＵ使用をそれらの元来の機能の一部として可能にするからである。これまで受け継がれてきたチャージバックシステムの場合、プロファイルを設定し、処理使用を、アイドル状態のシステム使用から減算されたプロファイルから推定して、何が実際の使用であるかを（ここに教示されるように）判断する必要はない。代わりに、いくつかのこれまで受け継がれてきたシステムでは、実際の使用は記録され直接報告される。この発明を必要とするこの特徴を（この特徴を有さない、一部の、知的所有権下にあるＯＳにあるニーズと並んで）有することは、現代のコモディティＯＳの失敗である。さらに、ＯＳ機能によって供給されるデータがアプリケーションのＣＰＵの使用量または他のリソースの使用量を包含するような、一部のレガシーシステムにおいては、システム健全性監視、リソース割当、性能および費用管理に対処しなければならない数多くの理由から、リソースの使用に対してアプリケーションプロファイルを与えることは依然として有用である。
【発明を実施するための最良の形態】
【００１４】
好ましい実施例の詳細な説明
したがって、処理使用とは何かを見ることから始めるべきであろう。まず、図１を参照して、処理アイドル状態システムＡがＣＰＵ時間のほとんどを占めている。EXCHANGE（交換）アプリケーションＢおよびSYSTEM RESOURCE（システムリソース）アプリケーションはCOMMERCE SERVER（商取引サーバ）ＤおよびSQLSERVER(ＳＱＬサーバ)Ｃそれぞれと同様の時間量を占める。数多くの他のより小さい処理は、円グラフ１０のセクションＦに統合されており、それは、加算し合わされても、実質的により小さなＣＰＵ利用を示している。
【００１５】
アプリケーションプログラムは数多くの「処理」、「スレッド」または「アクティブ構成要素」からなる。これらの、ＣＰＵ時間のサブプログラムレベル処理使用、入力／出力（Ｉ／Ｏ）読出、およびＩ／Ｏ書込は上述のウインドウズオペレーティングシステムパフォーマンスモニタリングＡＰＩにおいて捕捉される。図２において、通常のウインドウズ２０００オペレーティングシステムからの典型的な表示である。ウインドウズタスクマネージャ２０が示される。処理のすべてが表示されているわけではない。一番下の表示からわかるように、６６個の処理が現在動作中であり、１８のみがウインドウにて可視である。
【００１６】
アイドル状態システムにおいて動作中のすべてのプロセスのベースラインサンプリングが、各処理に対するＣＰＵ使用に対応して、カーネルおよびユーザモード時間を示す図３Ａにおいてリスト化されている。図３Ｂにおいては、同様のリストが示されているが、これもタスクマネージャからとられたものであり、COMMERCE SERVER（商取引サーバ）プログラムの２００人のユーザ作業負荷に対する、動作中のすべての処理およびカーネルモード時間を示している。
【００１７】
好ましい実施例のＣＰＵ時間または「カーネルモード」および「ユーザモード」におけるすべての処理のリストおよびそれらのリソース使用のすべては、図３Ａに対してはアイドル状態であり、図３Ｂにおいては２００人のユーザ作業負荷とともにCOMMERCE SERVER（商取引サーバ）を動作させる同一のシステムの起動後にとられるスナップショットにおいて捕捉される。図３Ａからのスナップショットは次いで図３Ｂのスナップショットから減算されて、COMMERCE SERVER（商取引サーバ）が２００人のユーザ負荷とともに動作しているときにアクティブである処理のアプリケーションリソースプロファイルを与える。
【００１８】
この計算を算術的に実行する他の方法があるかもしれないため、図４Ａ〜図４Ｃの図はその概念を一般的な用語で示す。図４Ａの円グラフ４１は、２００人のユーザ作業負荷を伴うCOMMERCE SERVER（商取引サーバ）アプリケーションプログラムにおいて用いられる特定の処理によりとられる、ＣＰＵその他のリソース時間の比率上の使用量（この例ではＣＰＵ時間）を示す。通常どおりのシステムアイドル処理は円グラフ４１上の利用可能な空間のうち最も大きな割合により表わされる。DLLHOST．EXE処理４４に向けられる円グラフの楔形状部分４４が次に大きい。次はINETINFO.EXE楔形状部分４５であり、その後にSYSTEM RESOURCES（システムリソース）４６およびSQLSERVR.EXE４７が続く。残りの処理はまとめられて最後の楔形状部分４８とされる。スナップショットＢはＣＰＵアイドルシステムについてである。ＣＰＵリソースは、ほとんど、システムアイドル処理において、再び、図４Ｂの円グラフ４２において、携わる。しかしながら、もちろん、このシステムアイドル処理はそのアイドルシステムにおいてＣＰＵ時間のほとんどすべてを占める。システム処理を維持し、または基本的な処理を維持するようコンピュータシステムによって必要とされるかもしれない統計またはハウススキーピング活動は非常に小さな楔形状部分４９として現われている。
【００１９】
減算された結果、図４ＣのCOMMERCE SERVER（商取引サーバ）プロファイル円グラフ４３が生ずる。特定の比例した円グラフの楔形状部分を、DLLHOST.EXE、sqlservr.exe４７ａ、inetinfo.exe４５ａおよびシステム(System)４６ａに対し、そのプロファイルの構成要素として有している。
【００２０】
図５において、円グラフ４３Ａにおけるリソース使用のCOMMERCE SERVER（商取引サーバ）プロファイルが示される。ここにおいて、COMMERCE SERVER（商取引サーバ）プログラムにより用いられる最も大きいリソースの割合はDLLHOST.EXEであり、２番目に大きいのはSQLSERVR.EXE、３番目に大きいのはINETINFO.EXEであり、最後に、いくつかのシステムリソースも商取引サーバによって用いられる。実験的に見たように、同じＣＰＵ使用プロファイルが得られるのはたとえ異なる数のユーザが存在する場合であってもCOMMERCE SERVER（商取引サーバ）アプリケーションを動作させているときである。したがって、図６の円グラフ６０は図５の円グラフ４３Ａと同一である。プログラムBizTalkは図７の円グラフ６１として示される異なるプロファイルを確立する。図８では、円グラフ６２が、再び、異なっており、１２００人のユーザの作業負荷レベルで用いられたようにEXCHANGE（交換）プログラムに対するＣＰＵプロファイルにおける異なる処理による異なるリソース利用を示している。
【００２１】
プロファイルおよび請求係数は、プロファイルされつつあるプログラムにかかわらず、ユーザ負荷が増大する中、一定のままであるように見える。したがって、システムの構成および進行中の作業の性質が一定のままである限り、プロファイルのスケーラビリティは、数多くの異なるプログラムに対し、プログラム負荷にわたって一貫している、とかなり確信される。
【００２２】
異なるタイプのコンピュータに対するＣＰＵ構成はプロファイルに影響を与えるようである。したがって、この発明が与え得るチャージバックまたは他のサービスをサポートするようプログラムのプロファイルが用いられるコンピュータシステム構成上におけるプロファイルを確立することは重要である。
【００２３】
図９には、Ｉ／Ｏのバイト当たりのＣＰＵとして特徴付けられる、ＣＰＵ利用対Ｉ／Ｏ利用を示す。マイクロソフト・イクスチェンジに対するチャートはＣＰＵ利用をほとんど有さず、ＣＰＵ使用／Ｉ／Ｏ使用比に対しては非常に小さな数を有しているが、おそらくそれが主にデータ供給プログラムであるからであろう。BizTalk１１１および商取引サー
バ２０００（１１２）は両方とも相対的に高いＣＰＵ利用および同様のＣＰＵ／Ｉ／Ｏ使用比を示している。サーバコンピュータシステムなどをセットアップする際、特定のアプリケーションがコンピュータ向けかまたはＩ／Ｏ向けかを知ることから利益が得られるはずであり、これらのアプリケーションプロファイルの使用はこの貴重な情報を与え得る。さらに、複数のシステム構成設計においてプロファイル化を行なうことにより、顧客使用の前に、その顧客が自身のシステムにおいて使用したいアプリケーションのプロファイルを用いて、システムを調整し得る。
【００２４】
ここで図１０を参照して、コンピュータシステム１３０が発見的な詳細にて示されている。オペレーティングシステム１３１は、コンピュータリソース１３３の使用を、さまざまなプログラムおよび処理により、コンピュータシステムおよびそのメモリ内において制御する。プログラム１３２は、この発明の好ましい実施例に従ってプロファイル化される例示的プログラムであってもよい。プログラム１３２が動作しているとき、ＯＳ１３１は、コンピュータリソース１３３を利用するプログラム１３２を動作させるよう必要とされるさまざまな処理に対する呼出を発生させる。オペレーティングシステム１３１はそのネイティブな機能性の一部として、プログラム１３２によりその動作中に引起されるさまざまな処理（図示せず）によるコンピュータリソースの使用のレコード１３４を保持する。これらのレコードはウインドウズ（登録商標）のオペレーティングシステム環境において、ここにおいては、便宜上、性能監視サービス１３４として言及されるプログラムにおいて保持される。（この機能はいくつかの広く公知のクライアントプログラムを有し、たとえば、タスクマネージャは、実際にまさに、現在ウインドウズＮＴパフォーマンスモニタリングＡＰＩと呼ばれるもののクライアントプログラムであるが、将来、それらは両方とも他の名前で呼ばれるかもしれない。一般に、我々は、処理を動作させることに対し使用データを記録し、これらの統計をクライアントプログラム、たとえば性能監視サービスなどに対して利用可能にするＯＳサービスに言及している。ウインドウズでは、タスクマネージャは処理およびそれらのリソース消費についての情報を明らかにするが、しかしながら、性能監視サービスが実行するサービスも、ネットワークアクティビティおよび記憶（ディスク）使用などのような処理と特定的にリンクされない他のリソース使用情報を明らかにする。ここにおいて具体的に明らかにされるものの他にそのような情報に対する潜在的に数多くの他の使用がある。他のＯＳにおいて、これらの性能監視サービスはさまざまな名称で呼ばれるかもしれない。したがって、共通の名称である性能監視サービスを用いることにより、使用データを、使用データを記すＯＳサービスから集めるプログラムに言及する。）同様の機能が、他のコモディティオペレーティングシステムにおいて見出されてもよく、望ましい場合には適切に置換されてもよい。基本的には、これらの監視サービスは「オブジェクト」の活動を追跡し、それらのリソース利用を記すべきである。オブジェクトは、ＯＳが追跡し得る処理、プロセッサ、サーバまたは任意のオブジェクトであり得る。要求１３５が、プログラム１３２をプロファイル化するようなされると、信号（ＩＮＩＴ）がオペレーティングシステム１３１を介してこの発明のプログラム１３７に送られる。１３７の処理における最初のステップは、コンピュータリソース１３３の、プログラム１３２の使用のスナップショットの捕捉を、タスクマネージャ１３４におけるレコードを読出すことにより行なうことである。この図においては、この段階はブロック９１のスナップショット捕捉によって特徴付けられる。
【００２５】
この情報のさまざまな使用は具体的なリソースタイプの使用に注目することにより対応されるのがよりよいかもしれない。図１１を参照して記載されるように、明らかに、特定のリソース使用（ＣＰＵ対Ｉ／Ｏ読出または書込）からのデータは、負荷平衡化およびリソースのプログラムに対する割当などを含む、プログラムについての重要な情報を明らかにし得ることがわかる。もちろん、ＣＰＵおよびＩ／Ｏ使用を、個々に識別可能なリソース項目として、ある例においては別個に識別し、他の例ではそうしないようにできることは有利となる。たとえば、プロファイルを用いて、どれぐらいのＩ／Ｏをプログラムがコ
ンピュータシステムにおいて得るかを優先順位などに基づいて割当てる場合、所与のコンピュータシステムを共有しているよう期待されるすべてのプログラムに対するＩ／Ｏ対ＣＰＵ使用比を知ることは。
【００２６】
次のブロックの演算処理９２には、図２に示されるものと同様のスナップショット捕捉データの組が、アイドル状態でのコンピュータシステム１３０に対して、およびプログラム１３２が負荷下において動作中であるコンピュータシステム１３０に対して、供給される。アイドル状態測定は、いずれか、オペレーティングシステムおよびその機能に対して中止を開始し、コンピュータシステムをアイドルにセットし、そのアイドル状態を適切な時間において測定するプログラム１３７を介して行なわれ得、そのアイドル状態に対してタスクマネージャレコードにおいて経過する総時間は動作しているプログラム１３２に対してスナップショットにおいてとられる測定値と等しい。次いで、ここにおいて先に記載された演算処理により、アイドル処理時間からのタスクマネージャスナップショットにおけるアイドル処理レコードの値を、プログラム１３２が負荷下において動作していたときから先のスナップショットにおいてとられたタスクマネージャにおけるプログラム処理レコードから減算する。これらの値から、プログラム１３２に対するプロファイルがプロファイルビルダ９３において構築される。このプロファイルを次いでオペレーティングシステム１３１を介して戻し、答１３６を、要求１３５をなした主体に対して与える。
【００２７】
代替的に、非アイドルシステムをベースラインスナップショットとしても用い得る。したがって、ベースライン基準としてのアイドル状態スナップショットは好ましく、より問題が少ないが、それは強制的なものではない。我々は、非アイドルシステムをベースラインスナップショットとして用いていくつかのプロファイルを発生させることに成功した。たとえば、２つのスナップショットＡおよびＢが主にターゲットアプリケーションの作業負荷によってのみ異なる場合、ある受入れ可能なプロファイルを発生させ得る。この場合、処理を数回繰返してプロファイルの組を比較することにより背景アプリケーション作業負荷（ベースラインスナップショットに対する）が２つのスナップショットに対し妥当に一様であったことを納得したいかもしれない。
【００２８】
あるプログラムに対する請求係数を導出することはそのプロファイルを用いることから達成される。たとえば、好ましい実施例におけるあるプロファイルの請求係数は、プロファイラにより明らかにされるように明示的に測定され得る処理の百分率の総和である。たとえば、COMMERCE SERVER（商取引サーバ）請求係数は０．６８＋０．１５＝０．８３である。０．６８は６８％のDLLHOST使用である。１５％はSQLSERVR測定値である。INETINFOに対する１４％およびSYSTEMに対する３％という使用数もあるが、それらは商取引サーバに対する請求係数の一部としては考慮されず、なぜならば、それらを明示的には測定し得ないからである。したがって、この請求係数を用いてCOMMERCE SERVER（商取引サーバ）に対するＣＰＵ請求レートを増大させ、測定されない処理についてのＣＰＵ使用量を補償する。たとえば、ＣＰＵ分当たり＄１を課金する代わりに、COMMERCE SERVER（商取引サーバ）のユーザに対し＄１．２０をＣＰＵ分当たり課金した。これが行なわれるのは、調整された請求レートは標準ＣＰＵ請求レートを請求係数で除したものに等しいからである。COMMERCE SERVER（商取引サーバ）請求レートはしたがってＣＰＵ分当たり＄１を８３％または０．８３で除したものであり、それはＣＰＵ分当たり＄１．２０に等しい。斯くして、請求係数を任意のリソース使用尺度と組合せることにより、顧客は正確な請求を、その顧客が用いているアプリケーションプログラムに対する請求係数およびリソースが用いられる測定された単位の量に基づいて受け得る。
【００２９】
この点を反復し明確にするため、リソース使用の量は、好ましい実施例では、ウインドウズ環境におけるパフォーマンスモニタＡＰＩから得られ得る出力を捕捉することにより、または他のオペレーティングシステム機能から入手可能な実質的に等価なデータを用い
ることにより、捕捉される。この数を請求係数と組合せることによりチャージバックの量が与えられる。
【００３０】
現時点において、アプリケーションの作業負荷プロファイルの使用はチャージバックおよび請求以外の数多くの使用を有し得ることは明らかである。たとえば、あるプロファイルが、規則正しく、所与のシステムにおけるアプリケーションプログラムの使用に対してとられ、そしてそのプロファイルが変化する場合、これは、コンピュータシステムのある特徴の状態の変化を明確に指し示すものであろう。なぜならば、作業負荷はプロファイルに影響を与えないように見られ、それはシステムが機能している態様における変化に違いないからである。したがって、プロファイルの変化は、信号をトリガしてプログラムを修復するか、または人を促して考えられ得る問題を調べさせ、おそらくは予防的な修復をなさせてもよいシステム健全性監視プログラムに加えられる信号であるかもしれない。同様に、そのような変更はセキュリティの問題を知らせるかまたは侵入者検出を知らせてもよく、したがって、セキュリティ監視プログラムまたはセキュリティ監視者にとって、そのような変更について評価されることは適切であろう。さらにより単純には、（同じ作業負荷構成を与えられる場合、）プロファイルにおける大きなシフトではなく、用いられる処理の変更を知らせることにより明らかにされつつある単一の新たな処理についての情報は、セキュリティ専門家に対し、セキュリティ侵害があったかどうかを判断するよう一層の調査を保証することを提案する。さらに、コンピュータシステムをセットアップすることにおいて、アプリケーションプログラムの、またはさらにはＩ／Ｏ対ＣＰＵ使用に関するそれらのプロファイルの作業負荷プロファイルを知ることはユーザまたはビジネスが欲するかもしれない特定のアプリケーションに対して最も効率的なシステム設計をセットアップすることを容易にする。さらに、継続的に、ＯＳシステムそれ自体が、プロファイルの変化に対する応答を、過剰に負荷をかけられたリソースを探し、より使用されていないリソースを障害が生じているタスクに再割当することにより行なう場合には、負荷平衡化が達成され得るであろう。特に、マルチプロセッサおよびマルチ分割されたコンピュータシステムにおいては、この使用は、コンピュータリソース使用の経済性を改善することにおいて極めて重要となるであろう。
【００３１】
プログラムプロファイルデータが用いられ得る数多くの他の方法が存在するが、この発明の範囲は特許請求の範囲を参照してしか限定されない。
【図面の簡単な説明】
【００３２】
【図１】ＣＰＵ利用の円グラフである。
【図２】ウインドウズタスクマネージャの画面ショットの画像である。
【図３Ａ】２つのモードにおけるコンピュータシステム上における処理によるすべてのＣＰＵ利用の部分的なスナップショット捕捉であり、そのシステムをアイドルモードにおいて示す。
【図３Ｂ】２つのモードにおけるコンピュータシステム上における処理によるすべてのＣＰＵ利用の部分的なスナップショット捕捉であり、そのシステムを「商取引サーバ」が２００人のユーザの作業負荷下にある状態で示す。
【図４Ａ】２００人のユーザを伴うCOMMERCE SERVER（商取引サーバ）におけるリソース利用の円グラフである。
【図４Ｂ】ＣＰＵアイドルシステムにおけるリソース利用の円グラフである。
【図４Ｃ】ＣＰＵアイドルからCOMMERCE SERVER（商取引サーバ）プロファイルシステムを引いたものにおけるリソース利用の円グラフである。
【図５】図４Ｃと同様の円グラフである。
【図６】異なるアプリケーションの、円グラフのＣＰＵプロファイル例である。
【図７】異なるアプリケーションの、円グラフのＣＰＵプロファイル例である。
【図８】異なるアプリケーションの、円グラフのＣＰＵプロファイル例である。
【図９】ＣＰＵ対Ｉ／Ｏ利用を示すグラフである。
【図１０】好ましい実施例の使用の発見的なブロック図である。
【図１】
2007524913.tif 000003
【図２】
2007524913.tif 000004
【図３Ａ】
2007524913.tif 000005
【図３Ｂ】
2007524913.tif 000006
【図４Ａ】
2007524913.tif 000007
【図４Ｂ】
2007524913.tif 000008
【図４Ｃ】
2007524913.tif 000009
【図５】
2007524913.tif 000010
【図６】
2007524913.tif 000011
【図７】
2007524913.tif 000012
【図８】
2007524913.tif 000013
【図９】
2007524913.tif 000014
【図１０】
2007524913.tif 000015
【国際調査報告】
2007524913.tif 000016
2007524913.tif 000017