JP3172423B2 - プロセッサ資源を管理するための装置および方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、相互接続され協調
動作する１組の独立コンピュータ・システム間でのユー
ザ・アプリケーション・プログラム実行のパフォーマン
ス管理に関する。

【０００２】ユーザ・アプリケーション・プログラム
は、コンピュータ・システムの目的である有用な作業を
実行する。このようなアプリケーション・プログラム
は、その実行がコンピュータのオペレーティング・シス
テム・ソフトウェアによって管理される作業単位を形成
する。このようなアプリケーション・プログラムが１つ
の分散作業負荷を形成すると言われるのは、１組の共通
パフォーマンス目標を共用しながら、１組のシステム間
に分散されて実行される独立プログラムであるためであ
る。

【０００３】このようなコンピュータ・システムが独立
していると言われるのは、それぞれが完全に別個であ
り、全体として機能するコンピュータ・システムであっ
て、ＩＢＭの多重仮想記憶／エンタープライズ・システ
ム体系（ＭＶＳ／ＥＳＡ）^TMオペレーティング・システ
ムなどのオペレーティング・システムの専用コピーによ
ってその資源が制御されるためである。また、このよう
なコンピュータ・システムが協調動作すると言われるの
は、それぞれが同一組内の他のコンピュータ・システム
と操作測定データを交換するためである。さらに、この
ようなコンピュータ・システムが相互接続されていると
言われるのは、それぞれが、同一組内の他のすべてのシ
ステムにその操作測定データを送信でき、同一組内の他
のすべてのシステムから類似データを受信できるためで
ある。このようなコンピュータ・システムが１つの組を
構成するのは、すべてが上記の特性を備えているためで
ある。

【０００４】本発明は、オペレーティング・システムが
同一組のシステム用に設定したそれぞれの個別パフォー
マンス目標ごとにパフォーマンス目標クラスを１つずつ
設定できるようになっているという意味でのパフォーマ
ンス管理と、同一組内の単一システムまたは複数システ
ムのいずれで所与のアプリケーション・プログラムが実
行されるかにかかわらず、実行のためにアプリケーショ
ン・プログラムをスケジューリングする部分として各ア
プリケーション・プログラムをそれぞれの目標クラスに
分類することと、所与の目標クラスに割り当てられたア
プリケーション・プログラムが１つの組と見なされるす
べてのシステム間のパフォーマンス目標を達成するよう
に、アプリケーション・プログラムの実行を制御するこ
とに関する。

【０００５】

【従来の技術】１９９４年４月４日に出願され、本発明
の出願人に譲渡され、参照により組み込まれる、J.D.ア
マン他（Aman）による"APPARATUS AND METHOD FOR MANA
GING ADATA PROCESSING SYSTEM WORKLOAD ACCORDING TO
TWO OR MORE DISTINCT PROCESSING GOAL TYPES"という
名称の米国特許出願第０８／２２２７５５号に開示され
た発明では、ユーザ・パフォーマンスの標準と標準の重
要性を指定することができ、その標準および重要性に応
じてシステム・パフォーマンスを管理し、このような管
理の手引きを行うためにシステム・パフォーマンス・パ
ラメータを指定したり人間が介入する必要なしに、導入
システムの目標を達成する責任をオペレーティング・シ
ステム・ソフトウェアが引き継ぐ方法を開示している。
この発明は、１９９４年４月４日に出願され、本発明の
出願人に譲渡され、参照により組み込まれる、C.アイラ
ート（Eilert）およびB.ピアス（Pierce）による"APPAR
ATUS AND METHOD FOR MANAGING SERVER WORKLOAD ACCOR
DING TO CLIENT PERFORMANCE GOALS IN A CLIENT/SERVE
R DATA PROCESSING SYSTEM"という名称の米国特許出願
第０８／２２２７５２号に開示された発明によって、ク
ライアントサーバ環境に拡張された。また、本発明と同
じ日に出願され、本発明の出願人に譲渡される、C.K.ア
イラートおよびP.ヨコム（Yocom）による"APPARATUS AN
D METHOD FORMANAGING A DISTRIBUTED DATA PROCESSING
SYSTEM WORKLOAD ACCORDING TO A PLURALITY OF DISTI
NCT PROCESSING GOAL TYPES"という名称の米国特許出願
第０８／３８３１６８号に開示された発明は、参照によ
り組み込まれる。この発明は、前記特許出願第０８／２
２２７５５号の発明をマルチシステム環境に拡張したも
のである。

【０００６】

【発明が解決しようとする課題】まだ満たされていない
要求条件は、導入システムが、作業負荷によって消費さ
れるプロセッサ資源を制限し、プロセッサ消費標準内の
作業負荷パフォーマンス標準に応じて管理し、複数シス
テム間のパフォーマンス標準と消費標準とを管理できる
ようにすることである。

【０００７】

【課題を解決するための手段】本発明により、作業単位
を１つまたは複数の資源グループにグループ化し、それ
ぞれの資源グループに割り当てられた作業単位によって
消費されるコンピュータ・システム処理容量の最大量と
して消費標準を指定することができる。資源グループ
は、マルチシステムの適用範囲を有することができる。
コンピュータのオペレーティング・システムは、指定さ
れた最大量を実施する。個々のコンピュータ・システム
内の作業単位が消費する処理容量を制限することは、コ
ンピュータ・ソフトウェアの分野では周知であり、作業
単位またはプログラム・キャッピングと呼ばれることが
多い。通常、キャッピングは、１つの作業単位がオペレ
ーティング・システムのディスパッチャ構成要素による
ディスパッチに使用できる時間量を制御することによっ
て実施される。

【０００８】前記の米国特許出願第０８／２２２７５５
号および第０８／３８３１６８号の発明と同様、本発明
でも、１つまたは複数のユーザ・パフォーマンス目標ク
ラスのそれぞれについて１つずつの目標を含むパフォー
マンス標準を指定し、それぞれの目標を達成することの
重要性を指定することができる。さらに本発明では、そ
れぞれが指定のプロセッサ資源消費最大値を有するプロ
セッサ資源消費グループにユーザ・パフォーマンス目標
クラスをグループ化することを含む、プロセッサ消費標
準の指定が可能である。

【０００９】本発明の目的は、資源グループ最大値と、
ユーザ・パフォーマンス目標および重要性が分かってい
る場合に、このような最大値、目標、重要性が最も適切
に達成されるようにコンピュータ・システム資源を実行
作業単位に割り振る責任をオペレーティング・システム
が引き受けることである。

【００１０】資源グループおよびユーザ・パフォーマン
ス目標クラスは、作業負荷が分散されている複数の相互
接続協調動作独立コンピュータ・システムにまたがる可
能性がある。それぞれのローカル・システムは、ローカ
ル・システム上の作業負荷パフォーマンスと資源消費の
データを収集し、そのデータのサブセットを遠隔システ
ムに定期的に同報する。ローカル・システム上で収集し
たデータと、遠隔システムから受け取ったデータとの組
合せにより、それぞれのシステムは、マルチシステムの
最大値、目標、重要性を達成させるために、個別に資源
調整値を決定することができる。

【００１１】

【発明の実施の形態】図１は、３つの相互接続協調動作
コンピュータ・システム（１００−Ａ、１００−Ｂ、１
００−Ｃ）を有する実施例に関する本発明の環境および
主な特徴を示している。本発明の環境は、１組のコンピ
ュータ・システム間に作業負荷が分散されるというもの
である。本発明では、その組のシステムについて単一方
針によりこのような作業負荷を管理することができる。
その組のシステムについて単一方針を用意すれば、分散
作業負荷の単一イメージ・ビューを提供するのに役立
つ。当業者は、本発明の精神または範囲を逸脱せずにこ
のような相互接続協調動作コンピュータ・システムをい
くつでも使用できることが分かるであろう。

【００１２】３つのコンピュータ・システム（１００−
Ａ、１００−Ｂ、１００−Ｃ）は１つの分散作業負荷を
実行し、それぞれのコンピュータ・システムはＩＢＭの
ＭＶＳ／ＥＳＡ^TMオペレーティング・システムなどのオ
ペレーティング・システム（１０１）の専用コピーによ
って制御される。オペレーティング・システムのこのよ
うなコピーのそれぞれは、本明細書に記載する諸ステッ
プを実行する。以下の説明でローカル・システムと言う
場合、それは、説明する諸ステップを実行している特定
のシステムを意味する。管理される他のすべてのシステ
ムは遠隔システムである。すなわち、説明の際の観点
は、ローカル・システムと見なされる特定の１つのシス
テムのものであり、他のすべてのシステムは遠隔システ
ムと見なされる。

【００１３】ディスパッチャ（１０２）は、オペレーテ
ィング・システムの構成要素であって、そのコンピュー
タによって次に実行される作業単位を選択するものであ
る。作業単位（１０３）は、コンピュータ・システムの
目的である有用な作業を実行するアプリケーション・プ
ログラムである。オペレーティング・システムに割り振
られたメモリ内では、それぞれの作業単位は、アドレス
空間制御ブロック（ＡＳＣＢ）（１０４）という制御ブ
ロックによって表される。それぞれのＡＳＣＢは、関連
作業単位をディスパッチしてもよいかどうかをディスパ
ッチャに示す、ディスパッチ制御フィールド（１０５）
を１つずつ有する。このフィールドはキャップ・ビット
（１０５）と呼ばれる。このディスパッチ標識は、本発
明の動作によって設定されるシステム制御データ要素ま
たはパラメータであり、１つの資源グループの作業単位
用に見込まれているプロセッサ実行時間の量を制御する
ために使用する。

【００１４】本発明は、システム管理者によって設定さ
れ、データ記憶機構（１０８）に格納されるパフォーマ
ンス目標（１０６）とプロセッサ消費最大値（１０７）
を入力として受け取る。この目標と最大値は、管理され
るすべてのシステム（１００−Ａ、１００−Ｂ、１００
−Ｃ）にわたる作業に適用される。また、データ記憶機
構（１０８）は、管理されるそれぞれのシステムからア
クセス可能である。

【００１５】ここに示すパフォーマンス目標は応答時間
目標（秒単位）である。当業者は、本発明の精神または
範囲を逸脱せずに他の目標または追加目標を選択できる
ことが分かるだろう。このパフォーマンス目標ととも
に、それぞれの目標の相対的重要性の指定が含まれる。
目標（１０６）は、オペレーティング・システムの作業
負荷マネージャ（ＷＬＭ）構成要素（１０９）によって
各システム（１００−Ａ、１００−Ｂ、１００−Ｃ）に
読み込まれる。システム管理者によって指定された各目
標により、作業負荷マネージャは、個々の作業単位が割
り当てられるユーザ・パフォーマンス目標クラスを設定
することになる。それぞれのユーザ・パフォーマンス目
標クラスは、クラス・テーブル項目（１１０）によって
オペレーティング・システムに割り振られたメモリ内に
表される。クラス・テーブル項目に格納される情報とし
ては、ユーザ・パフォーマンス目標クラスが属す資源グ
ループ名（１１１）（入力値）、ユーザ・パフォーマン
ス目標（１１２）（入力値）、ユーザ・パフォーマンス
目標クラスの相対的重要性（１１３）（入力値）、サン
プル・データ（１１４）（測定データ）、ローカルおよ
びマルチシステム・パフォーマンス・インデックス（１
１５）（計算値）、本発明のオペレーティング・システ
ムによって設定される作業単位のディスパッチ優先順位
などのシステム資源制御（１１６）などがある。

【００１６】ここに示すプロセッサ消費最大値（１０
７）は、プロセッサ・サービス単位で表される。当業者
は、本発明の精神または範囲を逸脱せずにプロセッサ消
費について他の測定単位を選択できることが分かるだろ
う。プロセッサ消費最大値（１０７）は、オペレーティ
ング・システムの作業負荷マネージャ（ＷＬＭ）構成要
素（１０９）によって、それぞれのシステムに読み込ま
れる。システム管理者が指定したそれぞれの資源消費最
大値（１０７）により、作業負荷マネージャは、個々の
作業単位が割り当てられる資源グループを設定すること
になる。それぞれの資源グループは、資源グループ・テ
ーブル項目（１１７）によってオペレーティング・シス
テムに割り振られたメモリ内に表される。資源グループ
・テーブル項目に格納される情報としては、資源グルー
プ名（１１８）（入力値）、プロセッサ・サービス消費
最大値（１１９）（入力値）、ローカル・システムおよ
び遠隔システムからのプロセッサ・サービス消費データ
（１２０および１２１）（測定データ）、資源グループ
内の作業単位をキャッピングしなければならないときの
特定の時間スライス（キャップ・スライス・パターン、
１２２）、すなわち、資源グループに関連する作業単位
がディスパッチ不能であることをキャップ・ビットが示
さなければならないときの特定の時間スライスなどがあ
る。キャップ・スライス・パターン（１２２）は計算値
である。

【００１７】オペレーティング・システムのシステム資
源マネージャ（ＳＲＭ）構成要素（１２３）は、ディス
パッチャ（１０２）による問合せを受けるキャップ・ビ
ット（１０５）値を操作する構成要素を含むように、本
発明により変更される。システム資源マネージャのこの
新しい構成要素は、後述するようにキャップ・ビット操
作プログラム（１３０）と呼ばれる。システム資源マネ
ージャ（１２３）の状態サンプラー（１２４）と、遠隔
データ受信プログラム（１２５）と、マルチシステム目
標主導パフォーマンス制御プログラム（ＭＧＤＰＣ）
（１２６）（Eilert発明に開示されているもの）も、本
発明により変更されており、以下に説明する。

【００１８】状態サンプラー 状態サンプリングは、当技術分野では周知のものであ
る。状態サンプラー（１２４）は、キャップ・ビット操
作プログラム（１３０）によってキャップ・ビット（１
０５）がオンになっているためにディスパッチャが任意
の単位をディスパッチしない場合に追加の状態をサンプ
リングするよう、変更されている。このようなキャップ
・サンプルは、ＭＧＤＰＣ（１２６）が計算に使用する
ときにプロセッサ遅延サンプルと組み合わされる。

【００１９】マルチシステム目標主導パフォーマンス制御プログラム システム資源マネージャ（１２３）のマルチシステム目
標主導パフォーマンス制御プログラム（ＭＧＤＰＣ）
（１２６）は、Eilert発明に記載されている。ＭＧＤＰ
Ｃ（１２６）は、システム資源マネージャの構成要素の
１つであって、パフォーマンス・インデックスを計算
し、管理される１組の相互接続協調動作独立コンピュー
タ・システム間でのユーザ・パフォーマンス目標の達成
を管理するためにディスパッチ優先順位などのシステム
資源制御を調整するものである。ＭＧＤＰＣ（１２６）
は、オペレーティング・システム（１０１）に適応性を
持たせ、自己調整させるように、増分を検出し、パフォ
ーマンス問題を修正するためのフィードバック・ループ
を提供する。ＭＧＤＰＣ（１２６）はタイマの満了によ
って呼び出される。

【００２０】ＭＧＤＰＣの動作については、図１４に詳
しく示す。ＭＧＤＰＣは、目標の達成度を測定し、その
パフォーマンスの改善を必要とするユーザ・パフォーマ
ンス目標クラスを選択し、後述するように関連作業単位
のシステム制御パラメータ（被制御変数）を変更するこ
とにより選択されたユーザ・パフォーマンス目標クラス
のパフォーマンスを改善するという機能を実行する。Ｍ
ＧＤＰＣ機能は、好ましい実施例では約１０秒ごとであ
る定期的なタイマの満了に基づいて、定期的に実行され
る。

【００２１】１４１５では、指定の目標（１４１０また
は１４１１）を使用して、ユーザ・パフォーマンス目標
クラス（１１０）ごとに、マルチシステム・パフォーマ
ンス・インデックスとローカル・パフォーマンス・イン
デックスが計算される。マルチシステム・パフォーマン
ス・インデックス（１４５１）は、管理されるすべての
システム間での目標クラスに関連する作業単位のパフォ
ーマンスを表す。ローカル・パフォーマンス・インデッ
クス（１４５２）は、ローカル・システムでの目標クラ
スに関連する作業単位のパフォーマンスを表す。その結
果得られるパフォーマンス・インデックスは、１４５１
および１４５２で対応するクラス・テーブル項目（１１
０）に記録される。ユーザ・パフォーマンス目標達成度
を測定する方法としてのパフォーマンス・インデックス
の概念は周知である。たとえば、１９９２年４月３０日
に出願され、本発明の出願人に譲渡され、D.Ferguson他
による"WORKLOAD MANAGER FOR ACHIEVING TRANSACTION
CLASS RESPONSE TIME GOALS IN A MULTIPROCESSING SYS
TEM"という名称の米国特許出願第０７／８７６６７０号
には、実際の応答時間を目標応答時間で割ったものとし
てパフォーマンス・インデックスが記載されている。同
出願は参照により組み込まれる。

【００２２】１４１６では、相対的目標重要性（１１
３）の順序のパフォーマンス改善と、パフォーマンス・
インデックス（１４５１、１４５２）の現行値とを受け
取るために、ユーザ・パフォーマンス目標クラスが選択
される。選択されたユーザ・パフォーマンス目標クラス
は、レシーバ（receiver）と呼ばれる。まず、ＭＧＤＰ
Ｃは、作業単位が管理されるすべてのシステム間で目標
を達成するようにする際にそれが行うアクションが可能
な限り最大の影響を及ぼすようにレシーバを選ぶとき
に、マルチシステム・パフォーマンス・インデックス
（１４５１）を使用する。マルチシステム・パフォーマ
ンス・インデックスに基づくアクションが一切行われな
い場合は、ローカル・パフォーマンス・インデックス
（１４５２）を使用して、ローカル・システムがその目
標を達成するのに最も役立つようなレシーバを選択す
る。

【００２３】システム制御データ要素に対するパフォー
マンス隘路は、周知の技法である状態サンプル（１１
４）を使用することにより決定する（１４１７）。この
システム制御データ要素はディスパッチ優先順位（１０
５）（ＣＰＵ遅延およびキャップ遅延に影響する）であ
る。当業者は、本発明の精神または範囲を逸脱せずに他
の被制御変数を選択できることが分かるだろう。

【００２４】１４１８では、被制御変数への潜在的変更
を考慮する。相対的目標重要性（１１３）とパフォーマ
ンス・インデックス（１４５１、１４５２）の現行値に
基づいてパフォーマンス低減を行うことができるユーザ
・パフォーマンス目標クラスが選択される（１４２
３）。このように選択されるユーザ・パフォーマンス目
標クラスはドナー（donor）と呼ばれる。次に、被制御
変数（ディスパッチ優先順位（１４２０）（１０５）に
ついて、レシーバおよびドナーのマルチシステムおよび
ローカル・パフォーマンス・インデックスへの予期変更
に対する提案変更の正味値が査定される（１４２４）。
結果が目標に関してドナーに及ぼす害以上にレシーバに
改善をもたらすと思われる場合には、提案変更が正味値
を有する。提案変更が正味値を有する場合は、それぞれ
の被制御変数がドナーとレシーバの両方のために調整さ
れる。

【００２５】ＭＧＤＰＣを呼び出すごとに、その間、レ
シーバ目標クラスと、パフォーマンス隘路と、ドナー目
標クラスと、アクションとのあらゆる組合せが考慮され
る。被制御変数の企図変更は十分なレシーバ値をもたら
さなければならず、レシーバ（複数も可）とドナー（複
数も可）との間で企図される再割振りは、実際に行われ
る企図変更用の正味値を備えていなければならない。こ
れらのステップについては、以降の項で詳述する。

【００２６】管理される各システムは、それぞれのシス
テムが他のすべてのシステムにデータ・レコードを送信
できるようにするデータ送信手段（１２９）を１つずつ
有する。それぞれの目標クラスの最新パフォーマンスを
記述するデータ・レコード（図２３）が他のすべてのシ
ステムに送信される（２１４）。

【００２７】１２５では、遠隔データ受信プログラム
が、ＭＧＤＰＣの動作とは非同期に遠隔システムからパ
フォーマンス・データを受け取る。受け取ったデータ
は、遠隔パフォーマンス・データ履歴（１４５７、１４
５８）と、ＭＧＤＰＣによるその後の処理のために遠隔
データ・ウィンドウ（１２１）とに置かれる。

【００２８】主要処理ステップ 図２は、本発明のマルチシステム目標主導パフォーマン
ス制御プログラム（ＭＧＤＰＣ）（１２６）の主要処理
ステップの論理の流れを示す流れ図である。

【００２９】ＭＧＤＰＣの主な目的は、管理されるすべ
てのシステム間でパフォーマンス目標を達成することで
ある。この目的は、中央制御を行わずに達成される。む
しろ、それぞれのシステムが管理される他のすべてのシ
ステムからパフォーマンス・データを受け取り、分散作
業負荷全体が行われる状態に関する各システムのビュー
に基づいて、目標を最も適切に達成するための資源割振
り決定を行う。ＭＧＤＰＣの第２の目的は、パフォーマ
ンス目標をローカルで達成することであり、その場合、
資源割振り決定はローカル・データと遠隔データを使用
して行われる。

【００３０】２０１では、各ユーザ・パフォーマンス目
標クラスごとにマルチシステムおよびローカル・パフォ
ーマンス・インデックスが計算される。（このパフォー
マンス・インデックスの計算については後述する。）ス
テップ２０３〜２１３により、最高２回のパスを行うこ
とができる。第１のパスは、マルチシステム・パスと呼
ばれる。このマルチシステム・パス中は、管理されるす
べてのシステム間で目標クラスがどのように実行される
かに基づいて、レシーバとドナーが選択される。ローカ
ル・パスという第２のパス中は、管理されるすべてのシ
ステム間で目標クラスがどのように実行されるかに加
え、その目標クラスがローカルでどのように実行される
かの両方に基づいて、レシーバとドナーが選択される。
ローカル・パスは、マルチシステム・パス中にアクショ
ンが一切行われない場合にのみ行われる。２０２では、
マルチシステム・パスが現在、処理されていることを示
すために、ループ制御変数が設定される。２０３では、
そのパフォーマンスが改善されるように、レシーバと呼
ばれるユーザ・パフォーマンス目標クラスが選択され
る。この選択プロセスについては、図３に詳しく示し、
後述する。２０４では、対処すべき隘路として、レシー
バの資源隘路の１つが選択される。隘路選択について
は、図５に詳しく示し、後述する。２０５では、レシー
バのパフォーマンスの改善に必要なものとして識別され
た資源を所有するユーザ・パフォーマンス目標クラスが
選択される。このように選択されたユーザ・パフォーマ
ンス目標クラスはドナーと呼ばれる。ドナーはレシーバ
とは逆の順序で選択される。すなわち、最適パフォーマ
ンス・インデックスと最低重要性を有するユーザ・目標
クラスが選択される。ドナー選択については、図６に詳
しく示し、後述する。

【００３１】２０６では、ドナーからレシーバへの資源
再割振りの影響が見積られる。資源再割振りの影響を見
積るのに使用するアルゴリズムは、関係する資源に応じ
て決まる。ＣＰＵ遅延とキャップ遅延に対処するための
ＣＰＵアルゴリズムについては、本明細書で後述する。
２０７では、ドナー（複数も可）からレシーバへの資源
の再割振りの正味値が査定される。資源再割振りにとっ
て正の正味値になるように見積られる場合は、特定のド
ナーからの資源を再割振りすることにより、レシーバの
み改善される。レシーバを改善するためのドナーの使用
が見積られ、結果的に、目標および重要性に関してレシ
ーバの改善以上にドナーに及ぼす害の方が大きくなる場
合には、資源再割振りは行われない。正味値の査定につ
いては、図８に詳しく示し、後述する。

【００３２】再割振りにとって正の正味値がある場合
は、２０８でドナー（複数も可）からレシーバに資源が
再割振りされる。正の正味値がない場合は、別の潜在的
ドナーが存在するかどうかを判定するために、２０９で
検査が行われる。

【００３３】別の潜在的ドナーが存在する場合は、別の
潜在的ドナーを選択するために制御が２０５に渡され
る。選択された隘路に対処するのに必要な資源の潜在的
ドナーがそれ以上存在しない場合は、レシーバが別の隘
路を持っているかどうかを判定するために、２１０で検
査が行われる。

【００３４】レシーバが対処可能な別の隘路を持ってい
る場合は、別の隘路を選択するために制御が２０４に戻
される。レシーバが対処すべき隘路をそれ以上持ってい
ない場合は、別の潜在的レシーバが存在するかどうかを
判定するために、２１１で検査が行われる。

【００３５】別の潜在的レシーバが存在する場合は、別
の潜在的レシーバを選択するために制御が２０３に戻さ
れる。潜在的レシーバがそれ以上存在しない場合は、現
行パスがマルチシステム・パスであることをループ制御
変数が示しているかどうかを確認するために、２１２で
検査が行われる。現行パスがマルチシステム・パスであ
る場合は、現行パスがローカル・パスであることを示す
ように２１３でローカル制御変数が設定され、別の潜在
的レシーバを選択するために制御が２０３に戻される。

【００３６】ローカル・パスがすでに行われた場合は、
管理される各遠隔システムにパフォーマンス・データを
送信するために、制御が２１４に渡される。２１５で
は、データ履歴がロールされる（次の項に示すデータ履
歴の説明を参照）。

【００３７】タイマが次に満了すると、ＭＧＤＰＣ機能
がもう一度呼び出され、前に行われた資源再割振りの影
響に関するフィードバックを行うとともに、パフォーマ
ンス問題に対処する機会をもう一度提供する。

【００３８】データ履歴 データ履歴とは、時間に関するデータを収集して分析す
るための機構である。データ履歴を使用することによ
り、ＭＧＤＰＣは、時代遅れになっている恐れがあるほ
ど古いデータを使用せずに、代表となるべき十分なサン
プルを有するデータを使用することができる。図１９
は、データ履歴の一例を示している。データ履歴は、６
行のデータ（１９０３）とロール・カウンタ（１９０
１）を含んでいる。各行は、所定の範囲の履歴時間から
のデータを表している。行１は、最新期間のみのデータ
を含む。行２〜６は、各種範囲の古いデータを含む。ロ
ール・カウンタは、任意の時間範囲からそれより前の時
間範囲まで１行分のデータをロールすべき時期を制御す
る。ロール・カウンタはそれぞれのＭＧＤＰＣ間隔ごと
に増分される。各行には、その行のデータを「ロール」
すべき時期を指定するロール・カウンタ値に対応する数
値（１９０２）が関連づけられている。行１の行カウン
タ値は１であり、すべての間隔ごとに行１がロールされ
ることを意味する。行２の間隔数は２であり、間隔２つ
分ごとに行２がロールされる。行３のロール・カウンタ
値は４であり、行４のロール・カウンタ値は１６であ
り、行５のロール・カウンタ値は６４であり、行６のロ
ール・カウンタ値は６４である。

【００３９】データは次のように履歴に追加される。行
１に新しいデータが追加される。各ＭＧＤＰＣ間隔の終
わりに、現行ロール・カウンタ値に均等に分かれるロー
ル・カウンタ値を有する最高行が検出される。次に数値
が大きい行にその行の内容が追加される。それより数値
が小さいすべての行の内容が１行ずつ上に上がり、行１
が空のままになる。行６からのデータをロールする時期
になると、そのデータが破棄される。データ履歴からデ
ータを獲得するには、行１〜ｎのデータをすべて加え
る。ｎの値は、使用するデータが代表となる十分なサン
プルを有する十分長い間隔にわたって収集されるように
選択する。行数の選択については、本明細書のパフォー
マンス・インデックスの項を参照されたい。

【００４０】応答時間目標を備えたそれぞれの目標クラ
スは、その目標クラスについて遠隔システムから受け取
ったパフォーマンス・データを含む、ローカルおよび遠
隔応答時間データ履歴（１４５７）を有する。この履歴
の各行は、２８項目を含む配列である。図２０は、この
配列のレイアウトを示している。この配列の各項目は、
目標の所与の割合（％）の範囲内の応答時間を有する完
了回数を含む。第１の項目は、目標の半分より少ない応
答時間を有する完了のカウントを含む。第２の項目は、
目標の半分以上であるが０．５７５倍未満である応答時
間を有する完了のカウントを含む。

【００４１】速度目標を備えたそれぞれの目標クラス
は、ローカルおよび遠隔速度サンプル・データ履歴（１
４５８）を有する。この履歴の各行は、２つの項目を含
む配列である。第１の項目は、目標クラスの作業が実行
中としてサンプリングされた回数のカウントを含む。第
２の項目は、目標クラスの作業が実行中または遅延済み
（非アイドル）としてサンプリングされた回数のカウン
トである。

【００４２】パフォーマンス・インデックス パフォーマンス・インデックスが１．０の場合は、ユー
ザ・パフォーマンス目標クラスがその目標を正確に達成
していることを示す。パフォーマンス・インデックスが
１より大きい場合は、そのクラスのパフォーマンスがそ
の目標より悪いことを示し、パフォーマンス・インデッ
クスが１．０未満の場合は、そのクラスのパフォーマン
スがその目標より良いことを示す。マルチシステム・パ
フォーマンス・インデックスは、管理されるすべてのシ
ステム間でユーザ・パフォーマンス目標クラスがどのよ
うに実施しているかを示す。ローカル・パフォーマンス
・インデックスは、ローカル・システムでユーザ・パフ
ォーマンス目標クラスがどのように実施しているかを示
す。

【００４３】実行速度パフォーマンス・インデックス 実行速度目標（１４１１）のパフォーマンス・インデッ
クスは次のように計算される（１４１５）。 （実行速度目標）／（実際の実行速度）

【００４４】実行速度は、ユーザ目標パフォーマンス・
クラスの作業が実行中の時間をその作業が実行中または
遅延済みの時間で割って、パーセントで表したものであ
る。パフォーマンス・インデックスは、実行速度目標を
備えた作業の実際の実行速度で割った目標と、応答時間
目標を備えた作業の応答時間目標で割った実際の応答時
間である。

【００４５】実行速度目標の場合、ローカル・サンプル
履歴（１２５）からローカル実行速度が計算される。ロ
ーカル・サンプル履歴（１２５）の各行は配列であり、
その第１の項目は、目標クラスの作業単位が実行中とし
てサンプリングされた回数のカウントであり、残りの項
目は、目標クラスの作業単位が本発明により対処される
８つの遅延状態のそれぞれについて遅延済みとしてサン
プリングされた回数のカウントになっている。サンプリ
ングされる遅延状態は、ＣＰＵ遅延、ＭＰＬ遅延、スワ
ップ遅延、専用領域補助記憶装置ページング遅延、共通
領域補助記憶装置ページング遅延、クロスメモリ・ペー
ジング遅延、仮想入出力（ＶＩＯ）補助記憶装置遅延、
ハイパー空間^TM補助記憶装置ページング遅延である。こ
れらの遅延をサンプリングする技法は当技術分野では周
知のものである。

【００４６】ローカル・サンプル履歴（１２５）からデ
ータを取る場合、少なくとも５００個の非アイドル・サ
ンプルを含めるために十分な行が合計される。履歴の最
初の２行はいつも使用される。履歴行を合計する場合、
最新データにより大きい重みを付けるために、最初の行
を２倍にする。現行速度を計算するため、結合行からの
サンプルを使用するＣＰＵを結合行の合計サンプルで割
る。このローカル速度をクラスの目標に分割し、ローカ
ル・パフォーマンス・インデックスを計算する。

【００４７】応答時間パフォーマンス・インデックス 応答時間目標（１４１０）のパフォーマンス・インデッ
クスは次のように計算される（１４１５）。 （実際の応答時間）／（応答時間目標）

【００４８】応答時間目標の場合、ローカル応答時間履
歴（１４２６）からのデータからローカル・パフォーマ
ンス・インデックスが計算される。図２０は、ローカル
応答時間履歴（１４２６）の１行を示している。２０秒
以下の応答目標を有する目標クラスの場合、少なくとも
１００回の完了を含めるために、ローカル応答時間デー
タ履歴の十分な行が合計される。それより長い応答時間
目標を有する目標クラスの場合、少なくとも１０回の完
了を含めるために、十分な行が合計される。履歴のうち
少なくとも最初の２行はいつも使用される。行を合計す
る場合、最新情報により大きい重みを付けるため、最初
の行の値を２倍にする。次に、作動中の各作業単位ごと
に次のように応答時間が見積られる。 １．問題の作業単位がこれまでに使用したサービス時間
より多くのサービス時間で完了した同一目標クラスに割
り当てられた作業単位によって使用された平均サービス
量を求める。 ２．その作業単位がこれまでに使用したサービス時間量
をこの平均から引いて、その作業単位が今後使用する追
加のサービス時間量の見積りを得る。 ３．作業単位がサービス時間を蓄積する速度で追加サー
ビス時間の見積りを割って、作業単位が完了するまでの
時間の見積りを得る。 ４．作業単位がすでに実行した時間の長さに作業単位が
完了するまでの時間の見積りを加算し、作業単位応答時
間の見積りを得る。

【００４９】ローカル応答時間履歴から構築した行の適
切な項目に、作動中の作業単位の各完了見積りが加えら
れる。この結合行からローカル平均応答時間が計算さ
れ、この平均応答時間を目標で割って、ローカル・パフ
ォーマンス・インデックスを計算する。

【００５０】マルチシステム・パフォーマンス・インデックス 各目標クラスごとにマルチシステム・パフォーマンス・
インデックスを計算するために以下のステップが行われ
るが、このステップについては図２２に示す。２２０１
では、変数Ｃが第１の目標クラスに設定される。２２０
２では、その目標クラスが応答時間目標を有するかどう
かを判定するためにＣがテストされる。Ｃが応答時間目
標を有する場合は、制御が２２０３に渡され、そこで遠
隔応答時間データ履歴からデータが取られる。遠隔応答
時間データ履歴からこのデータを取る場合、ローカル・
パフォーマンス・インデックスの計算に使用したデータ
と同じ量の時間を表すために、履歴の十分な行が使用さ
れる。遠隔応答時間データ履歴から返された応答時間デ
ータは履歴の１行分の形式になっている（図１９を参
照）。管理されるすべてのシステムを表すデータを得る
ために、ローカル・パフォーマンス・インデックスの計
算に使用したローカル応答時間データを２２０４で遠隔
データに加える。この結合応答時間データから平均応答
時間が計算され、この平均を使用して２２０５でマルチ
システム・パフォーマンス・インデックスを計算する。

【００５１】Ｃによって指定された目標クラスが実行速
度目標を有する場合は、制御が２２０６に渡され、そこ
で遠隔速度履歴からデータが取られる。遠隔速度履歴か
らこのデータを取る場合、ローカル・パフォーマンス・
インデックスを計算する際にローカル・サンプル履歴か
ら取られたのと同じ数の行が使用される。ローカル速度
の計算に使用したローカルＣＰＵが使用するサンプルを
結合行の第１の項目に加え、ローカル速度の計算に使用
した遅延状態カウントの合計を結合行の第２の項目に加
えることにより、２２０７でこの遠隔データにローカル
実行速度データを加える。このマルチシステム実行速度
データからマルチシステム速度が計算され、２２０８で
マルチシステム速度からマルチシステム・パフォーマン
ス・インデックスが計算される。

【００５２】処理すべき目標クラスがそれ以上存在する
場合は（２２０９）、制御が２２１０に渡され、そこで
Ｃが次の目標クラスに設定される。次に、次の目標クラ
スを処理するために制御が２２０２に戻される。

【００５３】パフォーマンス・データの送信 マルチシステム目標主導パフォーマンス制御プログラム
間隔の終わりに、その間隔中の各目標クラスのパフォー
マンスを記述するデータ・レコードが管理される各遠隔
システムに送られる。それぞれの資源グループごとのプ
ロセッサ資源消費データは、パフォーマンス・データの
送信と同時に各遠隔システムに送られる。プロセッサ資
源消費データについては、図１８に示し、後述する。図
２３は、各遠隔システムに送られるパフォーマンス・デ
ータを示している。応答時間目標を有するパフォーマン
ス目標クラスの場合、このデータ・レコードは、目標ク
ラス名（２３０１）と、最後のＭＧＤＰＣ間隔でのその
目標クラスの完了を記述する遠隔応答時間データ履歴の
１行分に相当する２８個の項目を有する配列（２３０
２）とを含む。速度目標を有する目標クラスの場合、こ
のデータ・レコードは、目標クラス名（２３０３）と、
最後のＭＧＤＰＣ間隔で目標クラスの作業が実行中とし
てサンプリングされた回数のカウントと、最後のＭＧＤ
ＰＣ間隔で目標クラスの作業が実行中または遅延済みと
してサンプリングされた回数のカウント（２３０４）と
を含む。

【００５４】遠隔データ受信プログラム 図２１は、遠隔目標クラス・パフォーマンス・データを
受け取るための論理の流れを示す流れ図である。２１０
１では、まったく同じ組の目標クラスとパフォーマンス
目標で実行中のシステムからのものであることを確認す
るために、着信データ・レコードが検査される。この検
査に不合格である場合、そのデータ・レコードは無視さ
れる（２１０２）。２１０３では、着信データ・レコー
ドが表す目標クラスと同じ名前の目標クラスを見つける
ために、パフォーマンス目標クラス・テーブルが探索さ
れる。この探索によって見つかった目標クラスが応答時
間目標を有する場合は（２１０４）、目標クラスの遠隔
応答時間データ履歴に着信データ・レコードの応答時間
データが加えられ（２１０５）、応答時間目標を有して
いない場合は、目標クラスの遠隔速度データ履歴に着信
レコードの速度データが加えられる（２１０６）。

【００５５】データ履歴を使用して遠隔パフォーマンス
・データを管理することにより、管理されるシステムは
独立して動作することができる。１つのＭＧＤＰＣ間隔
中に遠隔システムからのデータが到着しない場合は、必
要であれば、代表となる十分なサンプルを備えたデータ
が使用されることを保証するために古いデータを使用す
ることによって、データ履歴機構が補正することにな
る。また、管理される遠隔システムのうちの１つが故障
した場合は、１つのシステムが故障したことを残りのシ
ステムに具体的に通知する必要なく、そのデータがデー
タ履歴から消される。

【００５６】遠隔データ受信プログラム手段（１２５）
は、Eilert発明に開示されている。この遠隔データ受信
プログラム手段は、システム資源マネージャ（１２３）
の構成要素であって、それぞれのシステム上で動作し、
遠隔システムから同報されたデータを受け取り（図２
３）、ローカル・システム上で使用するためにそのデー
タを制御ブロックに格納するものである。本発明の遠隔
データ受信プログラムは、遠隔システムによって同報さ
れた資源グループ・プロセッサ消費データをさらに受け
取り、そのデータ（図１８）を資源グループ・テーブル
項目（図１５）の現行ウィンドウ面に格納するように変
更されている。受け取ったデータ・レコードは、資源グ
ループ名（１８００）と、それぞれの重要性ごとのプロ
セッサ消費（１８０１）と、システムがそれぞれの重要
性の作業を有するかどうかを示す標識（１８０２）とか
ら構成される。適切な資源グループ・テーブル項目は、
受け取ったデータに関連する資源グループ名（１８０
０）から判定される。現行ウィンドウ面インデックス
（１５０３）は、到着したデータを格納するためにウィ
ンドウ配列（１２１）のうちのどの要素を使用すべきか
を指定する。遠隔プロセッサ資源消費データは、ＭＧＤ
ＰＣ（１２６）のキャッピング調整手段（１２８）によ
って使用される。

【００５７】データ・ウィンドウを使用して遠隔パフォ
ーマンス・データを管理することにより、管理されるシ
ステムは独立して動作することができる。１つのＭＧＤ
ＰＣ間隔中に遠隔システムからのデータが到着しない場
合は、必要であれば、代表となる十分なサンプルを備え
たデータが使用されることを保証するために古いデータ
を使用することによって、データ・ウィンドウ機構が補
正することになる。また、管理される遠隔システムのう
ちの１つが故障した場合は、１つのシステムが故障した
ことを残りのシステムに具体的に通知する必要なく、そ
のデータがデータ・ウィンドウから消されるる。

【００５８】改善するレシーバの選択 図３は、パフォーマンス目標を選択してパフォーマンス
の重要性を受け取るためにレシーバ選択手段（１４１
６）が使用する論理の流れを示す流れ図である。３０１
では、任意の項目が関連づけられた重要性値を有するか
どうかを判定するためにパフォーマンス目標クラス・テ
ーブルが探索される。パフォーマンス目標を指定する場
合、重要性値は任意選択である。いずれの目標クラスに
ついても重要性値が指定されていない場合は、現行パス
がマルチシステム・パスかまたはローカル・パスかを判
定するために３０２でＭＧＤＰＣパスがテストされる。
現行パスがマルチシステム・パスである場合は、最悪
（最高）のマルチシステム・パフォーマンス・インデッ
クスを有する目標クラスが選択される（３０３）。現行
パスがローカル・パスである場合は、最悪のローカル・
パフォーマンス・インデックスを有する目標クラスが選
択される（３０４）。

【００５９】重要性値が指定されている場合は、考慮す
べき重要性値を、任意のパフォーマンス目標クラスに指
定した最高の重要性値に初期設定する（３０５）。３０
６では、このような目標クラスのいずれかがその目標を
達成していないかどうかを判定するために、重要性を考
慮して目標クラスの設定が検査される。目標不達成の定
義は、実行されるＭＧＤＰＣパスによって決まる。ＭＧ
ＤＰＣパスがマルチシステム・パスである場合は、その
マルチシステム・パフォーマンス・インデックスが１よ
り大きければ、目標クラスはその目標を達成していない
と見なされる。ＭＧＤＰＣパスがローカル・パスである
場合は、そのマルチシステムまたはローカルのいずれか
のパフォーマンス・インデックスが１より大きければ、
目標クラスはその目標を達成していないと見なされる。
考慮中の重要性レベルの目標クラスで、その目標を達成
していないものがある場合は、ＭＧＤＰＣパスに基づい
て目標クラスが選択される（３０７）。すなわち、パス
がマルチシステム・パスである場合は、最悪のマルチシ
ステム・パフォーマンス・インデックスを備えた目標ク
ラスが選択され（３０８）、パスがローカル・パスであ
る場合は、最悪のローカル・パフォーマンス・インデッ
クスを備えた目標クラスが選択される（３０９）。

【００６０】考慮中の重要性レベルのいずれの目標クラ
スもその目標を達成している場合であって、しかもそれ
より低い別の重要性値が指定されている場合は（３１
０）、指定されている次に低い重要性値が考慮の対照と
して設定され（３１１）、制御は３０６に戻される。い
ずれの重要性レベルの目標クラスもその目標を達成して
いる場合は、ＭＧＤＰＣパスに基づいて最悪のパフォー
マンス・インデックスを備えた目標クラスを選択するた
めに、制御が３０２に渡される。

【００６１】隘路の検出 図４は、対処すべき資源隘路の選択（１４１７）に使用
する状態データを示している。それぞれの遅延タイプご
とに、パフォーマンス目標クラス・テーブル項目は、そ
の遅延タイプを検出したサンプル数と、マルチシステム
目標主導パフォーマンス制御プログラムの現行呼出し中
に隘路としてその遅延タイプがすでに選択されているか
どうかを示すフラグとを含む。

【００６２】隘路検出手段の論理の流れは図５に示す。
対処すべき隘路の選択は、マルチシステム目標主導パフ
ォーマンス制御プログラムの現行呼出し中にすでに選択
されていない、最大数のサンプル数を有する遅延タイプ
を選択することによって行われる。遅延タイプを選択す
ると、マルチシステム目標主導パフォーマンス制御プロ
グラムのこの呼出し中に隘路検出手段が再呼出しされた
場合にその遅延タイプがスキップされるように、フラグ
が設定される。

【００６３】ＭＧＤＰＣ（１２６）の制御調整手段（１
２７）の隘路検出手段は、プロセッサ遅延サンプル（５
０１）に新しいキャップ遅延サンプルを加え、対処すべ
き次に大きい隘路がプロセッサ・アクセスであるかどう
かを判定するためにキャップ遅延サンプルとプロセッサ
遅延サンプルの合計を使用するように、変更されてい
る。この変更により、ディスパッチ優先順位を上げるこ
とによりプロセッサ遅延とキャップ遅延の両方を調整で
きるようなＭＧＤＰＣの新しい結果が得られる。

【００６４】図５の５０１では、ＣＰＵ遅延タイプ・サ
ンプルとキャップ遅延タイプ・サンプルの合計が、まだ
選択されていないすべての遅延タイプのうちの最大数の
遅延サンプルを有するかどうかを判定するために、検査
が行われる。ＹＥＳの場合は、５０２でＣＰＵ遅延選択
済みフラグが設定され、対処すべき次の隘路としてＣＰ
Ｕ遅延が返される。５０３では、別の遅延タイプ、たと
えば、タイプＸ遅延タイプが、まだ選択されていないす
べての遅延タイプのうちの最大数の遅延サンプルを有す
るかどうかを判定するために、検査が行われる。ＹＥＳ
の場合は、５０４でタイプＸ遅延選択済みフラグが設定
され、対処すべき次の隘路としてタイプＸ遅延が返され
る。５０５では、第３の遅延タイプ、たとえば、タイプ
Ｙ遅延タイプが、まだ選択されていないすべての遅延タ
イプのうちの最大数の遅延サンプルを有するかどうかを
判定するために、検査が行われる。ＹＥＳの場合は、５
０６でタイプＹ遅延選択済みフラグが設定され、対処す
べき次の隘路としてタイプＹ遅延が返される。当業者
は、上記と同じように隘路を検出するために、サンプリ
ングした各種遅延タイプをいくつでも使用できることが
分かるであろう。

【００６５】遅延の修正 この項では、隘路検出手段が選択した遅延を低減するた
めに被制御変数またはパラメータを変更することにより
レシーバのパフォーマンス目標クラス・パフォーマンス
を改善する方法について具体的に説明する。

【００６６】一般的修正の流れ 図７は、選択した資源隘路に関連する被制御変数を変更
することによるレシーバ目標クラス・パフォーマンスの
改善を査定するために、修正手段（１４１８）が必要と
する諸ステップを示している。７０１では、被制御変数
用として新しい値が選択される。７０２では、レシーバ
・パフォーマンス目標クラス用として、マルチシステム
およびローカル・パフォーマンス・インデックスの変更
が計算される。この計算の詳細は、個々の資源に固有で
あり、あとで説明する。７０３では、その変更の結果、
レシーバにとって十分な値になっているかどうかを判定
するために、パフォーマンス・インデックスの改善が検
査される。十分なレシーバ値になっていない場合は、制
御が７０１に戻され、そこで、レシーバにとってより多
くの恩恵が得られるような値が被制御変数用に選択され
る。

【００６７】十分なレシーバ値になっているときは、制
御が７０４に渡され、そこで制御変数の変更を行うのに
必要な資源のドナーを検出するために、ドナー選択手段
（１４２３）が呼び出される。７０５では、提案変更が
正味値を有するかどうかを確認するために検査が行われ
る。その変更が正味値を有する場合は、目標および重要
性に関してレシーバにもたらされる恩恵はドナーに及ぼ
す害より大きくなければならない。提案変更が正味値を
持つ場合は、７０６で被制御変数が変更される。正味値
がない場合は、選択された資源隘路を修正することがで
きない（７０７）。

【００６８】ドナーの選択 図６は、ドナー選択手段（１４２３）の論理の流れを示
す流れ図である。ドナー選択手段の目的は、必要な資源
を所有する１組の目標クラスから、レシーバにその資源
を寄贈するのに最も適格な目標クラスを選択することで
ある。６０１では、任意の項目が関連の重要性値を持っ
ているかどうかを判定するために、パフォーマンス目標
クラス・テーブルが探索される。いずれの目標クラスも
それに関連する重要性値を持たない場合は、任意の目標
クラスが必要な資源を所有しているかどうかをドナー選
択手段が判定する（６０２）。いずれの目標クラスも必
要な資源を所有していない場合は、適格ドナーは一切存
在しない（６０３）。このような目標クラスがある場合
は、ドナー選択手段は、ＭＧＤＰＣパスに基づいて、最
良パフォーマンス・インデックスを有する目標クラスを
ドナーとして選択する（６０４〜６０７）。現行パスが
マルチシステム・パスである場合は、マルチシステム・
パフォーマンス・インデックスが使用され、そうでない
場合は、ローカル・パフォーマンス・インデックスが使
用される。

【００６９】重要性が指定された目標クラスが存在する
場合は、目標を達成する必要資源を所有する目標クラス
が存在するかどうかをドナー選択手段が判定する（６０
７）。レシーバ選択手段の場合と同様、ＭＧＤＰＣパス
がマルチシステムである場合は、そのマルチシステム・
パフォーマンス・インデックスが１以下であれば、目標
クラスはその目標を達成するものと見なされる。現行パ
スがローカル・パスである場合は、そのマルチシステム
およびローカルの両方のパフォーマンス・インデックス
が１以下であれば、目標クラスはその目標を達成するも
のと見なされる。必要な資源を所有する目標を達成する
目標クラスが存在する場合は、ＭＧＤＰＣパスに基づい
て、最良のパフォーマンス・インデックスを備えた目標
クラスを選択するために制御が６０４に渡される。それ
ぞれの指定の目標を達成する目標クラス間を区別する場
合、重要性は使用しない。

【００７０】その指定の目標を達成し、しかも必要な資
源を所有している目標クラスが一切存在しない場合は、
ドナー選択手段は、指定の最低重要性値を有し、しかも
必要な資源を所有する目標クラスを検出する（６０８〜
６１１）。このような目標クラスが存在する場合は、ド
ナー選択は、ＭＧＤＰＣパスに基づいて、最良のパフォ
ーマンス・インデックスを有する目標クラスを選択する
（６１３〜６１５）。いずれの目標クラスも必要な資源
を所有していない場合は、システム内には適格ドナーが
一切存在しない（６１２）。

【００７１】正味値の査定 図８は、レシーバとドナーとの間の企図された資源再割
振りの正味値を判定するために正味値査定手段（１４２
４）が使用する諸ステップを示している。資源ドナーが
その目標を達成するように見積られ（８０１）、レシー
バがその目標を達成していない（８０２）場合は、再割
振りが正味値を持つ（８０３）。ただし、ＭＧＤＰＣの
マルチシステム・パスでは、そのマルチシステム・パフ
ォーマンス・インデックスが１以下であれば、目標クラ
スは目標を達成していると見なされることに留意された
い。また、ＭＧＤＰＣのローカル・パスでは、そのマル
チシステムとローカル両方のパフォーマンス・インデッ
クスが１以下であれば、目標クラスは目標を達成してい
ると見なされる。

【００７２】ドナーがその目標を達成するように見積ら
れ、レシーバがその目標を達成している場合は、アクシ
ョンは正味値を持たない（８０５）。ドナーとレシーバ
の両方が目標を達成していない場合は、レシーバの方が
（重要性値が示すように）ドナーより重要であれば、再
割振りが正味値を持ち（８０７）、ドナーの方がレシー
バより重要であれば、再割振りが正味値を持たない（８
０９）。８１０では、レシーバとドナーの両方が目標を
達成しておらず、同じように重要であるか、または両方
ともその目標を達成している。この場合、それによって
マルチシステム・パフォーマンス・インデックス（Ｐ
Ｉ）の正味利得が得られれば、再割振りが正味値を持
つ。ＭＧＤＰＣのローカル・パスでは、再割振りがロー
カル・パフォーマンス・インデックスの正味利得も持っ
ていなければならない。以下の条件が両方とも該当する
場合は、資源再割振りがパフォーマンス・インデックス
の正味利得を持つ。 １．レシーバについて見積られたパフォーマンス・イン
デックス値の減少（パフォーマンスの改善）の方が、ド
ナーの見積られたパフォーマンス・インデックス値の増
加（パフォーマンスの低下）より大きい。 ２．レシーバがドナーより低いパフォーマンス・インデ
ックス値（パフォーマンスの改善）を持つように見積ら
れる場合は、レシーバのパフォーマンス・インデックス
値は、再割振り前より再割振り後の方がドナーのパフォ
ーマンス・インデックス値に近くなるように見積られな
ければならない。

【００７３】上記１の場合、レシーバの見積られたパフ
ォーマンス・インデックスの減少とドナーの見積られた
パフォーマンス・インデックスの増加とを比較すると、
レシーバは、そのパフォーマンス・インデックス値の減
少の０．９０を上回る部分についてのみ寄与すると認め
られる。同様に、ドナーは、そのパフォーマンス・イン
デックス値の増加の０．９０を上回る部分についてのみ
寄与すると認められる。たとえば、レシーバのパフォー
マンス・インデックス値が１．５０から０．７０に改善
するように見積られた場合、比較に使用するパフォーマ
ンス・インデックスの減少は０．６０になるはずであ
る。

【００７４】レシーバ値 十分なレシーバ値があるかどうかを検査することは、最
適化の１つである。十分なレシーバ値になるように見積
られている場合のみ、レシーバに役に立つ。レシーバ値
は、最小パフォーマンス・インデックス改善基準か、ま
たは最小遅延サンプル・デルタ基準のいずれかになる。
たとえば、好ましい実施例では、レシーバ値基準は、レ
シーバの現行パフォーマンス・インデックスと１．００
との差の少なくとも１０％の改善か、またはレシーバで
検出された最大遅延の遅延サンプルの少なくとも半分に
相当する遅延サンプル・デルタを必要とする。これらの
基準は、非常に小さい改善を拒否するように設計されて
いる。レシーバ値が小さすぎるアクションを拒否する理
由は、限界改善のみをもたらす変更を避けるためであ
る。

【００７５】ＣＰＵ遅延 この項では、レシーバで検出されたＣＰＵ遅延（１４２
０）を低減することによるパフォーマンスの改善につい
て説明する。

【００７６】図９は、不公正にドナーのパフォーマンス
に害を及ぼさずにレシーバのパフォーマンスを改善する
ために使用する新しい１組のディスパッチ優先順位を見
つけるための諸ステップを示している。図９〜１３は、
修正手段（１４１８）から正味値査定手段（１４２４）
に提供されるパフォーマンス・インデックス・デルタの
見積りに関連する諸ステップを示している。

【００７７】９０１では、それぞれの目標クラスごとに
最大需要および待機／使用中の比率が計算され、それぞ
れの優先順位のすべての目標クラスについて蓄積され
る。これらの計算については、本明細書で後述する。こ
れらの値のテーブルが構築されるが、各行はディスパッ
チ優先順位を表し、２つの列は、対応するディスパッチ
優先順位値ですべてのパフォーマンス目標クラスについ
て蓄積された、待機／使用中の比率および最大需要であ
る。このテーブルは、待機／使用中テーブルと呼ばれ、
後述するように新しいディスパッチ優先順について新し
い待機／使用中の値を見積るために使用する。待機／使
用中の比率（ＣＰＵ遅延サンプルをＣＰＵ使用中サンプ
ルで割ったもの）は、コンピュータ・システムのパフォ
ーマンス測定では周知の概念である。最大需要は新しい
概念である。最大需要とは、ＣＰＵ遅延がない場合に目
標クラスに関連する作業単位が消費できる全プロセッサ
時間の理論上の最大割合（％）である。最大需要の計算
については、本明細書で後述する。

【００７８】ステップ９０２〜９０９は、上方移動と下
方移動の組合せによって十分なレシーバ値または不十分
な正味値が得られるまで、レシーバのディスパッチ優先
順位を上げた結果（レシーバの上方移動）とドナーのデ
ィスパッチ優先順位を下げた結果（ドナーの下方移動）
を交互に査定するプロセスを示している。１回の移動の
影響を見積るためのステップ９０３および９１２は図１
０に示す。また、正味値の検査は図８に示す。いずれか
の正味値検査で不合格になった場合は、移動の組合せで
正味値検査に合格するかどうかを判定するために、レシ
ーバとともに上方移動させるか、またはドナーとともに
下方移動させる２次ドナーおよびレシーバが選択され
る。

【００７９】移動の組合せで正味値検査に合格した場合
は、２次レシーバおよびドナーを１次レシーバおよびド
ナーとともに移動させる。２次ドナーおよびレシーバは
ドナー選択手段とレシーバ選択手段では検出されない。
むしろ、２次レシーバは、１）１次レシーバのディスパ
ッチ優先順位より低いディスパッチ優先順位を有し、
２）正味値検査に不合格だった、パフォーマンス目標ク
ラスとして定義されている。同様に、２次ドナーは、
１）１次ドナーのディスパッチ優先順位より高いディス
パッチ優先順位を有し、２）正味値検査に不合格だっ
た、パフォーマンス目標クラスである。

【００８０】最大需要の計算 最大需要は次のように計算される。

【００８１】最大需要とは、ＣＰＵ遅延がない場合に目
標クラスが消費できる全プロセッサ時間の理論上の最大
割合（％）である。

【００８２】優先順位変更の査定 図１０は、ディスパッチ優先順位の変更の影響を見積る
ための諸ステップを示している。１００１では、そのデ
ィスパッチ優先順位が変更されるパフォーマンス目標ク
ラスの最大需要が、その「変更前」（現行）優先順位で
の最大需要から引かれ、その「変更後」（提案された新
しい）優先順位での最大需要に加えられる。１００２で
は、各クラスごとの達成可能需要割合（％）をグラフか
ら読み取り、次にその達成可能需要割合（％）にシステ
ム内で使用可能な全時間を掛けることにより、ディスパ
ッチ優先順位変更による影響を受けた各クラスが使用す
るように見積られるＣＰＵ時間が見積られる。１００３
では待機／使用中の新しい比率が見積られ、１００４で
はＣＰＵ使用中と遅延のサンプル・デルタが計算され、
１００５ではディスパッチ優先順位の変更の影響を受け
た各パフォーマンス目標クラスごとにパフォーマンス・
インデックス・デルタが計算される。

【００８３】達成可能需要グラフ 図１１は、達成可能需要グラフを示している。横座標値
は、任意のディスパッチ優先順位で使用可能な最大需要
をそのディスパッチ優先順位での全最大需要で割った商
である。任意のディスパッチ優先順位で使用可能な最大
需要は、問題のパフォーマンス目標クラスのディスパッ
チ優先順位より上のすべてのディスパッチ優先順位での
累積最大需要を１００から引いたものである。任意のデ
ィスパッチ優先順位で使用可能な最大需要は、この計算
ではゼロより小さくなることはない。任意のディスパッ
チ優先順位での最大需要は、そのディスパッチ優先順位
でのすべてのクラスの全最大需要である。

【００８４】達成可能需要グラフの縦座標値は、達成可
能需要割合（％）である。達成可能需要割合は、それよ
り高いディスパッチ優先順位のすべての作業の最大需要
と、同一優先順位のすべての作業の最大需要が与えられ
ている場合に、消費するようにあるクラスが見積られて
いるそのクラスの最大需要の割合（％）である。

【００８５】使用するＣＰＵ時間を見積るため、達成可
能需要グラフから任意のクラスの達成可能需要割合が読
み取られる。この達成可能需要割合を使用して、プロセ
ッサ時間消費を見積る。ＣＰＵ時間消費は、達成可能最
大需要にそのクラスの最大需要を掛け、全ＣＰＵ時間を
掛けることによって計算される。

【００８６】達成可能需要グラフは、このグラフ用のす
べての値がハード・コード化されているという点によ
り、本発明で使用する他のグラフとは異なっている。他
のすべてのグラフには、実行中のシステムからの実デー
タの所見を使用する。達成可能需要グラフの値は、モデ
リングにより得られたものである。

【００８７】ＣＰＵの待機／使用中の比率 図１２は、前述のように構築した待機／使用中テーブル
を使用して新しい待機／使用中の比率を計算する方法を
示している。新しい遅延サンプル・デルタを計算するに
は、実際の待機／使用中の比率と見積られた待機／使用
中の比率を使用する。

【００８８】１２０１では、関心のあるディスパッチ優
先順位の見積られた累積最大需要より上および下の最も
近い累積最大での待機／使用中の比率を待機／使用中テ
ーブルで見つける。新しい累積最大需要に正確に一致す
るものがテーブルで見つからない場合（１２０２で検
査）は、上および下の最大需要での待機／使用中の比率
を補間して、使用する新しい待機／使用中の比率を求め
る（１２０３）。正確に一致するものが見つかった場合
は、その待機／使用中の比率が使用される。

【００８９】関心のあるディスパッチ優先順位より上の
１００％累積最大需要より大きくなるように見積られて
いる場合（１２０４）であって、１００％累積最大需要
より小さかった場合（１２０５）は、そのディスパッチ
優先順位で消費されているはずの最大需要と、消費する
ように見積られている最大需要との比率の１／２だけ、
待機／使用中の比率が膨張する（１２０６）。

【００９０】関心のあるディスパッチ優先順位より上の
１００％累積最大需要より大きくなるように見積られて
いない場合（１２０４）であって、この累積最大需要が
現行ディスパッチ優先順位用になるように見積られたも
のより悪い場合（１２０７）は、その提案されたディス
パッチ優先順位で消費されているはずの最大需要と、消
費するように見積られている最大需要との比率の１／２
だけ、待機／使用中の比率が膨張する（１２０８）。

【００９１】関心のあるディスパッチ優先順位より上の
１００％累積最大需要より大きくなるように見積られて
いない場合（１２０４）であって、この累積最大需要が
以前より悪くなっておらず（１２０７）、しかも上記の
１００％累積最大需要より小さかった場合（１２１０）
は、その優先順位で消費されるはずの最大需要と、消費
するように見積られている最大需要との比率だけ、待機
／使用中の比率が縮小する（１２１１）。

【００９２】関心のあるディスパッチ優先順位より上の
１００％累積最大需要より大きくなるように見積られて
いない場合（１２０４）であって、この需要が現行ディ
スパッチ優先順位用のものより悪くなっておらず（１２
０７）、しかも上記の１００％累積最大需要より小さく
なかった場合（１２１０）は、２で割ることによって待
機／使用中の比率が縮小する（１２１３）。

【００９３】すべての膨張ケースでは、膨張した値が次
に低い優先順位での実際の待機／使用中の比率より大き
い場合、待機／使用中の比率は、次に低い優先順位での
待機／使用中の比率に指定変更される。縮小した値が次
に高い優先順位での実際の待機／使用中の比率より小さ
い場合、待機／使用中の比率は、次に高い優先順位での
待機／使用中の比率に指定変更される。

【００９４】前述の待機／使用中テーブルから得られた
待機／使用中の比率は、個々のパフォーマンス目標クラ
スごとに次のようにさらに調整される。 待機／使用中比率（調整後）＝待機／使用中比率（テー
ブルからの値）×（Ａ／Ｂ） ただし、 Ａ＝その優先順位でのサービスで重みを付けた平均待機
間隔 Ｂ＝個々のパフォーマンス目標クラスの平均待機間隔

【００９５】ＣＰＵ使用中のサンプル・デルタ 図１３は、ＣＰＵ使用中のサンプル・デルタを計算する
ための論理の流れを示している。パフォーマンス目標ク
ラスについてＣＰＵ時間が蓄積された場合（１３０１で
検査）、見積られるＣＰＵ使用中サンプルは、実際のＣ
ＰＵ使用中サンプルに見積られるＣＰＵ時間を掛け、実
際のＣＰＵ時間で割ったものに等しくなるように設定さ
れる（１３０３）。パフォーマンス目標クラスについて
ＣＰＵ時間が蓄積されていなかった場合、見積られる使
用中サンプルは、見積られるＣＰＵ時間をサンプル当た
りのＣＰＵ時間で割ったものに等しくなるように設定さ
れる（１３０２）。使用中サンプル・デルタは、見積ら
れるサンプルから実際のサンプルを引いたものである。

【００９６】ＣＰＵ遅延サンプル・デルタ ＣＰＵ遅延サンプル・デルタは、次のように計算され
る。

【００９７】見積られる遅延サンプル数は、実際に観察
された遅延サンプル数に見積られる待機／使用中の比率
を掛け、実際の待機／使用中の比率で割ったものに等し
くなる。遅延サンプル・デルタは、見積られるサンプル
数から実際のサンプル数を引いたものである。

【００９８】ＣＰＵパフォーマンス・インデックス・デルタ パフォーマンス・インデックス・デルタは、以下に示す
ようにディスパッチ優先順位の変更について計算され
る。ただし、ＣＰＵ使用中と遅延のサンプル・デルタは
符号付き数字なので、これらの式はレシーバ用とドナー
用の両方の道筋をたどることに留意されたい。また、上
記で計算したサンプル・デルタはローカル・システム用
であることに留意されたい。

【００９９】

【０１００】キャップ・ビット操作プログラム キャップ・ビット操作プログラム（１３０）の動作は、
システム資源マネージャ（１２３）の周知の時間スライ
ス機能と同様である。所定の長さの時間（この長さはプ
ロセッサ速度による）をいくつかの間隔、好ましい実施
例では６４個の間隔に分割する。６４個の間隔のそれぞ
れに対応する標識は、その間隔中に資源グループをキャ
ッピングする必要があるかどうかを示す。これらの標識
は、キャップ・スライス・パターン（１２２）を形成
し、ＭＧＤＰＣ（１２６）のキャッピング調整手段（１
２８）によって設定される。キャップ・ビット操作プロ
グラム（１３０）が呼び出されると、このプログラム
は、どの資源グループをキャッピングすべきかを検査
し、それに応じて作業単位のＡＳＣＢ（１０４）にキャ
ップ・ビット（１０５）を設定する。

【０１０１】資源グループ・データ 図１５は、資源グループ内の作業単位をキャッピングす
べき時間量を決定するために使用する資源グループ・テ
ーブル項目データを示している。資源グループ名は１１
８に格納されている。この名前を使用して、遠隔システ
ムから送信されたプロセッサ資源消費データを相関さ
せ、ユーザ・パフォーマンス目標クラスを資源グループ
に関連づける。目標クラスが属している資源グループ用
の資源グループ名は、ユーザ・パフォーマンス目標クラ
ス・テーブル項目に格納されている。その資源グループ
用に指定されたプロセッサ消費最大値（１０７）は１１
９に格納されている。資源グループ内のすべての作業単
位が消費する全プロセッサ・サービス単位は、この最大
値を超えてはならない。これは、ローカル・システムと
すべての遠隔システム（１００−Ａ、１００−Ｂ、１０
０−Ｃ）で実行されるすべての作業単位の合計である。
資源グループ最大値は複数のシステムに及ぶ。資源グル
ープ名とプロセッサ資源消費最大値は入力値である。

【０１０２】計算に使用するグループ・プロセッサ消費
（１２０）とキャップ・スライス・データ（１２２）
は、移動時間ウィンドウにわたって保持される。この移
動時間ウィンドウは最新の６０秒として定義されてい
る。この６０秒のウィンドウは、６つのウィンドウ面と
呼ばれる１０秒ずつの６つの間隔に分割され、各ウィン
ドウごとに６要素の配列として実現される。好ましい実
施例では、３つのデータ・ウィンドウがあり、１つはロ
ーカル・システム上で消費されるプロセッサ・サービス
用（１２０）であり、２つ目はすべての遠隔システムの
合計で消費されるプロセッサ・サービス用（１２１）で
あり、３つ目のウィンドウはローカル・システム上のキ
ャップ・スライス用（１２２）である。

【０１０３】現行の１０秒の間隔用のデータは、現行ウ
ィンドウ面インデックス（１５０３）でインデックスが
付けられたウィンドウ面配列要素に格納される。それぞ
れのウィンドウ配列は、６つのウィンドウ面配列要素を
有する。この６つの配列要素は順に使用する。６番目の
要素の使用後、次の時間間隔用のデータは最初の要素に
格納され、すでに最初の配列要素に入っていた古いデー
タに置き換わる。計算に使用するデータは、ウィンドウ
のすべてのウィンドウ面のデータ、すなわち、６つの間
隔分のデータの合計である。

【０１０４】資源グループ用の現行ウィンドウ面インデ
ックス（１５０３）は、グループ・テーブル項目に格納
される。プロセッサ・サービス単位データ（１２０）
は、１つのウィンドウ分の時間、好ましい実施例では６
つの１０秒間隔にわたって保持される。現行ウィンドウ
面インデックス（１５０３）は、現行データにどのウィ
ンドウ面を使用すべきかを示す。いくつかの間隔（好ま
しい実施例では６つの１０秒間隔）にわたってデータが
保持されることは、本発明の重要な特徴の１つである。
この特徴により、データが平滑になり、管理されるシス
テム間で同期を取る必要がなくなる。このウィンドウ
は、遠隔データが遅れたり順不同になっても特殊な処理
やエラー処理を必要としないように十分な時間をカバー
している。遅れたデータは、到着したときにウィンドウ
・データに追加されるだけである。システムが故障し、
データの到着が停止した場合は、そのシステム用のデー
タが含まれなくなるだけであり、決定での使用が停止さ
れる。このプロセスにより、特殊なケースおよびエラー
処理機構の必要性がなくなり、個々のシステムでの資源
割振りの急激な変化の可能性が低減される。

【０１０５】前の６つの間隔の間に資源グループについ
て計算されたキャップ・スライスの数（１２２）は、６
つのウィンドウ面に格納される。キャップ・スライス値
はキャッピング調整手段（１２８）によって記入され
る。それぞれの重要性レベルでローカル（１２０）およ
び遠隔（１２１）で消費されるプロセッサ・サービス単
位の数は、最後の６つの間隔の間、６つのウィンドウ面
に保持される。遠隔システムからのプロセッサ・サービ
ス単位消費データは遠隔データ受信プログラム（１２
５）によって記入される。そのウィンドウでの重要性ご
とのローカルおよび全プロセッサ・サービス単位（１５
０６）と、そのウィンドウでの全プロセッサ・サービス
単位（１５０７）は、グループ・テーブル項目（１１
７）に格納される。これらの値は、キャッピング調整手
段（１２８）によって計算され、使用される。

【０１０６】ローカル・システムがそれぞれの重要性レ
ベルの作業を有するかどうかを示す標識（１５０８）
は、それぞれの重要性レベルの作業を有する遠隔システ
ムの数（１５０９）とともに、グループ・テーブル項目
（１１７）に格納される。この標識（１５０８）は、プ
ロセッサ・サービス単位消費データ（１２０）ととも
に、データ送信手段（１２９）によってローカル・シス
テムからすべての遠隔システムに送られる。この標識
は、遠隔データ受信プログラム（１２５）によって受信
され、格納される。

【０１０７】グループ内の作業単位をキャッピングすべ
き特定のスライスは、１２２に格納されたキャップ・ス
ライス・パターンに示される。これらのビットは、キャ
ップ・スライス割当て手段によって設定される。

【０１０８】キャッピングの調整 本発明のため、ＭＧＤＰＣ（１２６）は、キャッピング
調整という新しい機能を実行するように変更されてい
る。このキャッピング調整手段（１２８）は、資源消費
をその資源グループについて指定された最大値に制限す
るために、各資源グループに割り当てられた作業単位を
ディスパッチ不能にする（キャッピングする）必要があ
る時間量を決定する。ＭＧＤＰＣ（１２６）のこの新し
いキャッピング調整手段（１２８）については、図１６
に示し、後述する。データ送信手段（１２９）は、資源
グループごとにプロセッサ資源消費データをさらに送信
するように変更されている。送信される追加データは、
重要性ごとのローカル・プロセッサ・サービス単位消費
（１８０１）と、ローカル・システムがそれぞれの重要
性レベルの作業を有するかどうかを示す標識（１８０
２）である。

【０１０９】それぞれのシステムには、資源グループご
とに、ローカル・システムとすべての遠隔システム用の
重要性レベルごとのプロセッサ・サービス消費が用意さ
れている。各システムは、測定したプロセッサ消費と導
入システム指定の最大プロセッサ消費から、すべてのシ
ステムでどの程度プロセッサ消費を低減して、全プロセ
ッサ消費がその最大値を超えないようにするかを決定す
ることができる。重要性レベルごとのプロセッサ消費デ
ータを使用して、各システムは、重要性レベルを下げて
いき、所与の重要性レベルで消費したプロセッサ・サー
ビスのうち、どの程度を引き続きローカル・システム上
で割り振っておく必要があるかを判定する。所与の重要
性レベルで測定したすべてのプロセッサ・サービス消費
が最大値を下回る場合は、ローカル・システム上でその
重要性レベルで消費したすべてのプロセッサ・サービス
が、ローカル・システム上で許されるプロセッサ・サー
ビスの量に追加される。それより高い重要性レベルで割
り振られたプロセッサ・サービスと結合したときに、そ
の重要性レベルで消費したプロセッサ・サービスのすべ
てが最大値を下回るわけではない場合は、ローカル・シ
ステムでその重要性レベルで消費したプロセッサ・サー
ビスの比例分だけが、ローカル・システムで許される全
プロセッサ・サービスに追加される。このプロセスの結
果、重要性ごとに複数のシステム間で公平なキャッピン
グが行われる。このプロセスについては図１６に示す。

【０１１０】最大量未満のプロセッサ・サービスが消費
される場合は、各システムで実行中の作業の重要性に基
づいて、追加量のプロセッサ・サービスもシステム間に
割り振られる。次に、ローカル・システムで許されるプ
ロセッサ・サービス単位の数が、キャップ・スライスの
数（図１６）とキャップ・スライス・パターン（図１
７）に変換される。

【０１１１】キャッピング調整手段（１２８）は、各シ
ステムで定期的に（好ましい実施例では１０秒おき）動
作して、ローカル・システム上のキャップ・スライスの
数を調整し、条件の変化を補正する。たとえば、１つの
システム内のある資源グループに割り当てられた作業単
位が要求の厳しいサービスを停止した場合、他のシステ
ム上の同じ資源グループに割り当てられた作業単位の方
を多く消費することができる。ただし、ローカル・シス
テム上の各資源グループをどの程度制限するかはそれぞ
れのシステムが独立して決定できることに留意すること
が重要である。中央での調整は不要である。それぞれの
システムは、ローカル・システムでいくつのキャップ・
スライスが必要になるかを判断できるだけの十分な情報
を持っている。

【０１１２】図１６は、資源グループごとに作業単位を
キャッピングすべき時間量を決定するために使用する制
御の流れを示している。１６０１では、処理すべき別の
資源グループがあるかどうかを判定するために検査が行
われる。別の資源グループがない場合は、機能が完了
し、ウィンドウ面インデックスを次のウィンドウ面に設
定して終了するために制御が１６０２に移行する。ウィ
ンドウ面インデックスは、現行ウィンドウ面インデック
スに１を加え、新しいウィンドウ面インデックスが６よ
り大きいかどうかを検査することにより、次のウィンド
ウ面に設定される。新しいウィンドウ面インデックスが
６より大きい場合は、新しいウィンドウ面インデックス
が１に設定される。処理すべき別の資源グループがある
場合は、資源グループに現在キャップ・スライスが設定
されているか、または資源グループが指定の最大値を上
回るプロセッサ時間を現在消費しているかを判定するた
めに、１６０３で検査が行われる。ＮＯの場合は、次の
資源グループを処理するために制御は１６０１に移行す
る。ＹＥＳの場合は、初期設定が行われる１６０４に制
御が移行する。

【０１１３】初期設定は、資源グループに割り振り可能
な残りのプロセッサ・サービス単位を表す変数ＲＳＡを
資源グループ用に指定された最大値に設定することと、
ローカル・システム上で消費可能なプロセッサ・サービ
ス単位を表す変数ＬＳＡをゼロに設定することから構成
される。ローカル・プロセッサ上で許されるプロセッサ
・サービス単位は、ローカル・プロセッサとすべての遠
隔プロセッサ上での消費および作業の重要性に基づいて
割り当てられる。１６０４では、配列変数ＬＳとＴＳも
初期設定される。ＬＳとＴＳは、重要性レベルの数に等
しい数の要素を備えた配列である。変数ＬＳ（ＩＭＰ）
は、それぞれの重要性レベルごとに、最新ウィンドウ分
の時間にわたってローカル・システム上でその重要性レ
ベルで消費された全サービスに設定される。これは、ロ
ーカル・プロセッサ・サービス消費ウィンドウの６つの
要素からのその重要性レベルのサービス消費データを加
えることによって行われる。それぞれの重要性レベルで
消費された全サービスである変数ＴＳ（ＩＭＰ）は、同
様に計算される。

【０１１４】１６０５では、重要性変数（ＩＭＰ）が、
プロセッサ・サービス単位データにより重要性ごとにル
ープするために初期設定すべき最高の重要性に設定され
る。１６０６では、まだ割当て可能なプロセッサ・サー
ビス単位があるかどうかを判定するために検査が行われ
る。すべてのプロセッサ・サービス単位が割り当てられ
ている場合は、ローカル・プロセッサに割り当てられた
プロセッサ・サービス単位の数をキャップ・スライスの
数（１３０）に変換する１６１６に制御が移行する。

【０１１５】指定の最大値を超えずに割り当てられるプ
ロセッサ・サービス単位が残っている場合は、制御が１
６０７に移行し、そこで、ローカル・システムとすべて
の遠隔システム上で現行重要性レベルＩＭＰで消費した
プロセッサ・サービス単位の合計量ＴＳが割当て対象と
して残っているプロセッサ・サービス単位より少ないか
どうかを判定するために検査が行われる。現行重要性レ
ベルですべてのシステム上で消費したプロセッサ・サー
ビス単位の合計が割当て対象として残っているプロセッ
サ・サービス単位以下である場合は、制御は１６０８に
移行し、そこで、現行重要性レベルＩＭＰでローカル・
システム上で消費したプロセッサ・サービス単位の数Ｌ
Ｓが許されるローカル・プロセッサ・サービス単位の数
ＬＳＡに加えられる。現行重要性レベルで消費したプロ
セッサ・サービス単位の総数が割当て対象として残って
いるプロセッサ・サービス単位より多い場合は、制御は
１６０９に移行し、そこで、許される残りのプロセッサ
・サービス単位の一部がローカル・システムに割り振ら
れる。ローカル・システムに割り振られる残りのプロセ
ッサ・サービス単位の一部は、ローカル・システム上で
現行重要性レベルで消費したプロセッサ・サービス単位
の数を、ローカル・システムとすべての遠隔システム上
で現行重要性レベルで消費した全プロセッサ・サービス
単位で割ったものである。

【０１１６】いずれの場合も制御は次に１６１０に移行
し、そこで、ローカル・システムとすべての遠隔システ
ム上で消費したプロセッサ・サービス単位の総数ＴＳ
（ＩＭＰ）が、割当て対象として残っているプロセッサ
・サービス単位の数ＲＳＡから引かれる。次に、１６１
１では、処理すべき別の重要性があるかどうかを判定す
るために検査が行われる。ＹＥＳの場合は、制御が１６
１２に移行し、そこで現行重要性変数ＩＭＰが次に低い
重要性に設定され、次に制御が１６０６に戻り、前述の
ようにさらに割り当てるべきプロセッサ・サービス単位
があるかどうかが検査される。

【０１１７】すべての重要性値が処理されたと１６１１
で判定された場合は、制御が１６１３に移行し、そこ
で、資源グループの消費量がその最大許容プロセッサ・
サービス単位未満であったかどうかを判定するために検
査が行われる。資源グループの消費量がその許容最大プ
ロセッサ・サービス単位未満ではなかった場合は、制御
が１６１６に移行し、その資源グループ用のキャップ・
スライスを計算する。資源グループの消費量がその最大
プロセッサ・サービス単位未満だった場合は、制御は１
６１４に移行し、そこで、いずれかのシステム上の資源
グループ内のいずれかの作業の最高重要性レベルの作業
をローカル・システムが有しているかどうかを判定する
ために検査が行われる。資源グループ内の作業の重要性
のうち最高の作業を有するシステムには、追加のプロセ
ッサ・サービス単位が割り当てられる。ローカル・シス
テムが資源グループ内の作業の最高重要性レベルの作業
を有していない場合は、制御が１６１６に移行し、資源
グループ用のキャップ・スライスを計算する。ローカル
・システムが資源グループ内の作業の最高重要性レベル
の作業を有する場合は、割当て可能な残りのプロセッサ
・サービス単位の一部がローカル・システム上の作業に
割り当てられる。このローカル・システム上の作業に割
り当てられた部分は、１を最高重要性レベルの作業を有
するシステムの数（１５０９）で割ったものである。

【０１１８】１６１６では、以下のステップを使用し
て、ローカル・システム上で許されるプロセッサ・サー
ビス単位の数がキャップ・スライスの数に変換される。 １．許される非キャップ・スライスの数を次のように計
算する。 非キャップ・スライス＝ＬＳＡ＊（ＴＳＬＯＷ−ＣＳＬ
ＯＷ）／ＬＳＥＲＯＷ ただし、 ＬＳＡ： 許されるローカル・プロセッサ・サービス単
位 ＴＳＬＯＷ： ウィンドウでのスライスの総数 （６＊６４＝３８４、定数） ＣＳＬＯＷ： ウィンドウでのキャップ済みスライスの
数（１５０２） ＬＳＥＲＯＷ： ウィンドウで消費されたローカル・プ
ロセッサ・サービス単位（１５０４） ２．計算の結果、非キャップ・スライスが０になる場合
は、これを１に設定する。時間の１００％をキャッピン
グしてはならない。 ３．全スライス（６４）から非キャップ・スライスを引
いた数に等しくなるようにキャップ・スライスを設定す
る。 ４．キャップ・スライス数の増加がスライスの総数の半
分を上回る場合は、スライスの総数の半分だけ、キャッ
プ・スライスの数を増加する。 ５．キャップ・スライスの数を資源グループ・テーブル
項目（１２２）に格納する。キャップ・スライスの数
は、現行ウィンドウ面インデックスでインデックスが付
けられたキャップ・スライス配列要素に格納される。

【０１１９】特定のキャップ・スライスの割当て 図１７は、キャップ・ビット操作プログラム手段が問い
合わせするために、各資源グループのキャップ・スライ
スをキャップ・スライス・パターンにわたって比較的均
等に分散するための諸ステップを示している。最大数の
キャップ済みスライスを有する資源グループに特定のス
ライスがまず割り当てられ、その後、次に多い数のキャ
ップ・スライスを必要とする資源グループ、さらにその
次と、キャップ・スライスを有するすべての資源グルー
プが処理されるまで、順に割り当てられる。システム全
体では、特定のスライスを特定の資源グループに割り当
てるときに各スライス中にキャッピングすべき資源グル
ープの数をカウントすることにより、キャップ・スライ
ス・パターンの６４個のスライスのそれぞれの間に、同
数の資源グループ±１グループがキャッピングされる。
このカウントは、そのグループに特定のスライスを割り
当てるべきかどうかを判定するためにテストされる。６
４個のスライスすべてが１回ずつ割り当てられるまで、
１つのスライスが２つの資源グループに割り当てられる
ことはない。また、６４個のスライスすべてが２回ずつ
割り当てられるまで、１つのスライスが３つのグループ
に割り当てられることはなく、以下同様になる。

【０１２０】１７０１では、システム・データが初期設
定される。キャップ・スライス・カウント配列（ＳＣ
Ａ）要素はゼロにクリアされる。スライス・カウント配
列とは、複数のカウントからなる配列である。各項目に
は、そのスライス中にキャッピングされるグループの数
が入っている。キャップ・スライス・カウント配列には
６４個の項目がある。各項目はその時間の１／６４を表
す。

【０１２１】１７０２では、最大数のキャップ・スライ
スを有し、まだ処理されていない資源グループが選択さ
れる。処理すべき資源グループがそれ以上存在しない場
合は、制御は１７０３の終了に移行する。処理すべき別
の資源グループが存在する場合は、制御は１７０４に移
行する。

【０１２２】１７０４では、資源グループ・データが初
期設定される。スライス増分（ＳＩ）と、スライス・カ
ウント基準（ＳＣＣ）と、スライス・カウント配列イン
デックス（ＳＣＡＩ）が初期設定される。（ＳＩ−１）
は、資源グループのキャップ・スライスが可能な６４個
のキャップ・スライスに比較的均等に分散されるよう
に、資源グループ用の各キャップ・スライス間でスキッ
プ可能なスライスの数である。ＳＩは、６４をそのグル
ープのキャップ・スライスの数で割った数に設定され
る。ＳＣＣは、スライス・カウント配列の最大値に設定
される。スライス・カウント配列内のすべてのカウント
が同じ値を有する場合は、ＳＣＣに１が加えられる。Ｓ
ＣＡＩは、キャップ・スライス・パターンの最初のスラ
イスから始まるように１に設定される。

【０１２３】１７０５では、ＳＣＡ（ＳＣＡＩ）セルの
カウントがこのグループ用の基準（ＳＣＣ）と照らし合
わせて検査される。スライスがＳＣＣ個のグループに割
り当てられているか、またはこのグループにすでに割り
当てられている場合は、制御は１７０６に移行し、そこ
でＳＣＡＩに１が加えられる。ＳＣＡＩが６５まで増分
されると、これは１にリセットされる（すなわち、ＳＣ
ＡＩはモジュロ６４である）。スライス・カウント配列
内のすべてのカウントが同じ値を有する場合は、ＳＣＣ
に１が加えられる。次に制御は１７０５に戻る。

【０１２４】スライスがＳＣＣ個未満の資源グループに
割り当てられていて、処理中の現行グループには割り当
てられていない場合は、制御は１７０７に移行し、そこ
で、そのスライスがそのグループに割り当てられ、ＳＣ
Ａのスライス用の使用カウントに１が加えられる。資源
グループのキャップ・スライス・パターンのＳＣＡＩに
対応するビットを設定することにより、スライスが資源
グループに割り当てられる。次に制御は１７０８に移行
する。

【０１２５】１７０８では、現行資源グループに別のス
ライスを割り当てる必要があるかどうかを判定するため
に検査が行われる。そのグループのすべてのキャップ・
スライスについて特定のスライスが割り当てられている
場合は、制御は１７０２に戻り、別の資源グループの有
無を検査する。そのグループが別の特定のスライスの割
当てを必要とする場合は、制御が１７０９に移行する。

【０１２６】１７０９では、検査すべき次の特定のスラ
イスを設定するため、ＳＣＡＩにＳＩが加えられる。Ｓ
ＣＡＩが６４を上回る場合は、ＳＣＡＩから６４が引か
れる。ＳＣＡのすべてのカウントが同じ値を有する場合
は、ＳＣＣに１が加えられる。次に制御は１７０５に戻
る。

【０１２７】

【０１２８】

【図面の簡単な説明】

【図１】３つの相互接続協調動作コンピュータ・システ
ムを有する実施例のシステム構造図であり、本発明に関
して記載するように適応された制御オペレーティング・
システムおよびシステム資源マネージャ構成要素を備え
たローカルおよび遠隔コンピュータ・システムを示す図
である。

【図２】目標主導パフォーマンス制御プログラム構成要
素内の全体的な論理の流れを示す流れ図である。

【図３】レシーバ選択機能の論理の流れを示す流れ図で
ある。

【図４】資源隘路の選択に使用する状態データを示す図
である。

【図５】隘路検出機能の論理の流れを示す流れ図であ
る。

【図６】ドナー選択機能の論理の流れを示す流れ図であ
る。

【図７】修正手段の論理の流れを示す流れ図である。

【図８】変更案用の正味値査定機能の論理の流れを示す
流れ図である。

【図９】ディスパッチの優先順位を上げることによるパ
フォーマンスの改善を査定するための諸ステップを示す
流れ図である。

【図１０】ディスパッチの優先順位の変更の影響を投影
するための論理の流れを示す流れ図である。

【図１１】達成可能な需要のサンプル・グラフである。

【図１２】待機／使用中の新しい比率を計算するための
流れ図である。

【図１３】サンプル・デルタを使用してＣＰＵ時間を計
算するための流れ図である。

【図１４】図１のシステム構造の詳細を示す図である。

【図１５】資源グループ内の作業単位をキャッピングす
べき時間量を決定するために使用するデータを示す図で
ある。

【図１６】作業単位をキャッピングすべき時間量を決定
するために使用する諸ステップを示す流れ図である。

【図１７】特定のスライスをキャップ・スライス・パタ
ーンで割り当てる方法を示す流れ図である。

【図１８】遠隔データ受信プログラム手段が受け取るデ
ータを示す図である。

【図１９】データ履歴の各部を示す図である。

【図２０】遠隔応答時間データ履歴の１行分を示す図で
ある。

【図２１】遠隔データ受信プログラムが実行する諸ステ
ップを示す流れ図である。

【図２２】マルチシステム・パフォーマンス・インデッ
クスを計算するために実行する諸ステップを示す流れ図
である。

【図２３】応答時間タイプのパフォーマンス目標クラス
と実行速度タイプのパフォーマンス目標タイプの両方に
ついて遠隔システムに送られるデータを示す図である。

【符号の説明】 １００−Ａ コンピュータ・システム １００−Ｂ コンピュータ・システム １００−Ｃ コンピュータ・システム １０１ オペレーティング・システム １０２ ディスパッチャ １０３ 作業単位 １０４ ＡＳＣＢ １０５ キャップ・ビット優先順位 １０６ 目標 １０７ プロセッサ消費最大値 １０９ 作業負荷マネージャ １１０ クラス・テーブル項目 １１１ グループ名 １１２ 目標 １１３ 重要性 １１４ サンプル・データ １１５ パフォーマンス・インデックス １１６ システム資源制御 １１７ グループ・テーブル項目 １１８ グループ名 １１９ 最大値 １２０ ローカル・データ １２１ 遠隔データ １２２ キャップ・スライス・パターン １２３ システム資源マネージャ（ＳＲＭ） １２４ 状態サンプラー １２５ 遠隔データ受信プログラム １２６ マルチシステム目標主導パフォーマンス制御プ
ログラム（ＭＧＤＰＣ） １２７ 制御調整 １２８ キャッピング調整 １２９ データ送信 １３０ キャップ・ビット操作プログラム

───────────────────────────────────────────────────── フロントページの続き (72)発明者 バーナード・ロイ・ピアス アメリカ合衆国12601 ニューヨーク州 ポーキープシー クリーム・ストリート 262 (56)参考文献 特開 平６−19861（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 15/177 674 G06F 9/46 360 ＷＰＩ（ＤＩＡＬＯＧ)

Claims (4)

(57)【特許請求の範囲】
1. 【請求項１】複数の独立協調動作データ処理システムを
   備える分散データ処理システムのプロセッサ資源を管理
   するための装置であって、 ａ）前記複数の独立協調動作データ処理システムのうち
   の少なくとも２つのシステムが前記分散データ処理シス
   テムの分散作業負荷を実行し、当該分散 作業負荷が複数
   の作業単位から成り、当該複数の作業単位のうちの少な
   くとも一部が１つ以上の資源グループに編成され、当該
   １つ以上の資源グループのうちの少なくとも１つの資源
   グループが前記少なくとも２つのシステムによってアク
   セス可能で且つ当該少なくとも２つのシステムに共通の
   少なくとも１つのプロセッサ消費最大値を有し、前記複
   数の作業単位のうちの少なくとも１つの作業単位が少な
   くとも１つの重要性レベルを有し、 ｂ）前記少なくとも１つのプロセッサ消費最大値および
   前記少なくとも１つの重要性レベルに従って前記少なく
   とも２つのシステム間でシステム資源を管理するシステ
   ム資源マネージャ手段を備え、 前記システム資源マネージャ手段が、 ｉ）前記少なくとも２つのシステムの各々にそれぞれ設
   けられ、当該各システム上で実行中の作業単位のローカ
   ル・プロセッサ消費データを決定するとともに、当該各
   システム上で実行中の作業単位に関連する１つ以上の資
   源グループおよび当該１つ以上の資源グループ内の１つ
   以上の重要性レベルに基づいて、当該各システムのロー
   カル・プロセッサ消費データを遠隔プロセッサ消費デー
   タとして前記少なくとも２つのシステムのうちの他のシ
   ステムに提供する手段と、ii ）前記少なくとも２つのシステムの各々にそれぞれ設
   けられ、前記他のシステムから前記遠隔プロセッサ消費
   データを受信する遠隔データ受信手段と、iii ）前記少なくとも２つのシステムの各々にそれぞれ
   設けられ、前記他のシステムからの前記遠隔プロセッサ
   消費データおよび当該各システムからの前記ローカル・
   プロセッサ消費データに応答して、当該各システム上の
   少なくとも１つのシステム制御パラメータを調整して、
   当該各システム上で実行中の１つ以上の作業単位のプロ
   セッサ消費を変更させるマルチシステム目標主導パフォ
   ーマンス制御手段と、iv ）前記少なくとも２つのシステムの各々にそれぞれ設
   けられ、前記調整された少なくとも１つのシステム制御
   パラメータに応答して、所定の割合の時間の間、当該各
   システム上で前記１つ以上の作業単位をキャッピングす
   るキャッピング手段とを含むことを特徴とする、前記装
   置。
2. 【請求項２】前記キャッピング手段が、 ａ）前記少なくとも１つの資源グループのうちの各資源
   グループをキャッピングする必要がある所定の割合の時
   間を決定する計算手段と、 ｂ）前記各資源グループについて決定された所定の割合
   の時間により当該各資源グループ用のキャップ・スライ
   ス・パターンを作成する手段と、 ｃ）前記キャップ・スライス・パターンに応答して、ど
   の作業単位をキャッピングすべきかを示す標識を設定す
   る手段と、 ｄ）前記標識に応答して、作業単位のディスパッチを制
   御する手段とを含むことを特徴とする、請求項１に記載
   の装置。
3. 【請求項３】複数の独立協調動作データ処理システムを
   備える分散データ処理システムのプロセッサ資源を管理
   するための方法であって、 ａ）前記複数の独立協調動作データ処理システムのうち
   の少なくとも２つのシステム間で前記分散データ処理シ
   ステムの分散作業負荷を実行するステップを含み、 当該分散 作業負荷が複数の作業単位から成り、当該複数
   の作業単位のうちの少なくとも一部が１つ以上の資源グ
   ループに編成され、当該１つ以上の資源グループのうち
   の少なくとも１つの資源グループが前記少なくとも２つ
   のシステムによってアクセス可能で且つ当該少なくとも
   ２つのシステムに共通の少なくとも１つのプロセッサ消
   費最大値を有し、前記複数の作業単位のうちの少なくと
   も１つの作業単位が少なくとも１つの重要性レベルを有
   し、 ｂ）前記少なくとも１つのプロセッサ消費最大値および
   前記少なくとも１つの重要性レベルに従って前記少なく
   とも２つのシステム間でシステム資源を管理するステッ
   プを含み、 前記管理するステップが、 ｉ）前記少なくとも２つのシステムの各々において、当
   該各システム上で実行中の作業単位のローカル・プロセ
   ッサ消費データを決定するとともに、当該各システム上
   で実行中の作業単位に関連する１つ以上の資源グループ
   および当該１つ以上の資源グループ内の１つ以上の重要
   性レベルに基づいて、当該各システムのローカル・プロ
   セッサ消費データを遠隔プロセッサ消費データとして前
   記少なくとも２つのシステムのうちの他のシステムに提
   供するステップと、ii ）前記少なくとも２つのシステムの各々において、前
   記他のシステムから前記遠隔プロセッサ消費データを受
   信するステップと、iii ）前記少なくとも２つのシステムの各々において、
   前記他のシステムからの前記遠隔プロセッサ消費データ
   および当該各システムからの前記ローカル・プロセッサ
   消費データに応答して、当該各システム上の少なくとも
   １つのシステム制御パラメータを調整して、当該各シス
   テム上で実行中の１つ以上の作業単位のプロセッサ消費
   を変更させるステップと、iv ）前記少なくとも２つのシステムの各々において、前
   記調整された少なくとも１つのシステム制御パラメータ
   に応答して、所定の割合の時間の間、当該各上システム
   上で前記１つ以上の作業単位をキャッピングするステッ
   プとを含むことを特徴とする、前記方法。
4. 【請求項４】前記キャッピング・ステップが、 ａ）前記少なくとも１つの資源グループのうちの各資源
   グループをキャッピングする必要がある所定の割合の時
   間を決定するステップと、 ｂ）前記各資源グループについて決定された所定の割合
   の時間に従って当該各資源グループ用のキャップ・スラ
   イス・パターンを作成するステップと、 ｃ）前記キャップ・スライス・パターンに応答して、ど
   の作業単位をキャッピングすべきかを示す標識を設定す
   るステップと、 ｄ）前記標識に応答して、作業単位のディスパッチを制
   御するステップとを含むことを特徴とする、請求項３に
   記載の方法。