(57)【特許請求の範囲】
【請求項１】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムにおいて、性能を制御する方法であって、
前記システムの入力量監視手段が、前記ＣＤＰプログラムに対する入力量が所定の基準値を超えているか否か判定するステップと、
入力量が所定の基準値を超えている場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限でない場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より高いプログラム駆動周波数を算出するステップと、
前記システムのデューティ率予測手段が、現在のデューティ率に基づいて、前記周波数管理手段が算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率を求めるステップと、
前記デューティ率予測手段が、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記デューティ率予測手段が、前記算出したプログラム駆動周波数を、変更後のプログラム駆動周波数として決定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定し、並列度を高くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を含むことを特徴とする方法。
【請求項２】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、
前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、
前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段と、
前記ＣＤＰプログラムに対する入力量が所定の基準値を超えているか否か判定する入力量監視手段と、
入力量が所定の基準値を超えている場合、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限であるか否か判定し、上限でない場合、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より高いプログラム駆動周波数を算出する周波数管理手段と、
現在のデューティ率に基づいて、前記周波数管理手段が算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率を求め、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定し、上限を超えていない場合、前記算出したプログラム駆動周波数を、変更後のプログラム駆動周波数として決定するデューティ率予測手段と、
前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定し、並列度を高くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定する並列度管理手段と、
前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するプログラム再開手段と
を備えたことを特徴とするシステム。
【請求項３】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムに、性能を制御させるためのプログラムであって、
前記システムの入力量監視手段が、前記ＣＤＰプログラムに対する入力量が所定の基準値を超えているか否か判定するステップと、
入力量が所定の基準値を超えている場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限でない場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より高いプログラム駆動周波数を算出するステップと、
前記システムのデューティ率予測手段が、現在のデューティ率に基づいて、前記周波数管理手段が算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率を求めるステップと、
前記デューティ率予測手段が、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記デューティ率予測手段が、前記算出したプログラム駆動周波数を、変更後のプログラム駆動周波数として決定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定し、並列度を高くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を前記システムに実行させることを特徴とするプログラム。
【請求項４】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムにおいて、性能を制御する方法であって、
前記システムの入力量監視手段が、実行中のプログラムに対する入力量が所定の基準値を下回っているか否か判定するステップと、
入力量が基準値を下回っている場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を低くすることが可能か否か判定するステップと、
並列度を低くすることが可能である場合、前記並列度管理手段は、前記スケジュール記憶手段から前記特定の並列度より低いスケジュールを選択するステップと、
前記システムのデューティ率予測手段が、現在のデューティ率に基づいて、前記並列度管理手段が選択した並列度でプログラムを実行した場合の予測デューティ率を求めるステップと、
前記デューティ率予測手段が、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記デューティ率予測手段が、前記選択したスケジュールを、変更後のスケジュールとして決定するステップと、
並列度を低くすることが不可能である場合、または前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を含むことを特徴とする方法。
【請求項５】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、
前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、
前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段と、
実行中のプログラムに対する入力量が所定の基準値を下回っているか否か判定する入力量監視手段と、
入力量が基準値を下回っている場合、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定する周波数管理手段と、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を低くすることが可能か否か判定し、並列度を低くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より低いスケジュールを選択する並列度管理手段と、
現在のデューティ率に基づいて、前記並列度管理手段が選択した並列度でプログラムを実行した場合の予測デューティ率を求め、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定し、前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記選択したスケジュールを、変更後のスケジュールとして決定するデューティ率予測手段と、
変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するプログラム再開手段と
を備え、前記周波数管理手段は、並列度を低くすることが不可能である場合、または前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定することを特徴とするシステム。
【請求項６】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムに、性能を制御させるためのプログラムであって、
前記システムの入力量監視手段が、実行中のプログラムに対する入力量が所定の基準値を下回っているか否か判定するステップと、
入力量が基準値を下回っている場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を低くすることが可能か否か判定するステップと、
並列度を低くすることが可能である場合、前記並列度管理手段は、前記スケジュール記憶手段から前記特定の並列度より低いスケジュールを選択するステップと、
前記システムのデューティ率予測手段が、現在のデューティ率に基づいて、前記並列度管理手段が選択した並列度でプログラムを実行した場合の予測デューティ率を求めるステップと、
前記デューティ率予測手段が、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定するステップと、
前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記デューティ率予測手段が、前記選択したスケジュールを、変更後のスケジュールとして決定するステップと、
並列度を低くすることが不可能である場合、または前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を前記システムに実行させることを特徴とするプログラム。
【請求項７】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムにおいて、性能を制御する方法であって、
前記システムのデューティ率監視手段が、前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えているか否か判定するステップと、
前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えている場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定するステップと、
並列度を高くすることが可能である場合、前記並列度管理手段が、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定するステップと、
並列度を高くすることが不可能である場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を含むことを特徴とする方法。
【請求項８】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、
前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、
前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段と、
前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えているか否か判定するデューティ率監視手段と、
前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えている場合、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定し、並列度を高くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定する並列度管理手段と、
並列度を高くすることが不可能である場合、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定し、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定する周波数管理手段と、
前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するプログラム再開手段と
を備えたことを特徴とするシステム。
【請求項９】
メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムに、性能を制御させるためのプログラムであって、
前記システムのデューティ率監視手段が、前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えているか否か判定するステップと、
前記ＣＤＰプログラムのデューティ率が所定のデューティ率の上限を超えている場合、前記システムの並列度管理手段が、前記スケジュール記憶手段および前記特定の並列度に基づいて、並列度を高くすることが可能か否か判定するステップと、
並列度を高くすることが可能である場合、前記並列度管理手段が、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定するステップと、
並列度を高くすることが不可能である場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限であるか否か判定するステップと、
前記特定のプログラム駆動周波数が前記プログラム駆動周波数の下限でない場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定するステップと、
前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップと
を前記システムに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、性能制御方法、そのシステムおよびプログラムに関し、より詳細には、システムの性能上限を実行環境の許す範囲で制御する方法、そのシステムおよびプログラムに関する。
【背景技術】
【０００２】
クラウドコンピューティングは次世代のコンピューティング環境として期待を集めている。クラウドサービスを利用すると、システムの実行環境（サーバ、ストレージ、ネットワークなど）の調達・増強・縮退が短時間で可能であり、使った時間だけ利用料を払えばよい。従来、ソフトウェアシステムは、運用時にはごく稀にしか起きないピーク性能を基準に実行環境をサイジングし、その固定的な実行環境を前提に構築されてきた。その結果、低い平均負荷、高い運用コストを招いていた。クラウドでは、必要に応じて実行環境のサイズを変えられるので、運用コストの削減が期待できる。
【０００３】
また、従来、ソフトウェアシステムの開発段階において、マシンリソースの不足が開発スケジュール遅延の原因となることが多かった。例えば、試験工程では、マシンリソースの不足により、多くの期間を費やすこととなる。開発段階においてクラウドコンピューティングを利用することで、マシンリソースに制約されない開発が可能になり、開発期間の短縮、開発費の削減が期待できる。このようにクラウドコンピューティングは、従来のソフトウェアシステムの諸問題を解決できる可能性を秘めている。
【０００４】
クラウドコンピューティングには課題もある。一般に、ソフトウェアシステムは、機能要求に加えて、性能要求も満たす必要がある。従来、固定された実行環境において性能試験を行うことにより、一定の性能を保証してきた。従来型システムでは、実際に運用される実行環境が固定されるので、同実行環境における試験結果が、運用時に成り立つと類推可能だからである。一方、クラウドサービスでは、ベストエフォートで実行環境を提供する。
【０００５】
ベストエフォート型では、例えば、ＣＰＵのクロック数に関して、あるユーザーがＣＰＵ負荷の高いプログラムを実行すると、同一環境を利用する別のユーザーの性能は劣化する。また、ストレージに関して、あるユーザーがストレージに過剰な負荷をかける大量のトランザクションを処理すると、同様に、同一環境を利用する別のユーザーのＩ／Ｏ性能は劣化する。ネットワークに関しても同様である。これでは、実行環境を特定することができず、従って、性能試験の結果が運用時にも成り立つとの類推はできない。
【０００６】
このような問題を解決するため、本件出願人は、実行環境を固定できないクラウドコンピューティングにおいて、システムとしての性能（スループット）を保証する手段を提供することに成功した。システムとしての性能を保証するために、当該技術では、タイマーにより、定められた一定の処理を実行し、それが終了すると、次にタイマーにより駆動されるまで休むよう動作するクロック駆動プログラミング（ＣＤＰ）のプログラムを処理する。高速マシンを使うと、実行時間は減少するが、その分休止時間が増える。低速マシンを使うと、実行時間が増加し、その分休止時間が減少する。すなわち、高速マシンおよび低速マシンのいずれを用いても、時間当たりの実行ステップ数は同じになる。従って、性能（スループット）はハードウェアには依存せずに同一になる。
【０００７】
ただし、周期Ｔを保ってプログラムを実行するために、以下の式で示されるデューティ率（Ｄ）は１未満である必要がある。τは実行時間である。
【０００８】
【数１】
0005480322.tif 000002
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来、ソフトウェアは実行環境の許す限り最速で処理が行われるように記述されてきた。この場合、まず第１に、所定の処理を行うための適切なリソース量を決定する技術は存在しなかった。
【００１０】
第２に、入力量が増える場合に、必要な性能を得るためにはどの程度のリソース量を与えればよいのかを決定する技術も存在しなかった。ソフトウェアが実行環境の許す限り最速で処理が行われるように記述されている場合、実行環境に依存する性能上限内において、入力量に追従して自動的にシステム性能が上がるというメリットがある。しかし、この性能上限を決めるためには、プログラムに与えるリソース量を調整する必要があった。
【００１１】
プログラムに与えるリソースを調整する仕組みとしては、Linux（登録商標）のコントロールグループなど、物理マシンのコンフィグレーションを変えることなく調整できる技術が整ってきている。しかし、必要な性能を得るためにはどの程度のリソース量を与えればよいのかについては、未だに決定的な技術は存在しない。よって、システムの性能を必要に応じて制御することもできなかった。
【００１２】
第３に、入力量の少ない場合に、一定の性能に抑えるためにはどの程度のリソース量を減らせばよいのかを決定する技術も存在しなかった。
【００１３】
本発明は、このような問題に鑑みてなされたもので、その目的とするところは、システムの性能上限を、実行環境の許す範囲で動的に制御する手段を提供することにある。
【課題を解決するための手段】
【００１４】
上記の課題を解決するために、本発明に係る性能制御方法は、メモリに格納されたクロック駆動プログラミング（ＣＤＰ）プログラムを特定のプログラム駆動周波数かつ特定の並列度で実行するシステムであって、前記ＣＤＰプログラムを実行する並列度および当該並列度に対応するスケジュールを格納するスケジュール記憶手段と、前記ＣＤＰプログラムのプログラム駆動周波数の下限および前記ＣＤＰプログラムのプログラム駆動周波数の上限を格納する周波数記憶手段とを備えたシステムにおいて、性能を制御する方法であって、前記システムの入力量監視手段が、前記ＣＤＰプログラムに対する入力量が所定の基準値を超えているか否か判定するステップと、入力量が所定の基準値を超えている場合、前記システムの周波数管理手段が、前記周波数記憶手段に基づいて、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限であるか否か判定するステップと、前記特定のプログラム駆動周波数が前記プログラム駆動周波数の上限でない場合、前記周波数管理手段が、前記システムのタイムスライスに基づいて、前記特定のプログラム駆動周波数より高いプログラム駆動周波数を算出するステップと、前記システムのデューティ率予測手段が、現在のデューティ率に基づいて、前記周波数管理手段が算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率を求めるステップと、前記デューティ率予測手段が、前記予測デューティ率が所定のデューティ率の上限を超えているか否かを判定するステップと、前記予測デューティ率が前記所定のデューティ率の上限を超えていない場合、前記デューティ率予測手段が、前記算出したプログラム駆動周波数を、変更後のプログラム駆動周波数として決定するステップと、前記予測デューティ率が前記所定のデューティ率の上限を超える場合、前記システムの並列度管理手段が、前記スケジュール記憶手段に基づいて、並列度を高くすることが可能か否か判定し、並列度を高くすることが可能である場合、前記スケジュール記憶手段から前記特定の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定するステップと、前記システムのプログラム再開手段が、前記変更後のプログラム駆動周波数または前記変更後のスケジュールが決定されている場合、当該決定されたプログラム駆動周波数またはスケジュールでプログラムを再開するステップとを含むことを特徴とする。
【発明の効果】
【００１５】
本発明は、プログラム駆動周波数および並列度を制御することにより、特定の性能を維持しながらシステムを安定稼働させることができるか否かを検証することができる。一実施形態では、特定の性能を維持しながらシステムを安定稼働させるために必要な最少の並列度、すなわちＣＰＵの数を得ることができる。別の実施形態では、特定の性能を維持しながらシステムを安定稼働させることができないこと、および、その場合に、システムを安定稼働させながら提供可能な最高のプログラム駆動周波数を得ることができる。
【００１６】
本発明は、また、プログラム駆動周波数および並列度を制御することにより、入力量に応じてシステムの性能を上げることができる。また、制御に当たっては、不必要に並列度を高くすることを回避しながらシステムの性能を上げることができるので、リソースの不要な占有を起こすことはない。
【００１７】
本発明は、また、プログラム駆動周波数および並列度を制御することにより、入力量に応じてシステムの性能を下げることができる。また、制御に当たっては、並列度を優先して低くしながらシステムの性能を下げることができるので、不必要なリソースを優先して開放することができる。
【００１８】
なお、このような効果を得るに当たって、困難なリソース量解析を行う必要はまったくない。
【００１９】
さらに、本発明は、デューティ率による性能限界をフォローしながら性能を制御することができるので、システムを安定稼働させることができる。
【図面の簡単な説明】
【００２０】
【図１】本発明の一実施形態に係るネットワーク構成を示す図である。
【図２】本発明の一実施形態に係るタスクのプログラム記述例を示す図である。
【図３】本発明の一実施形態に係る別のタスクを利用するタスクのプログラム記述例を示す図である。
【図４】本発明の一実施形態に係るタスク配列のプログラム記述例を示す図である。
【図５】本発明の一実施形態に係るタスクのコールグラフを示す図である。
【図６】本発明の一実施形態に係るタスクのＰＥＲＴ図である。
【図７】本発明の一実施形態に係るタスクのコールグラフを示す図である。
【図８Ａ】ポーリングを用いたタスクのプログラム記述例を示す。
【図８Ｂ】ポーリングを用いたタスクのプログラム記述例を示す。
【図９】本発明の一実施形態に係るタスクのＰＥＲＴ図である。
【図１０】本発明の一実施形態に係るタスク間の先行関係を示す先行関係表である。
【図１１Ａ】変数リネーム技法を適用する前のプログラム記述例を示す図である。
【図１１Ｂ】変数リネーム技法を適用する後のプログラム記述例を示す図である。
【図１２】個別化技法を適用する前後のコールグラフを示す図である。
【図１３Ａ】抽選化技法を適用したタスクのプログラム記述例を示す図である。
【図１３Ｂ】抽選化技法を適用したタスクのプログラム記述例を示す図である。
【図１４】本発明の一実施形態に係るタスクのＰＥＲＴ図である。
【図１５】本発明の一実施形態に係るタスクを実行するプログラム記述例を示す図である。
【図１６】本発明の一実施形態に係るタスクを実行するプログラム記述例を示す図である。
【図１７】本発明の一実施形態に係るタスクを並列実行するシーケンス図である。
【図１８】本発明の一実施形態に係るスケジュール作成システムの構成を示すブロック図である。
【図１９】本発明の一実施形態に係るスケジュール記憶手段に格納された情報の一例を示す図である。
【図２０】本発明の一実施形態に係る性能を制御する工程を示すフローチャートである。
【図２１】本発明の一実施形態に係る性能を制御する工程を示すフローチャートである。
【図２２】本発明の一実施形態に係る性能を制御する工程を示すフローチャートである。
【発明を実施するための形態】
【００２１】
（ネットワーク構成）
図１は、本発明の一実施形態に係るネットワーク構成を示す図である。複数の性能制御システム１０１ａ、１０１ｂ、・・・、１０１ｎ（以下、性能制御システム１０１と呼ぶ）が、インターネット１０２を介して、複数のクライアントコンピュータ１０３ａ、１０３ｂ、・・・、１０３ｎ（以下、クライアントコンピュータ１０３と呼ぶ）と相互に通信可能に接続される。
【００２２】
性能制御システム１０１は、利用者に提供するサービスを実現するためのプログラムを格納するメモリを有し、利用者の要求に応答して、ストレージに格納されたプログラムを処理するために必要なデータを用いて、サービスを提供する。本発明の性能制御システム１０１により実行されるプログラムは、所定の条件を満たすよう構成されたクロック駆動プログラミング（ＣＤＰ）プログラムである。
【００２３】
クライアントコンピュータ１０３は、クラウドサービスの利用者によって使用される端末である。利用者は、クライアントコンピュータ１０３を介して、性能制御システム１０１が提供するサービスを、サーバ群を意識することなしに利用する。本実施形態では、クライアントコンピュータ１０３は、一般的なパーソナルコンピュータである。
【００２４】
（ＣＤＰプログラム）
初めに、ＣＤＰプログラムについて説明する。ＣＤＰは、イベント駆動プログラミング（ＥＤＰ）の一部である。従って、ＣＤＰは、ＥＤＰをサポートする任意のプログラミング言語、およびＯＳで実践できる。本実施形態では、C言語、およびWindows（登録商標）を用いるが、これに限定されるものではない。
【００２５】
ＣＤＰとＥＤＰとの違いは、イベントハンドラーの使い方にある。ＥＤＰでは、任意の数のタイマーを利用することができるのに対し、ＣＤＰでは、タイマーイベントハンドラーを提供するタイマーを、必ず１つ利用することが要求される。
【００２６】
また、ＥＤＰでは、タイマーイベントハンドラーを含むすべてのイベントハンドラーにおいて、イベントに対応する処理を行う。一方、ＣＤＰでは、タイマーイベントハンドラー以外のイベントハンドラーにおいて、状態を示すフラグをセットすることにより、イベントの発生を記録するのみで、イベントに対応する処理は、ここでは行わない。ＣＤＰでは、タイマーイベントハンドラーにおいて、状態を示すフラグに基づいて、イベントの発生に対応するタスクを実行する。
【００２７】
ＣＤＰプログラムは、以下の手順で作成される。１）タスクを洗い出し、記述する。２）タスク間の先行関係を把握し、ＰＥＲＴ図を作成する。３）ＰＥＲＴ図によって与えられた先行関係の制約を満たすスケジュールを作成する。タスクの記述、ＰＥＲＴ図の作成、スケジュールの作成を順に説明する。
【００２８】
（タスクの記述）
ＣＤＰのタスクを、図２のプログラム記述例に基づいて説明する。ＣＤＰのタスクは、以下の要素を用いて定義される。
内部変数：ステート間で値を引継ぐために使用する１以上の変数
インタフェース関数：内部変数を他のタスクが参照または更新するための０以上の関数
リセット関数：内部変数を初期化するための関数
タスク本体関数：タイマーイベントハンドラーによって呼び出される関数
ＣＤＰのタスクは、状態により、実行する動作が変化するステートマシンである。ステート間で値を引継ぐために、内部変数を用いる。図２の例では、行番号L5に、taskA_data_t構造体型の内部変数taskA_dataが定義されている。なお、taskA_data_t構造体型は、同図の行番号L2からL4により示されるように、taskA_state_t列挙型の変数state、int型のx、y、resultをメンバとして含む。
【００２９】
ＣＤＰのタスクは、前述の内部変数を他のタスクが参照または更新するためのインタフェース関数を必要に応じて定義する。図２の例では、行番号L13からL31で定義されるcalcメソッド、行番号L33からL43で定義されるget_resultメソッドがインタフェース関数である。calcメソッドは、図２に記述されるTaskAに処理を要求するための関数、get_resultメソッドは、処理結果を要求するための関数である。
【００３０】
ＣＤＰのタスクはまた、内部変数を初期化するためのリセット関数を定義する。図２の例では、行番号L45からL48で定義されるtaskA_RSTメソッドがリセット関数である。本実施形態では、リセット関数において内部変数taskA_dataのメンバ変数stateを初期化している。
【００３１】
そして、ＣＤＰのタスクは、タイマーイベントハンドラーによって呼び出されるタスク本体関数を定義する。図２の例では、行番号L50からL84で定義されるtaskA_CLKメソッドがタスク本体関数である。図２に示されるように、タスク本体関数は、taskA_data.stateの値に従って計算を実行する。stateがcalc1の場合、Ｆ（ｘ）を計算する。ここで、関数Fは、行番号L11で定義されるように、標準ライブラリなどの他のモジュールで定義される外部関数である。stateがcalc2の場合、定数LIMITを上限として、Ｆ（ｘ）yを計算する。
【００３２】
ここで、タスクの実行時間は、タイマーの周期より短い必要がある。そのため、タスクは次の２つの要求を満たす必要がある。１）タスクは、実行ステップの上限を有する。２）タスクの各ステートメントは、実行時間の上限を有する。
【００３３】
要求１）を満たすために、各関数は、構文的に停止性が保証される形で書く。すなわち、選択(if then else)および順次（;) の組み合わせに展開可能となるように記述する。ループに関しては、反復回数に上限があるものだけが記述可能であり、実行時に反復回数が決まるループを書くことは許されない。不定回数のループは、図２のtaskA_CLKメソッドのように、固定回数のループを周期的に実行することにより実現する。この場合、選択（if then else)によりステップ数は変化するが、１周期で実行されるステップ数には上限が存在するので、要求１）が満たされる。
【００３４】
要求２）を満たすために問題となるのは、ステートメントが関数呼び出しを含む場合である。呼び出す関数が他のタスクのインタフェース関数である場合は、呼び出し先の関数についても実行ステップ数に上限があり、結果として実行時間に上限があるので、問題はない。一方、呼び出す関数が、ライブラリ関数やＯＳの機能を呼び出すＡＰＩなど、ＣＤＰに従わない関数である場合、実行時間に上限がない場合がある。
【００３５】
特に問題となるのが、ＯＳのＡＰＩに存在するblocking I/Oである。例えば、blocking I/O のREAD関数を用いてファイルの読み出しをする場合、ファイルの読み出しが完了するまで、呼び出し側プログラムに制御を戻さない。これでは、要求２）を満たすことができない。そこで、ＣＤＰのタスクでは、原則としてblocking I/Oの代わりに、non-blocking I/Oを用いる。あるいは、select関数等を用いてブロックされないことを確認した上でblocking I/Oを用いる。
【００３６】
続いて、図３に、図２に記載のtaskAを利用するtaskBのプログラム記述例を示す。taskBは、列挙型の変数state、int型のa、b、zをメンバとして含む構造体型の内部変数taskB_dataを持つ。taskBのタスク本体関数では、図３の行番号L34に示されるように、stateがstate_10の場合、calcメソッドを呼ぶことによりtaskAに処理を要求する。図２の行番号L23に示されるように、taskAの状態に従って要求が受け入れられる場合のみ、戻り値として0が返される。従って、taskBは、要求が受け入れられるまでリトライし、要求が受け入れられると、state_11に遷移する。
【００３７】
また、図３の行番号L40に示されるように、stateがstate_11の場合、get_resultメソッドを呼ぶことにより処理結果の取得を試みる。ここでも、図２の行番号L40に示されるように、taskAの状態に従って計算が終わっている場合のみ、戻り値として0が返される。従って、taskBは、戻り値として0が得られるまで、クロック毎にget_resultメソッドを呼び出し、処理結果を取得すると、state_12に遷移する。
【００３８】
（タスクの配列化）
図２の行番号L18に示されるように、taskAはstateがfreeである場合のみ、計算要求を受け入れる。つまり、taskAが先行する計算要求を受け入れ、計算を実行している間は、他のタスクからの計算要求を受け入れることはできない。そこで、同時に複数の計算要求を処理したい場合には、同一機能を持つ複数のタスクを用意するために、タスクを配列化したタスク配列を定義する。図４に、図２に記載のtaskAを配列化したタスク配列のプログラム記述例を示す。
【００３９】
図４の行番号L4に示されるように、タスク配列では、内部変数を配列化する。そして、行番号L7に示されるように、インタフェース関数calcの引数としてインデクスを受け取り、内部変数の参照、更新時には受け取ったインデクスを指定して行う。他の関数においても、同様に引数としてインデクスを受け取り、受け取ったインデクスを指定して内部変数の参照更新を行うことにより、タスクを配列化することができる。内部変数配列の要素数をタスク配列の多重度と呼び、配列化されていないタスク（例えば、図２のtaskA）の多重度は１である。
【００４０】
（ＰＥＲＴ図の作成）
タスクを記述したら、次にタスク間の先行関係を把握しＰＥＲＴ図を作成する。タイマーイベントハンドラーが呼び出すのは、タスク本体関数であり、タスク間の先行関係とは、タスク本体関数間の先行関係である。あるタスクは、そのタスク本体関数において、他のタスクのインタフェース関数を呼び出して、他のタスクの処理結果を取得する。例えば、図３に示すtaskBは、タスク本体関数において、taskAのget_resultメソッドを呼び出して、taskAの処理結果Ｆ（ｘ）yを取得する。このインタフェース関数の静的呼び出し関係を示したものが、図５のコールグラフである。
【００４１】
ここで、taskBが処理結果を得るためには、taskAのタスク本体関数がtaskBのタスク本体関数の実行の前に完了している必要がある。この場合、taskAはtaskBに先行する。完了順序を示すＰＥＲＴ図は、コールグラフの矢印の向きを逆転することにより得ることができる（図６）。しかし、全てのコールグラフからＰＥＲＴ図を得ることができるわけではない。
【００４２】
ＰＥＲＴ図を得るためには、コールグラフがacyclicである（ループがない）必要がある。図７に示すように、コールグラフがacyclicでない場合は、ポーリング（polling）を用いてタスク間のインタフェースの向きを入れ替える必要がある。taskAとtaskBとのコールグラフはacyclicであるので、タスク間のインタフェースの向きを入れ替える必要はない。ポーリングを用いる参考例として、図８Ａおよび図８Ｂに、インタフェース方向を変えたtaskAおよびtaskBのプログラム記述例を示す。
【００４３】
得られたＰＥＲＴ図から、同時実行され得るタスクを判断することができる。コールグラフに基づいて、図９に示すＰＥＲＴ図が得られたものとする。ここで、図９に示すＰＥＲＴ図のグラフＧは、１から９のタスクに対応するノードの集合、およびタスク間の先行関係を表す矢印の集合により構成される。ＰＥＲＴ図には、本来のタスク１から９に対応するノードに加えて、プログラム全体のスタートとフィニッシュをそれぞれ表す端点sと端点tが記されている。
【００４４】
図１０に、図９のＰＥＲＴ図に含まれるタスク間の先行関係を示す先行関係表を示す。図中の◎は、２つのタスクが、直接の先行関係を有することを示す。例えば、タスク１と（タスク１のインタフェース関数を呼び出す）タスク４、タスク１と（タスク１のインタフェース関数を呼び出す）タスク６などは、直接の先行関係を有する。図中の○は、２つのタスクが、間接の先行関係を有することを示す。例えば、タスク１とタスク７、タスク１とタスク８、タスク１とタスク９などは、間接の先行関係を有する。図中の×は、２つのタスクが、先行関係を有し得ないことを示す。
【００４５】
間接の先行関係は、直接の先行関係を有さないが、１または複数のタスクを経由して先行関係を有する２つのタスク間において生じる。例えば、タスク１とタスク７は、タスク１のインタフェース関数を呼び出し、かつタスク７によりそのインタフェース関数を呼び出されるタスク４を経由して、先行関係を有する。同様に、タスク１とタスク８も、タスク４を経由して先行関係を有する。また、タスク１とタスク９は、タスク４およびタスク７を経由して、あるいはタスク６を経由して、先行関係を有する。
【００４６】
ここで、特定のタスクｖのインタフェース関数を呼び出すタスクｕ、およびタスクｗが、直接または間接の先行関係を有する場合、タスクｕとタスクｗとは、同時実行されることはない。例えば、タスク１のインタフェース関数を呼び出すタスク４およびタスク６は、図１０に示されるように直接の先行関係を有するので、同時実行されることはない。一方、タスク３のインタフェース関数を呼び出すタスク５およびタスク８は、図１０に示されるように先行関係を有さないので、同時実行され得る。
【００４７】
複数のタスクが同時に同じタスクのインタフェース関数を呼び出す場合、タスクの実行される順序やインタフェース関数の実行される順序により、結果が変わってしまう可能性がある。そこで、複数のタスクから同時に呼び出され得るインタフェース関数は、Bernstein’s conditionsを満たす必要がある。Bernstein's conditionsは、プログラムの断片が並列実行できるための、周知の十分条件である。
【００４８】
例えば、タスク５およびタスク８から同時に呼び出され得る、タスク３に含まれる関数ｆ、ｇは、関数ｆの中で構文的に参照される内部変数の集合（Ｒ（ｆ））、関数ｆの中で構文的に代入される内部変数の集合（Ｗ（ｆ））、関数ｇの中で構文的に参照される内部変数の集合（Ｒ（ｇ））、および関数ｇの中で構文的に代入される内部変数の集合（Ｗ（ｇ））について以下の(1)から(3)が成り立つ場合、Bernstein's conditionsを満たし、並列実行することができる。
R(f) ∩ W(g) ＝ φ・・・(1)  
R(g) ∩ W(f) ＝ φ・・・(2)  
W(f) ∩ W(g) ＝ φ・・・(3)
（Bernstein's conditionsを満たすプログラムへの書き換え技法）
【００４９】
同時実行され得るタスクがBernstein's conditionsを満たさない場合、書き替え技法を用いてプログラムを修正する必要がある。代表的な３つの書き換え技法を以下で紹介する。
【００５０】
第１の書き替え技法として、変数リネーム技法がある。図１１Ａおよび図１１Ｂに、変数リネーム技法を適用する前後のプログラム記述例を示す。適用前のプログラム記述例では、図１１Ａに示されるように、インタフェース関数read、writeにおいて、Ｒ（read） ∩ Ｗ（write） ＝ {taskA_x} ≠ φであり、Bernstein's conditionsを満たさない。一方、適用後のプログラム記述例では、図１１Ｂに示されるように、別途内部変数を用いてプログラムを修正することにより、Ｒ（read） ∩ Ｗ（write） ＝φとなり、Bernstein's conditionsを満たすことができる。
【００５１】
第２の書き替え技法として、個別化技法がある。個別化技法では、Bernstein's conditionsを満たさないインタフェース関数を有するタスクを、配列化する。図１２に、個別化技法を適用する前後のコールグラフを示す。適用前のコールグラフでは、図１２（左）に示されるように、インタフェース関数calc_Fの競合がおき、Ｒ（calc_F） ∩ Ｗ（calc_F） ＝ {taskB_data} ≠ φであり、Bernstein's conditionsを満たさない。一方、適用後のコールグラフでは、図１２（右）に示されるように、taskBを配列化することにより、Ｒ（calc_F(0)) ∩ ）Ｗ（calc_F(1)） ＝ {taskB_data[0]} ∩ {taskB_data[1]} ＝ φとなり、Bernstein's conditionsを満たすことができる。
【００５２】
第３の書き替え技法として、抽選化技法がある。前述した個別化技法は、唯一のリソースを使用する場合には適用することができない。この場合、内部変数のみを配列化し、タスクは配列化しない抽選化技法により、インタフェース関数の競合を防ぐ。具体的には、図１３Ａに示されるように、競合対象であるtaskBのタスク本体関数において、複数のインタフェース関数呼び出しのうちの１つを選択し（抽選）、選択された（当選した）呼び出しのみ処理を実行し、選択されなかった（落選した）呼び出しについてはエラーを返す。また、図１３Ｂに示されるように、呼び出し側タスクであるtaskC（およびtaskD（図示せず））では、当選するまでインタフェース関数の呼び出しを繰り返す。
【００５３】
（スケジュールの作成）
ＰＥＲＴ図が得られたら、次にスケジュールを作成する。スケジュールは、どのタイミングでどのリソースにタスクを割り当てるかを、ＰＥＲＴ図で与えられた先行関係を満たすように定めたものである。利用可能なリソースの制約の元で、完了時間が最小となるスケジュールを作成することが望ましい。図１４に示すＰＥＲＴ図に基づいて、スケジュールを作成する。
【００５４】
（スケジュールの作成−逐次実行）
逐次実行する場合、ＰＥＲＴ図を既知のアルゴリズムでトポロジカルソートすることにより、容易にスケジュールを作成することができる。図１４のＰＥＲＴ図の場合、以下の３つのスケジュールが作成される。taskX、taskY、taskZ、taskWのタスク本体関数が、それぞれ、taskX_CLK()、taskY_CLK()、taskZ_CLK()、taskW_CLK()であるものとする。  
スケジュール１＝taskX_CLK(); taskY_CLK(); taskW_CLK(); taskZ_CLK();
スケジュール２＝taskX_CLK(); taskY_CLK(); taskZ_CLK(); taskW_CLK();
スケジュール３＝taskX_CLK(); taskZ_CLK(); taskY_CLK(); taskZ_CLK();
【００５５】
ＰＥＲＴ図の先行関係を満たす限り、どの順序で実行しても同一の結果を得ることができ、また、同一の完了時間となる。従って、任意のスケジュールを選択することができる。図１５に、スケジュール１でタスクを実行するプログラム記述例を示す。図１５の行番号L25において、第３引数（presiod）で指定した100ミリ秒ごとに、第４引数（OnTimer）で指定した関数が呼ばれるよう、タイマーの設定が行われている。本実施形態ではスケジュール１を実行するために、図１５の行番号L6からL9に示されるように、タスクの実行順序を定義する。
【００５６】
（スケジュールの作成−並列実行）
並列実行する場合、タスク間の先行関係は同期プリミティブを用いて実現する。本実施形態では、同期プリミティブとして、Windowsの提供するEvent Objectを用いる。Event Objectは、２つの状態（シグナル状態／非シグナル状態）を持つ。SetEvent(e)を呼び出すことにより、引数eのハンドルにより特定されるEvent Objectはシグナル状態になる。WaitForSingleObject(e)を呼び出すと、引数eのハンドルにより特定されるEvent Objectが非シグナル状態である場合、シグナル状態になるまでWaitForSingleObject(e)の呼び出し側スレッドは待機し続ける。他のスレッドによりSetEvent(e)が呼ばれ、eにより特定されるEvent Objectがシグナル状態になると、制御が戻され、呼び出し側スレッドは後続の処理を実行することができる。
【００５７】
例えば、図１４のＰＥＲＴ図を、並列度４で実行する場合を考える。  
スケジュール４−０＝taskX_CLK(); SetEvent(e1); SetEvent(e2);
スケジュール４−１＝WaitForSingleObject(e1); taskZ_CLK();
スケジュール４−２＝WaitForSingleObject(e2); taskY_CLK(); SetEvent(e3);
スケジュール４−３＝WaitForSingleObject(e3); taskW_CLK();
【００５８】
スケジュール４−０では、taskX_CLKメソッドが完了すると、e1およびe2により特定されるEvent Objectをシグナル状態にする。スケジュール４−１では、WaitForSingleObject(e1)を呼び出し、e1により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskX_CLKメソッドの完了によりSetEvent(e1)が呼ばれると、スケジュール４−１に対応するスレッドに制御が戻され、taskZ_CLKメソッドが実行される。同様に、スケジュール４−２では、WaitForSingleObject(e2)を呼び出し、e2により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskX_CLKメソッドの完了によりSetEvent(e2)が呼ばれると、スケジュール４−２に対応するスレッド制御が戻され、taskY_CLKメソッドが実行される。スケジュール４−２では、taskY_CLKメソッドが完了すると、e3により特定されるEvent Objectをシグナル状態にする。スケジュール４−３も、WaitForSingleObject(e3)を呼び出し、e3により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskY_CLKメソッドの完了によりSetEvent(e3)が呼ばれると、スケジュール４−３に対応するスレッドに制御が戻され、taskW_CLKメソッドが実行される。
【００５９】
図１６に、スケジュール４−０から４−３でタスクを実行するプログラム記述例を示す。図１６の行番号L43において、第３引数（presiod）で指定した100ミリ秒ごとに、第４引数（OnTimer）で指定した関数が呼ばれるよう、タイマーの設定が行われている。本実施形態では、図１６の行番号L3からL14に示されるように、スケジュール４−１から４−３に対応するスレッドを用意する。
【００６０】
OnTimerメソッドでは、まず、スレッド１、スレッド２、スレッド３にそれぞれ対応するs[0]、s[1]、s[2]により特定されるEvent Objectをシグナル状態にする。その後、メインスレッドでスケジュール４−０を実行し、スレッド１、スレッド２、スレッド３にそれぞれ対応するt[0]、t[1]、t[2]により特定されるEvent Object のWaitForSingleObjectメソッドを呼び出すことで、Event Objectがシグナル状態になるまで、すなわち該当のスレッドが完了するまで待機し続ける。図１７に、並列実行のシーケンス図を示す。
【００６１】
スケジュール４−１に対応するスレッド１では、WaitForSingleObject(s[0])を呼び出し、s[0]により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。図１６の行番号L18に示されるように、OnTimerメソッド内でSetEvent(s[0])が呼ばれると、スレッド１に制御が戻され、WaitForSingleObject(e1)を呼び出す。その後、e1により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskX_CLKメソッドの完了によりSetEvent(e1)が呼ばれると、スレッド１に制御が戻され、taskZ_CLKメソッドが実行される。スレッド１では、taskZ_CLKメソッドが完了すると、t[0]により特定されるEvent Objectをシグナル状態にすることで、スレッドの完了を通知する。
【００６２】
スケジュール４−２に対応するスレッド２（図示せず）においても、スレッド１同様、WaitForSingleObject(s[1])を呼び出し、s[1]により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。図１６の行番号L19に示されるように、OnTimerメソッド内でSetEvent(s[1])が呼ばれると、スレッド２に制御が戻され、WaitForSingleObject(e2)を呼び出す。その後、e2により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskX_CLKメソッドの完了によりSetEvent(e2)が呼ばれると、スレッド２に制御が戻され、taskY_CLKメソッドが実行される。スレッド２では、taskY_CLKメソッドが完了すると、taskYの完了を通知するSetEvent(e3)を呼び出し、その後、t[1]により特定されるEvent Objectをシグナル状態にすることで、スレッドの完了を通知する。
【００６３】
スケジュール４−３に対応するスレッド３（図示せず）においても、スレッド１同様、WaitForSingleObject(s[2])を呼び出し、s[2]により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。図１６の行番号L20に示されるように、OnTimerメソッド内でSetEvent(s[2])が呼ばれると、スレッド３に制御が戻され、WaitForSingleObject(e3)を呼び出す。その後、e3により特定されるEvent Objectがシグナル状態になるまで、待機し続ける。taskY_CLKメソッドの完了によりSetEvent(e3)が呼ばれると、スレッド３に制御が戻され、taskW_CLKメソッドが実行される。スレッド３では、taskW_CLKメソッドが完了すると、t[2]により特定されるEvent Objectをシグナル状態にすることで、スレッドの完了を通知する。
【００６４】
（スケジュールの作成−タスク配列）
タスク配列内の各タスク間に先行関係は存在しない。そのため、各タスクをどのような順序でスケジューリングしてもよい。また、タスク配列は、コードは全て同じで、内部変数の場所だけが異なるので、タスク配列内の各タスクの平均の実行時間は、同一であることが期待できる。従って、タスクの多重度がｍ、利用可能なＣＰＵ数がｎである場合、各ＣＰＵにｍ／ｎ個ずつタスクを分配する。
【００６５】
図１４に示すＰＥＲＴ図のtaskYが多重度４のタスク配列で、利用可能なＣＰＵ数が５である場合、以下のスケジュールを作成することができる。  
スケジュール５−０＝taskX_CLK(); SetEvent(e1); SetEvent(e21); SetEvent(e22);
スケジュール５−１＝WaitForSingleObject(e1); taskZ_CLK();
スケジュール５−２＝WaitForSingleObject(e21); taskY_CLK(0); taskY_CLK(2); 
SetEvent(e31);
スケジュール５−３＝WaitForSingleObject(e22); taskY_CLK(1); taskY_CLK(3); 
SetEvent(e32);
スケジュール５−４＝WaitForSingleObject(e31); WaitForSingleObject(e32); 
taskW_CLK();
【００６６】
このように、多重度の数だけ存在するタスク本体関数をインデックス指定して、各ＣＰＵに分配することにより、利用可能なＣＰＵ数に応じてスケジュールを作成することができる。
【００６７】
（ＣＤＰプログラムの性能）
上述のＣＤＰプログラムの性能は、プログラムを代表するタスクのスループットＰ（tps）として、以下の式で求めることができる。
【００６８】
【数２】
0005480322.tif 000003
【００６９】
mはタスクの多重度（同一機能を有するタスクの数）、ｃは一単位処理あたりに呼ばれるタスク本体関数の数(Clocks Per Transaction：ＣＰＴ)、ｆはプログラム駆動周波数（タイマーの周期Ｔの逆数）であり、ここで、周期Ｔを保ってタスク本体関数を呼び出すために、デューティ率は１未満である必要がある。
【００７０】
図２に記述されるtaskAのように、ＣＰＴが変動する場合、平均値を用いる。taskAは、前述のように、固定回数のループを周期的に実行することにより、不定回数のループを実現する。本実施形態では、stateがcalc2の場合にＦ（ｘ）yを計算するが、図２の行番号L62に示されるように、calcメソッドの第２引数yにより指定される不定回数のループを、定数LIMITにより指定される上限で周期的に実行する。
【００７１】
従って、１≦y≦１０１の場合、タスク本体関数は、stateがcalc1で１回、stateがcalc2で１回、合計２回呼ばれ、ＣＰＴは２となる。１０１≦y≦２０１の場合、タスク本体関数は、stateがcalc1で１回、stateがcalc2で２回、合計３回呼ばれ、ＣＰＴは３となる。例えば、ＣＰＴが２となる確率が５０％、ＣＰＴが３となる確率が５０％の場合、ＣＰＴは２．５となる。
【００７２】
ＣＤＰでは、デューティ率が１未満である限り、プログラム駆動周波数ｆに比例するスループットを保証することができる。ＣＤＰでの実行環境の性能差は、デューティ率の差として現れる。プログラムを同一のプログラム駆動周波数で実行する場合、低速ＣＰＵでは、高速ＣＰＵと比べてデューティ率が高くなる。しかし、デューティ率に差はあっても、同一のプログラム駆動周波数であれば、性能は同じである。
【００７３】
ここまで、ＣＤＰプログラムについて詳述してきた。特に、ＣＤＰプログラムの性能の章では、デューティ率が１未満である限り、ＣＤＰプログラムは、プログラム駆動周波数ｆに比例するスループットを保証することができる点について述べている。以降の章では、システムの性能上限を実行環境の許す範囲で制御する技術を開示する。
【００７４】
（システム構成）
図１８のブロック図を参照して、性能制御システム１０１の構成を詳細に説明する。なお、図１８では、単一のコンピュータシステムを想定し、必要な機能構成だけを示しているが、スケジュール作成システム１を、複数のコンピュータシステムによる多機能の分散システムの一部として構成することもできる。
【００７５】
性能制御システム１０１は、ＣＰＵ１０に、システムバス１１を介してＲＡＭ１２、入力装置１３、出力装置１４、通信制御装置１５および不揮発性記憶媒体（ＲＯＭやＨＤＤなど）で構成される記憶装置１６が接続された構成を有する。記憶装置１６は、上記した機能を奏するためのソフトウェアプログラムを格納するプログラム格納領域と、随時取得するデータや処理結果としてのデータ等を格納するデータ格納領域とを備えている。以下に説明するプログラム格納領域の各手段は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、ＣＰＵ１０によって記憶装置１６から呼び出されＲＡＭ１２のワークエリアに展開されて、データベース等を適宜参照しながら順次実行されることで、各機能を奏するものである。
【００７６】
データ格納領域は、スケジュール記憶手段１７および周波数記憶手段１８を備える。何れも、記憶装置１６内に確保された一定の記憶領域である。
【００７７】
スケジュール記憶手段１７は、図１９に示すように、並列度およびその並列度に対応するスケジュールを格納する。スケジュールには、例えば、（スケジュールの作成）の章において開示されるようなスケジュールの文字列を直接格納することもできるし、対応するスケジュールの参照先を格納することもできる。
【００７８】
周波数記憶手段１８は、プログラム駆動周波数の下限および上限を格納する。プログラム駆動周波数の下限およびプログラム駆動周波数の上限については後述する。
【００７９】
プログラム格納領域に格納されているソフトウェアプログラムは、本発明に関連するものだけを列挙すると、デューティ率監視手段１９、並列度管理手段２０、周波数管理手段２１、プログラム再開手段２２、入力量監視手段２３およびデューティ率予測手段２４を備えている。
【００８０】
デューティ率監視手段１９は、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超えているか否か判定する。デューティ率については、タイマーイベントハンドラーの入口および出口で時刻を計測し、その差分から実行時間τを求め、この実行時間τを周期Ｔで割ることにより求めることができる。
【００８１】
並列度管理手段２０は、スケジュール記憶手段１７に基づいて、並列度を高くすることが可能か否か判定する。並列度を高くすることが可能である場合、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定する。本実施形態では、現在の並列度より高いスケジュールのうち、並列度が最も低い並列度のスケジュールを選択し、変更後のスケジュールとして決定する。
【００８２】
また、並列度管理手段２０は、スケジュール記憶手段１７に基づいて、並列度を低くすることが可能か否か判定する。並列度を低くすることが可能である場合、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より低いスケジュールを選択する。本実施形態では、現在の並列度より低いスケジュールのうち、並列度が最も高い並列度のスケジュールを選択する。
【００８３】
周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が下限であるか否か判定する。プログラム駆動周波数が下限でない場合、周波数管理手段２１は、タイムスライスに基づいて、現在より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定する。本実施形態では、現在のプログラム駆動周波数より１段階低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定する。
【００８４】
また、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が上限であるか否か判定する。プログラム駆動周波数が上限でない場合、周波数管理手段２１は、タイムスライスに基づいて、現在より高いプログラム駆動周波数を算出する。本実施形態では、現在のプログラム駆動周波数より１段階高いプログラム駆動周波数を算出する。
【００８５】
プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、変更後の並列度、または変更後のプログラム駆動周波数でプログラムを再開することができる。
【００８６】
入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。入力量の基準値には、例えば、単位時間当たりの処理要求の数、または処理対象のデータ量など、実行中のプログラムに合った所望の基準値を用いることができる。
【００８７】
デューティ率予測手段２４は、現在のデューティ率Ｄに基づいて、変更予定の条件でプログラムを実行した場合の予測デューティ率Ｄ’を求める。本実施形態では、変更予定のプログラム駆動周波数、または変更予定の並列度でプログラムを実行した場合の予測デューティ率Ｄ’を求めることができる。
【００８８】
また、デューティ率予測手段２４は、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているか否かを判定する。Ｄ’がＤLを超えていない場合、デューティ率予測手段２４は、予測デューティ率Ｄ’の計算に用いた変更予定の条件を、変更後の条件として決定する。
【００８９】
（事前準備−プログラム駆動周波数の上限決定）
システムの性能上限を動的に制御するために、プログラム駆動周波数の上限および下限を決定する。実行時には、この上限および下限の範囲内で、プログラム駆動周波数が動的に決定される。
【００９０】
プログラム駆動周波数の上限は、２つの要因に基づいて決定することができる。第１の要因はプログラムの性能要件であり、第２の要因はＯＳが提供可能なクロック分解能である。例えば、スループットＰ＝１０，０００（tps）がプログラムの性能要件であり、タスクの多重度m＝８００、ＣＰＴ＝４の場合、前述の数２を利用して、５０Ｈｚのプログラム駆動周波数が求められる。
【００９１】
【数３】
0005480322.tif 000004
【００９２】
次に、第２の要因であるＯＳが提供可能なクロック分解能について考える。マルチタスクＯＳでは、ＯＳのタイムスライスによりクロック分解能が制約される。例えば、ＯＳのタイムスライスが１０ミリ秒の場合、５０Ｈｚをクロック分解上表現することができる。一方、ＯＳのタイムスライスが１６ミリ秒の場合には、５０Ｈｚをクロック分解上表現することができない。そこで、クロック分解上表現できない場合は、第１の要因において求めたプログラム駆動周波数（５０Ｈｚ）より高く、クロック分解能上表現可能なプログラム駆動周波数（６２．５Ｈｚ）をプログラム駆動周波数の上限とすることが望ましい。
【００９３】
（事前準備−プログラム駆動周波数の下限決定）
次に、プログラム駆動周波数の下限を決定する。プログラム駆動周波数の下限は、プログラムの応答時間要件に基づいて決定することができる。応答時間要件Ｒ（秒）、周期Ｔ（秒）、ＣＰＴ：ｃとした場合、ＣＤＰプログラムでは、イベントの発生から処理を開始するまでに最大１クロックの遅れがあることを考慮して、以下の条件を満たす必要がある。
【００９４】
【数４】
0005480322.tif 000005
例えば、応答時間要件Ｒ＝３（秒）、ＣＰＴ＝４の場合、数４を利用して、１．６７Ｈｚ以上のプログラム駆動周波数が必要となることがわかる。
【００９５】
【数５】
0005480322.tif 000006
【００９６】
一実施形態では、余裕をみて、２Ｈｚをプログラム駆動周波数の下限とすることができる。
【００９７】
（事前準備−並列度の異なる複数のスケジュール作成）
ＣＤＰプログラムでは、前述したように、周期Ｔを保ってプログラムを実行するために、デューティ率Ｄは１未満である必要がある。すなわち、０％＜Ｄ＜１００％のデューティ率であれば、周期Ｔを保ってプログラムを実行することができると言える。しかし実際には、システムを安定稼働させるために、デューティ率の上限であるＤLを設定して、８０％≦ＤL≦９０％とすることが望ましい。
【００９８】
デューティ率の制約を守ってプログラムを実行するために制御可能な要素は、周期Ｔ（すなわちプログラム駆動周波数ｆ）または実行時間τである。プログラム駆動周波数ｆは、前述したプログラム駆動周波数の上限および下限の範囲内で決定することができる。一方、実行時間τについては、プログラムの並列度を高くすることにより、実行時間の短縮が期待できる。従って、プログラムが同時実行され得るタスクを含む場合には、並列度の異なる複数のスケジュールを作成することが性能を制御するために有用である。
【００９９】
（性能制御方法−デューティ率の上限ＤLオーバー）
次に、図２０のフローチャートを参照して、本実施形態に係る性能を制御する工程を説明する。本実施形態では、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超える場合に性能を制御する場合について説明する。まず初めに、並列度を高くすることによりデューティ率オーバーに対処する実施形態１−１について説明する。実施形態１−１では、プログラム駆動周波数の下限を２Ｈｚ、プログラム駆動周波数の上限を５０Ｈｚ、デューティ率の上限ＤLを９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）は４つのＣＰＵを有し、現在１つのＣＰＵを用いてプログラム駆動周波数５０Ｈｚで逐次実行しているものとする。
【０１００】
処理Ｓ１において、デューティ率監視手段１９は、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超えているか否か判定する。ＤがＤLを超えている場合、処理Ｓ２に進み、超えていない場合には処理を終了する。本実施形態では、プログラム駆動周波数５０Ｈｚ（すなわち周期２０ミリ秒）でプログラムを実行中、実行時間が１９ミリ秒となり、デューティ率Ｄ（９５％）がデューティ率の上限ＤL（９０％）を超え、処理Ｓ２に進む。
【０１０１】
処理Ｓ２において、並列度管理手段２０は、スケジュール記憶手段１７および現在の芸列度に基づいて、並列度を高くすることが可能か否か判定する。並列度を高くすることが可能である場合、処理Ｓ３に進み、不可能である場合には処理Ｓ５に進む。本実施形態では、図１９に示されるように、スケジュール記憶手段１７には、並列度１から並列度４のスケジュールが格納されている。並列度管理手段２０は、スケジュール記憶手段１７に基づいて、現在の並列度１より高い並列度のスケジュールが存在するので、処理Ｓ３に進む。
【０１０２】
処理Ｓ３において、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定する。本実施形態では、現在の並列度１より高いスケジュールのうち、並列度が最も低い並列度２のスケジュールを選択し、変更後のスケジュールとして決定する。
【０１０３】
処理Ｓ４において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、並列度２のスケジュールでプログラムを再開する。
【０１０４】
処理Ｓ４の後、処理Ｓ１に再度戻り、デューティ率監視手段１９は、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超えているか否か判定する。本実施形態では、並列度の高い（並列度２）スケジュールでプログラムを実行することにより、実行時間が１５ミリ秒となり、デューティ率の上限ＤL（９０％）をＤ（７５％）が下回るので処理を終了する。
【０１０５】
次に、プログラム駆動周波数を低くすることにより、デューティ率オーバーに対処する実施形態１−２について説明する。プログラム駆動周波数の下限、プログラム駆動周波数の上限およびデューティ率の上限ＤLは、実施形態１−１同様、それぞれ２Ｈｚ、５０Ｈｚ、および９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）が有する４つのＣＰＵのうち、現在４つのＣＰＵを用いてプログラム駆動周波数５０Ｈｚで並列実行しているものとする。
【０１０６】
処理Ｓ１において、デューティ率監視手段１９は、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超えているか否か判定する。本実施形態では、プログラム駆動周波数５０Ｈｚ（すなわち周期２０ミリ秒）でプログラムを実行中、実行時間が１９ミリ秒となり、デューティ率Ｄ（９５％）がデューティ率の上限ＤL（９０％）を超え、処理Ｓ２に進む。
【０１０７】
処理Ｓ２において、並列度管理手段２０は、スケジュール記憶手段１７および現在の並列度に基づいて、並列度を高くすることが可能か否か判定する。本実施形態では、図１９に示されるように、スケジュール記憶手段１７には、並列度１から並列度４のスケジュールが格納されている。本実施形態では、現在の並列度４より高い並列度は存在しないので、処理Ｓ５に進む。
【０１０８】
処理Ｓ５において、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が下限であるか否か判定する。プログラム駆動周波数が下限でない場合、処理Ｓ６に進み、下限である場合には処理Ｓ７に進む。本実施形態では、現在のプログラム駆動周波数５０Ｈｚはプログラム駆動周波数の下限（２Ｈｚ）でないので、処理Ｓ６に進む。
【０１０９】
処理Ｓ６において、周波数管理手段２１は、タイムスライスに基づいて、現在より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定する。本実施形態では、現在のプログラム駆動周波数５０Ｈｚ（すなわち周期２０ミリ秒）およびタイムスライス（１０ミリ秒）に基づいて、１段階低いプログラム駆動周波数３３．３Ｈｚ（すなわち周期３０ミリ秒）を算出し、変更後のプログラム駆動周波数として決定する。
【０１１０】
処理Ｓ４において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、プログラム駆動周波数３３．３Ｈｚでプログラムを再開する。
【０１１１】
処理Ｓ４の後、処理Ｓ１に再度戻り、デューティ率監視手段１９は、実行中のプログラムのデューティ率Ｄがデューティ率の上限ＤLを超えているか否か判定する。本実施形態では、プログラム駆動周波数を低くしてプログラムを実行することにより、デューティ率の上限ＤL（９０％）をデューティ率Ｄが下回るので処理を終了する。
【０１１２】
なお、並列度を高くすることもプログラム駆動周波数を低くすることもできず、処理Ｓ７に進んだ場合、デューティ率オーバー時の規定の処理を実行する。一実施形態では、プログラムの実行を強制的に終了することができる。別の実施形態では、デューティ率がオーバーしていることを示すメッセージの出力、またはログの書き込みなどを行うことができる。
【０１１３】
図２０の制御フローから明らかであるように、本発明では、プログラム駆動周波数を低くすること、および並列度を高くすることのうち、後者を優先してデューティ率の上限ＤLオーバーに対処する。具体的には、並列度を高くすることで対処可能な間は並列度により対処し、並列度を高くできなくなった時点で初めて、プログラム駆動周波数を低くすることを検討する。これは、現在提供している（もしくはこれから提供しようとしている）性能を維持しながら、問題に対処することを目的としているからである。実施形態１−１では、特定の性能を維持しながらシステムを安定稼働させるために必要な最少の並列度、すなわちＣＰＵの数を得ることができる。また、実施形態１−２では、特定の性能を維持しながらシステムを安定稼働させることができない場合に、システムを安定稼働させながら提供可能な最高のプログラム駆動周波数を得ることができる。
【０１１４】
（性能制御方法−入力量過多）
次に、図２１のフローチャートを参照して、本実施形態に係る性能を制御する工程を説明する。本実施形態では、実行中のプログラムの入力量が過多である場合に性能を制御する場合について説明する。まず初めに、プログラム駆動周波数を高くすることにより入力量過多に対処する実施形態２−１について説明する。実施形態２−１では、プログラム駆動周波数の下限を２Ｈｚ、プログラム駆動周波数の上限を５０Ｈｚ、デューティ率の上限ＤLを９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）は４つのＣＰＵを有し、現在１つのＣＰＵを用いてプログラム駆動周波数５Ｈｚで逐次実行しているものとする。
【０１１５】
処理Ｓ１において、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。入力量が基準値を超えている場合、処理Ｓ２に進み、超えていない場合には処理を終了する。本実施形態では、基準値を超え、処理Ｓ２に進むものとする。
【０１１６】
処理Ｓ２において、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が上限であるか否か判定する。プログラム駆動周波数が上限である場合、処理Ｓ３に進み、上限でない場合には処理Ｓ４に進む。本実施形態では、現在のプログラム駆動周波数５Ｈｚはプログラム駆動周波数の上限（５０Ｈｚ）でないので、処理Ｓ４に進む。処理Ｓ３については後述する。
【０１１７】
処理Ｓ４において、周波数管理手段２１は、タイムスライスに基づいて、現在より高いプログラム駆動周波数を算出する。本実施形態では、現在のプログラム駆動周波数５Ｈｚ（すなわち周期２００ミリ秒）およびタイムスライス（１０ミリ秒）に基づいて、１段階高いプログラム駆動周波数５．３（すなわち周期１９０ミリ秒）を算出する。
【０１１８】
処理Ｓ５において、デューティ率予測手段２４は、現在のデューティ率Ｄに基づいて、処理Ｓ４で算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率Ｄ’を求める。本実施形態では、プログラム駆動周波数５Ｈｚ（すなわち周期２００ミリ秒）でプログラムを実行中、実行時間が１００ミリ秒で、現在のデューティ率は５０％であるものとする。この場合、現在の周期をＴ、タイムスライスΔとすると、１段階高いプログラム駆動周波数でプログラムを実行した場合の予測デューティ率Ｄ’を以下の式で算出することができる。
【０１１９】
【数６】
0005480322.tif 000007
【０１２０】
本実施形態では、１段階高いプログラム駆動周波数５．３（すなわち周期１９０ミリ秒）でプログラムを実行すると、予測デューティ率Ｄ’は５３％となる。
【０１２１】
処理Ｓ６において、デューティ率予測手段２４は、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているか否かを判定する。Ｄ’がＤLを超えていない場合、処理Ｓ７に進み、超えている場合には処理Ｓ９に進む。本実施形態では、予測デューティ率Ｄ’（５３％）がデューティ率の上限ＤL（９０％）を下回るので、処理Ｓ７に進む。
【０１２２】
処理Ｓ７において、デューティ率予測手段２４は、処理Ｓ４で算出したプログラム駆動周波数を、変更後のプログラム駆動周波数として決定する。本実施形態では、５．３Ｈｚを変更後のプログラム駆動周波数として決定する。
【０１２３】
処理Ｓ８において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、プログラム駆動周波数５．３Ｈｚでプログラムを再開する。
【０１２４】
処理Ｓ８の後、処理Ｓ１に再度戻り、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。本実施形態では、プログラム駆動周波数を高くしてプログラムを実行することにより、入力量は基準値未満となり、処理を終了する。
【０１２５】
次に、並列度を高くすることより入力量過多に対処する実施形態２−２について説明する。プログラム駆動周波数の下限、プログラム駆動周波数の上限およびデューティ率の上限ＤLは、実施形態２−１同様、それぞれ２Ｈｚ、５０Ｈｚ、および９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）は４つのＣＰＵを有し、現在１つのＣＰＵを用いてプログラム駆動周波数９．１Ｈｚで逐次実行しているものとする。
【０１２６】
処理Ｓ１において、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。本実施形態では、基準値を超え、処理Ｓ２に進むものとする。
【０１２７】
処理Ｓ２において、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が上限であるか否か判定する。本実施形態では、現在のプログラム駆動周波数９．１Ｈｚはプログラム駆動周波数の上限（５０Ｈｚ）でないので、処理Ｓ４に進む。
【０１２８】
処理Ｓ４において、周波数管理手段２１は、タイムスライスに基づいて、現在より高いプログラム駆動周波数を算出する。本実施形態では、現在のプログラム駆動周波数９．１Ｈｚ（すなわち周期１１０ミリ秒）およびタイムスライス（１０ミリ秒）に基づいて、１段階高いプログラム駆動周波数１０（すなわち周期１００ミリ秒）を算出する。
【０１２９】
処理Ｓ５において、デューティ率予測手段２４は、現在のデューティ率Ｄに基づいて、処理Ｓ４で算出したプログラム駆動周波数でプログラムを実行した場合の予測デューティ率Ｄ’を求める。本実施形態では、プログラム駆動周波数９．１Ｈｚ（すなわち周期１１０ミリ秒）でプログラムを実行中、実行時間が９５ミリ秒で、現在のデューティ率は８６％であるものとする。この場合、１段階高いプログラム駆動周波数１０（すなわち周期１００ミリ秒）でプログラムを実行すると、予測デューティ率Ｄ’は９５％となる。
【０１３０】
処理Ｓ６において、デューティ率予測手段２４は、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているか否かを判定する。本実施形態では、予測デューティ率Ｄ’（９５％）がデューティ率の上限ＤL（９０％）を超えているので、処理Ｓ９に進む。
【０１３１】
処理Ｓ９において、並列度管理手段２０は、スケジュール記憶手段１７および現在の並列度に基づいて、並列度を高くすることが可能か否か判定する。並列度を高くすることが可能である場合、処理Ｓ１０に進み、不可能である場合には処理Ｓ３に進む。本実施形態では、図１９に示されるように、スケジュール記憶手段１７には、並列度１から並列度４のスケジュールが格納されている。本実施形態では、現在の並列度１より高い並列度のスケジュールが存在するので、処理Ｓ１０に進む。
【０１３２】
処理Ｓ１０において、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より高いスケジュールを選択し、変更後のスケジュールとして決定する。本実施形態では、現在の並列度１より高いスケジュールのうち、並列度が最も低い並列度２のスケジュールを選択し、変更後のスケジュールとして決定する。
【０１３３】
処理Ｓ８において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、並列度２のスケジュールでプログラムを再開する。
【０１３４】
処理Ｓ８の後、処理Ｓ１に再度戻り、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。本実施形態では、並列度の高いスケジュール（並列度２）でプログラムを実行することにより、入力量は基準値未満となり、処理を終了する。
【０１３５】
なお、プログラム駆動周波数を高くすることも並列度を高くすることもできず、処理Ｓ３に進んだ場合、入力量過多時の規定の処理を実行する。一実施形態では、プログラムの実行を強制的に終了することができる。別の実施形態では、入力量が過多であることを示すメッセージの出力、またはログの書き込みなどを行うことができる。
【０１３６】
図２１の制御フローから明らかであるように、本発明では、プログラム駆動周波数を高くすること、および並列度を高くすることのうち、前者を優先して入力量過多に対処する。具体的には、まずは、プログラム駆動周波数を高くすることで対処可能な間はプログラム駆動周波数により対処し、プログラム駆動周波数を高くできなくなった時点で初めて、並列度を高くすることを検討する。
【０１３７】
ここで、前述したように、プログラムの並列度を高くすると、実行時間の短縮が期待できる。例えば、実施形態２−２の処理Ｓ６では、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているので、処理Ｓ１０で並列度を高くしている。しかし、実施形態２−２の処理Ｓ１０を経た後、再度入力量過多を検出して処理Ｓ６に至った場合には、実行時間が短縮されているので、再び、プログラム駆動周波数により対処できる可能性が生まれる。すなわち、本発明では、システムを安定稼働させながら、並列度での対処を最小限に抑えて問題に対処することができる。
【０１３８】
このように性能を制御することにより、システムを安定稼働させながら、入力量に応じてシステムの性能を上げることができる。また、制御に当たっては、不必要に並列度を高くすることを回避することができる。
【０１３９】
（性能制御方法−入力量過少）
次に、図２２のフローチャートを参照して、本実施形態に係る性能を制御する工程を説明する。本実施形態では、実行中のプログラムの入力量が過少である場合に性能を制御する場合について説明する。まず初めに、並列度を低くすることにより入力量過少に対処する実施形態３−１について説明する。実施形態３−１では、プログラム駆動周波数の下限を２Ｈｚ、プログラム駆動周波数の上限を５０Ｈｚ、デューティ率の上限ＤLを９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）は４つのＣＰＵを有し、現在２つのＣＰＵを用いてプログラム駆動周波数５Ｈｚで並列実行しているものとする。
【０１４０】
処理Ｓ１において、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を下回っているか否か判定する。入力量が基準値を下回っている場合、処理Ｓ２に進み、下回っていない場合には処理を終了する。本実施形態では、基準値を下回り、処理Ｓ２に進むものとする。
【０１４１】
処理Ｓ２において、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が下限であるか否か判定する。プログラム駆動周波数が下限である場合、処理Ｓ３に進み、下限でない場合には処理Ｓ４に進む。本実施形態では、現在のプログラム駆動周波数５Ｈｚはプログラム駆動周波数の下限（２Ｈｚ）でないので、処理Ｓ４に進む。処理Ｓ３については後述する。
【０１４２】
処理Ｓ４において、並列度管理手段２０は、スケジュール記憶手段１７および現在の並列度に基づいて、並列度を低くすることが可能か否か判定する。並列度を低くすることが可能である場合、処理Ｓ５に進み、不可能である場合には処理Ｓ１０に進む。本実施形態では、図１９に示されるように、スケジュール記憶手段１７には、並列度１から並列度４のスケジュールが格納されている。本実施形態では、現在の並列度２より低い並列度のスケジュールが存在するので、処理Ｓ５に進む。
【０１４３】
処理Ｓ５において、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より低いスケジュールを選択する。本実施形態では、現在の並列度２より低いスケジュールのうち、並列度が最も高い並列度１のスケジュールを選択する。
【０１４４】
処理Ｓ６において、デューティ率予測手段２４は、現在のデューティ率Ｄに基づいて、処理Ｓ５で選択した並列度でプログラムを実行した場合の予測デューティ率Ｄ’を求める。本実施形態では、プログラム駆動周波数５Ｈｚ（すなわち周期２００ミリ秒）でプログラムを実行中、実行時間が８０ミリ秒で、現在のデューティ率は４０％であるものとする。この場合、現在のスケジュールの並列度をＰ、変更予定のスケジュールの並列度をＰ’とすると、予測デューティ率Ｄ’を以下の式で算出することができる。
【０１４５】
【数７】
0005480322.tif 000008
【０１４６】
本実施形態では、現在並列度（並列度２）より１段階低いスケジュール（並列度１）でプログラムを実行すると、予測デューティ率Ｄ’は８０％となる。
【０１４７】
処理Ｓ７において、デューティ率予測手段２４は、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているか否かを判定する。Ｄ’がＤLを超えていない場合、処理Ｓ８に進み、超えている場合には処理Ｓ１０に進む。本実施形態では、予測デューティ率Ｄ’（８０％）がデューティ率の上限ＤL（９０％）を下回るので、処理Ｓ８に進む。
【０１４８】
処理Ｓ８において、デューティ率予測手段２４は、処理Ｓ５で選択したスケジュールを、変更後のスケジュールとして決定する。本実施形態では、並列度１のスケジュールを変更後のスケジュールとして決定する。
【０１４９】
処理Ｓ９において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、並列度１のスケジュールでプログラムを再開する。
【０１５０】
処理Ｓ９の後、処理Ｓ１に再度戻り、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。本実施形態では、並列度の低いスケジュールでプログラムを実行することにより、入力量は基準値を超え、処理を終了する。
【０１５１】
次に、プログラム駆動周波数を低くすることより入力量過少に対処する実施形態３−２について説明する。プログラム駆動周波数の下限、プログラム駆動周波数の上限およびデューティ率の上限ＤLは、実施形態３−１同様、それぞれ２Ｈｚ、６４Ｈｚ、および９０％に設定しているものとする。また、実行環境のサーバ（タイムスライス：１０ミリ秒）は４つのＣＰＵを有し、現在２つのＣＰＵを用いてプログラム駆動周波数５Ｈｚで並列実行しているものとする。
【０１５２】
処理Ｓ１において、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を下回っているか否か判定する。本実施形態では、基準値を下回り、処理Ｓ２に進むものとする。
【０１５３】
処理Ｓ２において、周波数管理手段２１は、周波数記憶手段１８に基づいて、プログラム駆動周波数が下限であるか否か判定する。本実施形態では、現在のプログラム駆動周波数５Ｈｚはプログラム駆動周波数の下限（２Ｈｚ）でないので、処理Ｓ４に進む。
【０１５４】
処理Ｓ４において、並列度管理手段２０は、スケジュール記憶手段１７および現在の並列度に基づいて、並列度を低くすることが可能か否か判定する。本実施形態では、図１９に示されるように、スケジュール記憶手段１７には、並列度１から並列度４のスケジュールが格納されている。本実施形態では、現在の並列度２より低い並列度のスケジュールが存在するので、処理Ｓ５に進む。
【０１５５】
処理Ｓ５において、並列度管理手段２０は、スケジュール記憶手段１７から現在の並列度より低いスケジュールを選択する。本実施形態では、現在の並列度２より低いスケジュールのうち、並列度が最も高い並列度１のスケジュールを選択する。
【０１５６】
処理Ｓ６において、デューティ率予測手段２４は、現在のデューティ率Ｄに基づいて、処理Ｓ５で選択した並列度でプログラムを実行した場合の予測デューティ率Ｄ’を求める。本実施形態では、プログラム駆動周波数５Ｈｚ（すなわち周期２００ミリ秒）でプログラムを実行中、実行時間が１００ミリ秒で、現在のデューティ率は５０％であるものとする。この場合、数６により予測デューティ率Ｄ’を求めると、１００％となる。
【０１５７】
処理Ｓ７において、デューティ率予測手段２４は、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているか否かを判定する。本実施形態では、予測デューティ率Ｄ’（１００％）がデューティ率の上限ＤL（９０％）を超えているので、処理Ｓ１０に進む。
【０１５８】
処理Ｓ１０において、周波数管理手段２１は、タイムスライスに基づいて、現在より低いプログラム駆動周波数を算出して、変更後のプログラム駆動周波数として決定する。本実施形態では、現在のプログラム駆動周波数５Ｈｚ（すなわち周期２００ミリ秒）およびタイムスライス（１０ミリ秒）に基づいて、１段階低いプログラム駆動周波数４．８Ｈｚ（すなわち周期２１０ミリ秒）を算出し、変更後のプログラム駆動周波数として決定する。
【０１５９】
処理Ｓ９において、プログラム再開手段２２は、変更後の条件でプログラムを再開する。本実施形態では、プログラム駆動周波数４．８Ｈｚでプログラムを再開する。
【０１６０】
処理Ｓ９の後、処理Ｓ１に再度戻り、入力量監視手段２３は、実行中のプログラムに対する入力量が所定の基準値を超えているか否か判定する。本実施形態では、プログラム駆動周波数を低くしてプログラムを実行することにより、入力量は基準値を超え、処理を終了する。
【０１６１】
なお、並列度を低くすることもプログラム駆動周波数を低くすることもできず、処理Ｓ３に進んだ場合、入力量過少時の規定の処理を実行する。一実施形態では、入力量が過少であることを示すメッセージの出力、またはログの書き込みなどを行うことができる。
【０１６２】
図２２の制御フローから明らかであるように、本発明では、プログラム駆動周波数を低くすること、および並列度を低くすることのうち、後者を優先して入力量過少に対処する。具体的には、まずは、並列度を低くすることで対処可能な間は並列度により対処し、並列度を低くできなくなった時点で初めて、プログラム駆動周波数を低くすることを検討する。
【０１６３】
ただし、プログラムの並列度を低くすると、実行時間の増大が予想される。例えば、実施形態３−２の処理Ｓ７では、予測デューティ率Ｄ’がデューティ率の上限ＤLを超えているので、処理Ｓ１０でプログラム駆動周波数を低くしている。しかし、実施形態３−２の処理Ｓ１０を経た後、再度入力量過少を検出して処理Ｓ７に至った場合には、プログラム周波数が低くなっているので、再び、並列度により対処できる可能性が生まれる。すなわち、本発明では、システムを安定稼働させながら、並列度での対処を優先して問題に対処することができる。
【０１６４】
このように性能を制御することにより、システムを安定稼働させながら、入力量に応じてシステムの性能を下げることができる。また、制御に当たっては、不必要なリソースを優先して開放することができる。
【図１】
0005480322.tif 000009
【図２】
0005480322.tif 000010
【図３】
0005480322.tif 000011
【図４】
0005480322.tif 000012
【図５】
0005480322.tif 000013
【図６】
0005480322.tif 000014
【図７】
0005480322.tif 000015
【図８Ａ】
0005480322.tif 000016
【図８Ｂ】
0005480322.tif 000017
【図９】
0005480322.tif 000018
【図１０】
0005480322.tif 000019
【図１１Ａ】
0005480322.tif 000020
【図１１Ｂ】
0005480322.tif 000021
【図１２】
0005480322.tif 000022
【図１３Ａ】
0005480322.tif 000023
【図１３Ｂ】
0005480322.tif 000024
【図１４】
0005480322.tif 000025
【図１５】
0005480322.tif 000026
【図１６】
0005480322.tif 000027
【図１７】
0005480322.tif 000028
【図１８】
0005480322.tif 000029
【図１９】
0005480322.tif 000030
【図２０】
0005480322.tif 000031
【図２１】
0005480322.tif 000032
【図２２】
0005480322.tif 000033