JP4121525B2 - リソース利用率を制御する方法およびコンピュータシステム - Google Patents

Description

本出願は、一般にコンピュータシステムにおけるリソース利用率の制御に関する。

コンピュータ実行可能ファイルを別個のグループにしたいことがよくある。グループは、ユーザログイン識別子、ユーザクラス（例えば、学生、教師、管理者など）、アプリケーション名などによって定義されることがある。さらに、複数の実行可能ファイルを実行する共有コンピューティング環境では、コンピュータ管理者が、実行可能ファイルのグループ分けに基づき実行可能ファイルによるリソース利用率の制限を設けることが有利なことが多い。この制限は、グループ間の分離を維持し、容量を管理し、またはユーザが与えられたサービスレベルだけを受け取ることを確実にするために、プログラム予測精度のために使用することができる。既知のコンピューティングシステムにおいて、そのような制限は、「シェア」（有限なリソースの最大占有率）としてしばしばコード化され(ｅｎｃｏｄｅｄ)、「キャップ（ｃａｐ）」と呼ばれることもある。

シェア割り当て機構を強化するためいくつかの技術が実施されてきた。しかしながら、既知の技術は大きいオーバヘッドを課し、それによりアプリケーションのパフォーマンスが低下する。さらに、既知の技術は、それぞれのグループ内のアプリケーションの特定の組み合わせによりパフォーマンスをさらに低下させる。例えば、既知のキャッピング技術を使用することにより、グループの１つの実行可能ファイルが、同じグループの別の実行可能ファイルがリソースにアクセスする機会を有する前に、グループに割り当てられたすべてのリソース（例えば、プロセッササイクル）を消費してしまうことがある。その場合、同じグループの他の実行可能ファイルが、しばらくの間プロセッサリソースを獲得する機会がなくなる。

本発明は、コンピュータシステムにおけるリソース利用率の制御に関する方法及びシステムを提供する。

一実施形態において、方法は、（ｉ）コンピュータシステムのリソースを使用している実行可能ファイルと関連したグループを識別するステップと、（ｉｉ）グループ利用率制限がゼロより大きいときにリソースのグループ利用率制限を減少させるステップと、（ｉｉｉ）リソースのグループ利用率制限がゼロのときにグループの利用率予備量（ｕｔｉｌｉｚａｔｉｏｎ ｒｅｓｅｒｖｅ）を減少させるステップとを含み、操作（ｉ）〜（ｉｉｉ）が、システム割り込みに応じてソフトウェアルーチンによって実行され、（ｉｖ）リソースを使用する別の実行可能ファイルをスケジューリングするステップとを含み、スケジューリングするステップが、（ａ）別の実行可能ファイルが、リソースの非ゼログループ利用率を有するグループに属するか、（ｂ）別の実行可能ファイルが非ゼロ利用率予備量を有するグループに属するかを検証する。

別の実施形態において、コンピュータ可読媒体が、（ｉ）複数のプロセッサのそれぞれと複数のグループのそれぞれのプロセッサ利用率制限を決定し、（ｉｉ）複数のグループのそれぞれの利用率予備量を決定する第１のソフトウェアルーチンと、（ｉ）複数のプロセッサを使用している実行可能ファイルのグループを識別し、（ｉｉ）プロセッサ利用率制限がゼロより大きいときに識別されたグループのそれぞれのプロセッサ利用率制限を減少させ、（ｉｉｉ）識別されたグループのプロセッサ利用率制限がゼロのときに識別されたグループの利用予備量パラメータを減少させる、システム割り込みに応じて呼び出される第２のソフトウェアルーチンと、複数のプロセッサで実行される実行可能ファイルをスケジューリングする第３のソフトウェアルーチンとを含み、第３のソフトウェアルーチンは、プロセッサの実行可能ファイルが選択されたときに、（ｉ）選択された実行可能ファイルが、ゼロより大きいプロセッサのプロセッサ利用率制限を有するグループに属するか、（ｉｉ）実行可能ファイルが、ゼロより大きい利用率予備量を有するグループに属するかを検証する。

別の実施形態において、コンピュータシステムは、コンピュータシステムのプロセッサを使用する実行可能ファイルと関連したグループを識別する手段と、グループ利用率制限がゼロより大きいときにプロセッサのグループ利用率制限を減少させる手段と、プロセッサのグループ利用率制限がゼロのときにグループの利用率予備量を減少させる手段とを含み、識別する手段、減少させる手段、減少させる手段が、システム割り込みに応じて動作可能であり、プロセッサを使用する別の実行可能ファイルをスケジューリングする手段であって、（ａ）別の実行可能ファイルがプロセッサのゼロでないグループ利用率制限を有するグループに属するか、（ｂ）別の実行可能ファイルが、ゼロでない利用率予備量を有するグループに属するかを検証するスケジューリングする手段とを含む。

いくつかの代表的な実施形態は、シェアまたはキャップを利用する方式によってリソース利用率を制限するシステムおよび方法を対象とする。具体的には、プロセスがグループに編成され、各グループにリソースのシェアが提供される。リソースには、プロセッサ時間、共有チャネルのディスク帯域幅、共有ポート上のネットワーク帯域幅、または単位時間当たりのシェアで表わすことができる任意の他のリソースがある。この考察のために、プロセッサリソースだけを考察する。しかしながら、代表的な実施形態はそのように限定されない。

あらかじめ定義された間隔（例えば、１秒に１回）で、アロケータソフトウェアモジュールが実行されて、グループ基準ごととプロセッサレベルごとにグループへのリソースのどの割り当てが「適正」であるが決定される。各グループの利用できるクロック「チック」の総数が、利用可能なプロセッサの総数と各グループのシェアを使用して計算される。チックは、システム割り込みとシステム割り込みの間の時間と関連付けられた既知の期間であり、多くのシステムではシステム割り込みは一定間隔で起こる。例えば、最新のＬｉｎｕｘシステムにおいて、システム割り込みは、毎秒１０００回起こる。しかしながら、ここでの説明のためだけに、システム割り込みが毎秒１００回起こると仮定する。各グループのチックの総数の一部分が、各グループに割り当てられたプロセッサ間で分割される。この場合、各グループは、割り当てられたプロセッサに関して計算されたチックの数（グループプロセッサ制限）が許可される。さらに、各グループのチックの総数の一部分は、新しくインスタンス化された実行可能ファイルあるいは以前の１組の割り当て規則に従ってインスタンス化された昔の実行可能ファイルの「慈善（ｃｈａｒｉｔｙ）」予備量に割り当てられる。この慈善予備量によって、別のときには（ｏｔｈｅｒｗｉｓｅ）プロセッサへのアクセスを受け入れない選択されたプロセスが、ある程度進行できるようになる。

それぞれの割り込み時に、評価ソフトウェアモジュール（ａｃｃｏｕｎｔａｎｔ ｓｏｆｔｗａｒｅ ｍｏｄｕｌｅ）が実行される。それぞれのグループを使用して、評価ソフトウェアモジュールは、各プロセッサのチックにより動作する。所定のプロセッサ上でグループがグループプロセッサ制限に達したとき、評価ソフトウェアモジュールは、グループの慈善予備量にチックが残っているかどうかを判定する。残っている場合は、グループの慈善予備量を減少させる。プロセッサ制限に達し慈善予備量が使い尽くされた場合、実行可能ファイルはプロセッサから切り替えられる。また、一実施形態において、スケジューラソフトウェアモジュールが、第２段階のシェア強化を実行する。スケジューラソフトウェアモジュールは、プロセッサ上で次に実行される実行可能ファイルを決定するために使用される。スケジューラソフトウェアモジュールは、グループの慈善予備量が使い尽くされたときにグループプロセッサ制限に達したグループに関連した実行可能ファイルを選択することを許可しない。

次に図面を参照すると、図１は、代表的な一実施形態によりプロセッサリソースを割り当てるシステム１００を示す。具体的には、システム１００は、ＣＰＵ１０１−１〜１０１−Ｎで実行される複数の実行可能ファイル（アプリケーション１０２−１〜１０２Ｍとして示した）を含む。システム１００は、オペレーティングシステムカーネル内に、どのアプリケーション１０２をどのＣＰＵ１０１で実行するかを決定するソフトウェアルーチンを含むオペレーティングシステム１１０を含む。

図１に示したように、オペレーティングシステム１１０は、アロケータソフトウェアモジュール１１１を含む。アロケータソフトウェアモジュール１１１は、処理リソースをそれぞれの所定の期間内でどのように割り当てるかを決定するために使用される。一実施形態において、アロケータソフトウェアモジュール１１１は、１秒に１回呼び出され、システムクロックによって測定される次の秒にプロセッサリソースの割り当てを決定する。アロケータソフトウェアモジュール１１１は、グループごとにプロセッサリソースを割り当てる。１つの実施形態において、グループと、各グループに関連付けられたリソースのシェアを定義するために、適切なデータ構造１２０が維持される。データ構造１２０は、また、特定のグループに属する実行可能ファイルを実行するためにどのＣＰＵ１０１が割り当てられるかを示す情報を含むことができる。実行可能ファイルが作成されるとき（例えば、「ｆｏｒｋ」コマンドや他の適切なコマンドによって）、実行可能ファイルの特性（例えば、ユーザログインＩＤ、ユーザのクラス、実行可能ファイルのファイル名など）が解析される。この解析によって、プロセスと関連したデータ構造（図示せず）が、適切なグループを反映するように更新される。

アロケータソフトウェアモジュール１１１は、アロケータソフトウェアモジュール１１１が呼び出されるたびに、データ構造１２０に記憶されたシェア情報を使用して次の割り当て期間に各グループが利用可能なプロセッサリソースの総量を計算する。どのグループをどのＣＰＵ１０１に割り当てるかによって、所定のＣＰＵ１０１に割り当てられたグループが、合計１００を超えるチックを有することが可能になる。したがって、アロケータソフトウェアモジュール１１１は、ＣＰＵごとにチックを正規化することができる。さらに、アロケータソフトウェアモジュール１１１は、また、プロセッササイクルの一部分を各グループの慈善予備量に割り当てる。一実施形態において、慈善予備量は、ＣＰＵ１０１の全体にわたって適用される。慈善予備量は、割り当て期間が始まった後で作成された新しい実行可能ファイルがプロセッサリソースを得ることを可能にする。また、慈善予備量は、システム割り当て特性が変化する前にインスタンス化された昔の実行可能ファイルがプロセッサリソースを得ることを可能にする。したがって、そのような実行可能ファイルは、「リソース不足（ｓｔａｒｖｉｎｇ）」が防止され、何らかの前進を行うことが可能になる。割り当てデータは、適切なデータ構造（図１の構造１３０として示した）に記憶されてもよい。

代表的な一実施形態による割り当てデータの生成を示すために、システム１００が４つのＣＰＵ１０１を含むと仮定する。また、「学生」グループにシステムプロセッサリソースの５１％のキャップが割り当てられると仮定する。グループチックキャップを生成する式「グループ制限＝キャップ×プロセッサ数×１００」を使用して、学生グループには２０４のクロックチックが割り当てられる。１つの実施形態において、１クロックチックとグループ制限の１％の大きい方が、慈善予備量に「寄付」される。学生グループの場合、２つのクロックチックが学生慈善予備量に割り当てられる。次に、残りのクロックチックが、ＣＰＵ１０１に割り当てられる。学生グループが、３つのＣＰＵ（１０１−１〜１０１−３）だけで実行するように割り当てられた場合、学生グループのＣＰＵのそれぞれに６７のチックが提供される。丸めにより除かれた追加のクロックチックは、学生慈善予備量に寄付される。

さらに、「管理者」グループが、１０％のキャップを受け取り、ＣＰＵ１０１−１上だけで実行するように割り当てられたと仮定する。その場合、管理者グループは、４０（すなわち４×１００×０．１０）のクロックチックを受け取る。それらのクロックチックのうちの１つが、管理者慈善予備量に寄付される。前述のように、ＣＰＵ１０１−１上の６７のクロックチックは既に割り当てられている。具体的には、１秒当たりに実行される総数１０６（すなわち３９＋６７）の時間チックが、ＣＰＵ１０１−１に利用可能なたった１００のチックと共にＣＰＵ１０１−１に割り当てられている。したがって、１つのＣＰＵ１０１にクロックチックが１００だけ割り当てられるように正規化が行われることが好ましい。正規化演算によって生成される丸めの超過分が、慈善予備量に再分配される。

また、「その他」グループが、２５％のキャップ（１００チック）を受け取り、ＣＰＵ１０１−４に割り当てられ、１クロックチックがその他慈善予備量に寄付されると仮定する。

以下の表は、様々なグループと慈善予備量に関して計算されたチックをまとめたものである。

図１のシステム１００でチックごとにシステム割り込みが起こり、クロックチック制限を強化するために評価ソフトウェアモジュール１１２が呼び出される。評価ソフトウェアモジュール１１２は、それぞれのＣＰＵ１０１上にどの実行可能ファイルがあるかを決定し、実行可能ファイルがどのグループに属するかを決定する。各ＣＰＵ１０１に対して、評価ソフトウェアモジュール１１２は、前に計算されたグループチックを減少させる。特定のグループとＣＰＵ１０１のグループチックカウントがゼロになったとき、評価ソフトウェアモジュール１１２は、グループごとの慈善予備量内にチックがあるか否かを判定する。慈善予備量内にチックがある場合は、現行の実行可能ファイルが継続され、慈善予備量が減分される。それぞれのＣＰＵ１０１とグループのグループチックカウントがゼロになり、慈善予備量もゼロになったとき、そのグループに属する実行可能ファイルは、それぞれのＣＰＵ１０１から切り替えられる。

スケジューラソフトウェアモジュール１１３は、実行可能ファイルがＣＰＵ１０１から切り替えられたとき、実行可能ファイルがその動作を完了したとき、実行可能ファイルがスリープ状態になったときなどに、次の実行可能ファイルを決定する。スケジューラソフトウェアモジュール１１３は、スケジューリングの決定を行うために各ＣＰＵ１０１ごとに実行待ち行列（１１４−１〜１１４−Ｎで示した）を保持することがある。スケジューラモジュール１１３は、既知のスケジューラアルゴリズムを使用して実施し、それ以外に、スケジューラモジュール１１３は、実行可能ファイルが、それぞれのＣＰＵに残っているチックを有するグループに属するか、または慈善予備量内にチックが残っていることを検証することができる。また、それぞれのＣＰＵ１０１に所定のグループのジョブが残っていない場合は、グループの残りのチックが慈善予備量に提供される。

図２は、代表的な一実施形態により、実行可能ファイルを複数のグループに割り当てるためにクロックチックで測定されたＣＰＵリソースの量を決定するフローチャートを示す。図２に示した操作は、アロケータソフトウェアモジュール１１１内の適切なコードまたはソフトウェア命令を使用して実施することができる。コードまたはソフトウェア命令は、任意の適切なコンピュータ可読媒体に記憶することができる。１つの実施形態において、図２に示した操作は、１秒に１回実行される。

ステップ２０１で、適切なデータ構造からグループキャップ情報を取り出す。ステップ２０２で、次の割り当て期間のグループチックの総数を、ＣＰＵ全体の可用性（ａｖａｉｌａｂｉｌｉｔｙ）とグループキャップ情報を使用して計算する。グループチック全体のうちのある割合を、それぞれのグループごとの慈善予備量に割り当てる（ステップ２０３）。ステップ２０４で、グループチック全体を、各グループの個々に割り当てられたＣＰＵに分割する。ステップ２０５で、それぞれ個々のＣＰＵのグループチック全体がそれぞれのＣＰＵのチックの可用性を超えないようにグループチックを正規化する。以上の計算で生じた丸め誤差は、慈善予備量に寄付されることがある。

図３は、代表的な一実施形態によりＣＰＵ利用率を評価するフローチャートを示す。図３に示した操作は、評価ソフトウェアモジュール１１２内の適切なコードまたはソフトウェア命令を使用して実施することができる。コードまたはソフトウェア命令は、任意の適切なコンピュータ可読媒体に記憶することができる。１つの実施形態において、図３に示した操作は、各システム割り込み時に実行される。

ステップ３０１で、検査するＣＰＵを選択する。ステップ３０２で、ＣＰＵ上にジョブのないグループに割り当てがあるかどうかを判定する論理比較を行なう。割り当てがある場合は、プロセスフローはステップ３０３に進み、そこでグループごとの割り当てをそれぞれの慈善予備量に送る。割り当てがない場合、プロセスフローはステップ３０４に進む。

ステップ３０４で、現在ＣＰＵを使用している実行可能ファイルのグループを決定する。ステップ３０５で、ＣＰＵのグループのチックカウントがゼロより大きいかどうかを判定する論理比較を行う。ゼロより大きい場合は、プロセスフローはステップ３０６に進み、グループのチックカウントが減分される。そうでない場合、プロセスフローはステップ３０７に進み、グループの慈善予備量がゼロかどうか判定する別の論理比較を行う。慈善予備量がゼロでない場合、慈善予備量を減少させる（ステップ３０８）。そうでない場合、実行可能ファイルをＣＰＵから切り替える（ステップ３１０）。

プロセスフローは、ステップ３０６と３０８のそれぞれからステップ３０９に移る。ステップ３０９で、ＣＰＵを使用するために別のグループが待っているかどうか判定する論理比較を行う。ＣＰＵを使用するために別のグループが待っている場合は、現行の実行可能ファイルをＣＰＵから切り替え（ステップ３１０）、スケジューリングアルゴリズムに従って別のグループの実行可能ファイルがＣＰＵにアクセスすることを許可する。そうでない場合、プロセスフローはステップ３１１に進む。ステップ３１１で、検査する別のＣＰＵがあるかどうかを判定する論理比較を行う。調査する別のＣＰＵがある場合、プロセスフローはステップ３０１に戻る。そうでない場合、プロセスフローは終了する（ステップ３１２）。

図４は、代表的な一実施形態によりＣＰＵに配置される（ｐｌａｃｅｄ）実行可能ファイルを選択するフローチャートを示す。図４に示した操作は、スケジューラソフトウェアモジュール１１３内の適切なコードまたはソフトウェア命令を使用して実施することができる。コードまたはソフトウェア命令は、任意の適切なコンピュータ可読媒体に記憶することができる。図４に示した操作は、実行可能ファイルが終了したとき、実行可能ファイルがスリープ状態になったとき、実行可能ファイルがＣＰＵから切り替えられたとき（図３のステップ３１０を参照）などに実行されることがある。

ステップ４０１で、既知または今後開発されるスケジューリングアルゴリズムに従ってそれぞれのＣＰＵの実行待ち行列から実行可能ファイルを選択する。ステップ４０２で、実行可能ファイルが各ＣＰＵのゼロでないチックを有するグループに属しているかどうかを判定する論理比較を行う。そのグループに属する場合は、実行可能ファイルをＣＰＵに入れる（ステップ４０４）。そうでない場合は、ステップ４０３で別の論理比較を行う。ステップ４０３で、実行可能ファイルがゼロでない慈善予備量を有するグループに属しているかどうかを判定する論理比較を行う。そのようなグループに属している場合は、実行可能ファイルをＣＰＵに配置する（ステップ４０４）。そうでない場合、フロープロセスフローはステップ４０１に戻り、別の実行可能ファイルを選択する。

いくつかの代表的な実施形態には多数の長所がある。例えば、いくつかの代表的な実施形態は、割り当て操作と評価操作に比較的高い精度がある。さらに、いくつかの代表的な実施形態は、利用操作を管理するシステムリソースにかかるオーバヘッドが比較的低い。アプリケーション性能は、ほとんど妨げられない。また、オーバヘッドが低いため、大きいマルチプロセッサスケーリングを効率的に行うことができる。既知の作業負荷管理（ＷＬＭ）キャッピング技術と違って、いくつかの代表的な実施形態は、１秒以上の間約０．５パーセントの精度の範囲内で実行可能ファイルを適正に割り当てる。したがって、いくつかの代表的な実施形態は、ＵＮＩＸ（登録商標）プロセスの約９５パーセントが１秒未満で完了する場合にかなり改善された性能を示す。さらに、いくつかの代表的な実施形態によれば、任意の事前定義されたスケジューリングスロットに強制的に入れられる代わりに、必要とされるときにグループがリソースを要求することができるので、入出力の頻繁な作業負荷は、きわめて改善された性能を示す。

代表的な一実施形態によるリソースを割り当てるシステムを示す図である。 代表的な一実施形態により複数の実行可能ファイルに割り当てるためにクロックチックで測定されたＣＰＵリソースの量を決定するフローチャートである。 代表的な一実施形態によるリソース利用率を評価するフローチャートである。 代表的な一実施形態によりＣＰＵに配置する実行可能ファイルを選択するフローチャートである。

符号の説明

１００・・・システム
１０１−１〜Ｍ・・・ＣＰＵ
１０２−１〜Ｍ・・・アプリケーション
１１０・・・オペレーティングシステム
１１１・・・アロケータソフトウェアモジュール
１１２・・・評価ソフトウェアモジュール
１１３・・・スケジューラソフトウェアモジュール
１１４−１〜Ｍ・・・実行待ち行列
１２０・・・グループ定義／シェア
１３０・・・ＣＰＵごとのグループチックとグループごとの慈善予備量

Claims (9)

1. （ｉ）コンピュータシステムのリソースを使用している実行可能ファイルに関連したグループを識別するステップ（３０４）と、
   （ｉｉ）前記リソースのグループ利用率制限を、前記グループ利用率制限がゼロより大きいときに減少させるステップ（３０６）と、
   （ｉｉｉ）前記リソースの前記グループ利用率制限がゼロのときに前記グループの利用率予備量を減少させるステップ（３０８）であって、操作（ｉ）〜（ｉｉｉ）をシステム割り込みに応じるソフトウェアルーチンによって実行するステップと、
   （ｉｖ）前記リソースを使用する別の実行可能ファイルをスケジューリングするステップであって、（ａ）前記別の実行可能ファイルが、前記リソースのゼロでないグループ利用率制限を有するグループに属しているか、（ｂ）前記別の実行可能ファイルが、ゼロでない利用率予備量を有するグループに属しているかを検証するスケジューリングするステップと、
   （ｖ）前記コンピュータシステムで使用可能なリソースの数を決定するステップと、
   （ｖｉ）前記グループに関連付けられたシェア制限に前記数を掛けてグループ全体の制限を生成するステップ（２０２）と、
   （ｖｉｉ）前記グループに割り当てられたリソース間で前記グループ全体の制限を分割して、割り当て期間の前記グループ利用率制限を生成するステップ（２０４）と
   を含む方法。
2. 前記利用率予備量に割り当てる前記グループ全体の制限の一部を減少させるステップをさらに含み、前記減少させるステップが、前記分割するステップの前に実行される（２０３）請求項１に記載の方法。
3. 前記グループ利用率制限と前記リソースの他のグループのグループ利用率制限が、前記リソースに使用可能な利用率合計を超えたときに、前記リソースの前記グループ利用率制限を正規化するステップ（２０５）をさらに含む請求項１に記載の方法。
4. （ｖ）〜（ｖｉｉ）が、１つの割り当て期間に１回呼び出される別のソフトウェアルーチンによって実行される請求項１に記載の方法。
5. 前記割り当て期間が１秒である請求項４に記載の方法。
6. 前記グループ利用率制限と前記コード化された利用率が、前記グループの実行可能ファイルによって使用される前記コンピュータシステムのチックを表す請求項４に記載の方法。
7. 前記コンピュータシステムのプロセッサ（１０１）を使用する実行可能ファイル（１０２）に関連したグループを識別する手段と、
   前記グループ利用率制限がゼロより大きいとき前記プロセッサのグループ利用率制限（１３０）を減少させる手段と、
   前記プロセッサの前記グループ利用率制限がゼロのときに前記グループの利用率予備量を減少させる手段であって、前記識別する手段、デクリメントする手段、および減少させる手段が、システム割り込みに応じて動作可能である手段と、
   前記プロセッサを使用する別の実行可能ファイルをスケジューリングする手段（１１４）であって、（ａ）前記別の実行可能ファイルが、ゼロでないグループ利用率制限を有するグループに属しているか、（ｂ）前記別の実行可能ファイルが、ゼロでない利用率予備量を有するグループに属しているかを検証するスケジューリングする手段と、
   前記コンピュータシステムで使用可能なプロセッサの数を決定する手段と、
   前記グループに関連付けられたシェア制限に前記数を掛けてグループ全体の制限を生成する手段と、
   前記グループに割り当てられたプロセッサ間で前記グループ全体の制限を分割して、割り当て期間の前記グループ利用率制限を生成する手段と
   を含むコンピュータシステム。
8. 前記グループ利用率制限が、前記グループによって使用されるシステムチックの数をコード化する請求項７に記載のコンピュータシステム。
9. 前記実行可能ファイルが、ゼロである前記プロセッサのグループ利用率制限と、ゼロである利用率予備量とを有するグループに属しているときに、前記プロセッサから実行可能ファイルを取り除く手段をさらに含む請求項７に記載のコンピュータシステム。

Images