JP4992740B2 - マルチプロセッサシステム、障害検出方法および障害検出プログラム - Google Patents

Description

この発明は、システムが正常に動作しているかどうかを監視するためのウォッチドッグタイマ（ＷＤＴ）を用いて障害検出を行うマルチプロセッサシステム、障害検出方法および障害検出プログラムに関するものである。

従来、サーバ等のコンピュータシステムでは、プログラムのバグ等による障害の要因を特定する為の有効な方法として、次のような方法が一般に用いられている。プログラムのバグ等により障害が発生した際、障害発生時にプログラムが使用していたメモリ内容を「ダンプファイル」としてディスク等へ出力するダンプ機能がＯＳ（Operating System）に備わっている。そして、ダンプファイルの内容を専用のツール等で解析する事によって、障害の要因を特定する。ダンプファイル内には、障害を検出した時に走行していたプログラムのアドレスを含むレジスタ情報、タスク情報、スタック情報も含まれている。

また、一般的なコンピュータシステムでは、動作中のプログラムの正常性を確認するための一つの手段としてウォッチドッグタイマが搭載されている。通常時はウォッチドッグデーモン（以下、ＷＤデーモン）と呼ばれるＯＳ上のタスクがＣＰＵ（Central Processing Unit）の実行権を獲得する度にＷＤＴのカウンタをクリアする仕組みになっている。図２１は、従来技術における通常運用時のＷＤＴとＷＤデーモンの動きを示す図である。

プログラムに暴走等の障害が発生すると、ＷＤデーモンがＣＰＵの実行権を獲得する事が出来なくなる為、ＷＤＴへのクリアも実施されなくなる。図２２は、従来技術における障害発生時のＷＤＴとＷＤデーモンの動きを示す図である。一定期間以上このクリアが実施されないとＷＤＴはウォッチドッグタイムアウト（以下、ＷＤタイムアウト）として障害を検出し、ＣＰＵへ割込み等で通知を行い、この通知を契機として前述のダンプファイルの出力処理が開始される。

一方、近年では、コンピュータシステムの処理能力を向上させ、種々のタスクを実行するための技術として、複数のＣＰＵ上で複数のタスクを並列実行するマルチプロセッサシステムが多用されるようになっている。マルチプロセッサシステムでも、動作中のプログラムの正常性の確認のためには、上述の例と同様、ＯＳ上のＷＤＴおよびＷＤデーモンによる障害検出が行われるのが一般である。

また、複数の計算機を接続して負荷分散を可能とする計算機システムの障害発生に対する技術として、たとえば、下記特許文献１に記載の技術がある。下記特許文献１では、複数の計算機で構成される分散システムで、各計算機の障害を検出して障害が発生した場合に、上位機に問い合わせることなく、バックアップ計算機を決定することを可能とする技術が開示されている。

特開昭６２−０７２０５２号公報

しかしながら、マルチプロセッサシステムの各ＣＰＵ上では、タスクはＣＰＵ実行権を獲得したり解放したりを繰り返しながら並列動作を行っており、あるタスクが実行権を解放した際、次にどのタスクが実行権を持つかはＯＳの機能であるスケジューラが決定し、スケジューラが次のタスクへの切替えを行っている。通常、タスクはなるべく同じＣＰＵ上に留るため、ＣＰＵ実行権を解放した後、次に実行権が回って来る際は同じＣＰＵ上で実行されるようスケジューリングされる事になる。上述のＷＤデーモンもタスクの一種であるため、通常であれば同じＣＰＵ上で動作する。したがって、ＷＤデーモンは実行権を獲得する度に同一のＣＰＵ上で動作して、ＷＤＴのクリアを実施することになる。

このため、上記ＷＤＴおよびＷＤデーモンを用いた障害検出の従来技術をマルチプロセッサシステムに適用する場合に、ＷＤデーモンが稼動しているＣＰＵとは異なるＣＰＵ上で無限ループ等の暴走障害が発生しても、ＷＤデーモンは稼動しているＣＰＵが正常であるためＷＤＴをクリアし続け、システム全体としての障害を検出する事ができない、という問題がある。

また、ロードバランス機能を備えたＯＳの場合は、あるＣＰＵ上に多数のタスクが偏ってしまった場合等に、別のＣＰＵ上へタスクを強制移動させて負荷分散を行うことがある。この場合、暴走障害が発生したＣＰＵ以外のＣＰＵへＷＤデーモンが割当てられる可能性が高くなり、その場合、上記の例と同様に、システム全体としての障害を検出する事ができない、という問題がある。図２３は、従来技術におけるＷＤＴが障害を検出できないケースを示す図である。このように、ＣＰＵ＃２のタスクが暴走していても、ＷＤデーモンがＣＰＵ＃０またはＣＰＵ＃１で動作しているとＷＤＴはカウンタをクリアし、障害を検出できない。

また、ＣＰＵと同じ数のＷＤＴを実装すれば、全てのＣＰＵに渡って発生する障害を監視することが可能であるが、コスト的に負担が大きい上に、専用ハードを搭載することになり汎用性が損なわれる。近年では汎用ＣＰＵを搭載したボード上で汎用ＯＳを動かし同一ハードウェアで多様なサービスに対応するサーバシステムの導入がキャリア等を中心に広がっている。そうしたシステムに障害監視や障害情報収集のために独自に専用ハードウェアを搭載すると、汎用性を損なうことになるため、導入は難しい。

この発明は、上述した従来技術による問題点を解消するためになされたものであり、専用ハードウェアを搭載することなく、システムの全てのＣＰＵで発生した障害を検出することができることができるマルチプロセッサシステム、障害検出方法および障害検出プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、複数のプロセッサを備え、ウォッチドッグデーモンがウォッチドッグタイマを用いて障害の検出を行い、障害を検出した場合に障害発生の通知を行うマルチプロセッサシステムであって、待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報と、ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールと、を格納するための記憶手段と、ウォッチドッグデーモンのタスクに対応する前記プロセッサ情報を前記プロセッサ移動ルールに基づいて更新し、更新後のプロセッサ情報を前記記憶手段に書き込むウォッチドッグ管理手段と、を備えることを特徴とする。

また、本発明は、前記記憶手段に、ウォッチドッグデーモンが動作したプロセッサの識別子とウォッチドッグデーモンがウォッチドッグタイマをクリアした時刻とを対応付けてウォッチドッグ起動履歴として格納するウォッチドッグ履歴記録手段と、前記ウォッチドッグ起動履歴に基づいて、所定の時間を超えてウォッチドッグデーモンが動作していないプロセッサがあると判断した場合には、そのプロセッサに障害が発生したことを示す障害発生を通知するウォッチドッグ起動監視手段と、をさらに備えることを特徴とする。

また、本発明は、前記プロセッサ移動ルールに対するユーザーからの変更要求を受け付けるウォッチドッグデーモン挙動指定手段、をさらに備え、前記ウォッチドッグ管理手段が、前記変更要求に基づいて前記プロセッサ移動ルールを書き換えることを特徴とする。

また、本発明は、障害発生の通知が行われた場合、実行命令を含むレジスタ情報、タスク情報、スタック情報を含むプログラム走行情報を、所定の期間収集し、収集したプログラム走行情報を前記記憶手段へ書き込むプログラム走行履歴記録手段、をさらに備えることを特徴とする

また、本発明は、前記プログラム走行履歴の出力先の装置を変更可能とすることを特徴とする。

本発明によれば、ＷＤデーモンの動作プロセッサを所定のプロセッサ移動ルールに従って移動させるようにしたので、ＷＤデーモンが満遍なく全プロセッサ上で動作することができ、専用ハードウェアを搭載することなく、マルチプロセッサシステム内のどのプロセッサで障害が発生した場合でも、ＷＤタイムアウトによる障害の検出を行うことができるという効果を奏する。

また、本発明によれば、ＷＤＴクリアを行ったプロセッサ番号とその時刻をＷＤ起動履歴として格納し、ＷＤ起動履歴に基づいて所定の基準時間の間ＷＤＴクリアが行われていないプロセッサがある場合に、そのプロセッサ上で障害が発生したと判断して障害通知を出すようにしたので、ＯＳがロードバランス機能を有する場合でも、長時間ＷＤデーモンが動作していないプロセッサを検出することにより、全てのプロセッサについて障害検出を行うことができるという効果を奏する。

また、本発明によれば、プロセッサ移動ルールに対するユーザーの変更指示を受付け、変更指示に基づいて格納されたプロセッサ移動ルールを書き換えるようにしたので、プロセッサ移動ルールをいつでも任意に変更することができ、ユーザーの要求を容易に反映することができるという効果を奏する。

また、本発明によれば、障害発生通知があった場合に、プログラムの実行命令を含むレジスタ情報、タスク情報、スタック情報、時刻情報などをあらかじめ定められた任意の時間の間収集して格納するようにしたので、障害発生時のみの情報を格納する通常のダンプファイルとは異なり所定の時間の情報を確認することができ、無限ループが発生するような障害についても、格納されたプログラム走行履歴を解析することにより、容易に障害箇所を特定することができるという効果を奏する。

また、本発明によれば、ダンプファイルの出力先を指定できるようにしたので、システムの利用状況に応じてより利便性の高いメディアへの出力が選択可能となり、また、ダンプファイルを出力する装置に障害があった場合でも出力先を変更することによりダンプファイルの記録が可能となるという効果を奏する。

以下に添付図面を参照して、この発明に係るマルチプロセッサシステム、障害検出方法および障害検出プログラムの好適な実施の形態を詳細に説明する。なお、本実施例の説明では、プロセッサとして、ＣＰＵを例に挙げて説明するが、プロセッサの形態は、ＭＰＵ（Micro Processing Unit）等の他の形態であってもよい。また、ウォッチドッグデーモンおよびウォッチドッグタイマについても、所定のタイミングでシステムの動作状態を監視して障害の発生を検知する機能を有するものであればよい。

図１は、本発明にかかるマルチプロセッサシステムの実施例１の機能構成例を示す図である。本実施例のマルチプロセッサシステムは、複数のＣＰＵ（図示せず）で構成される制御部１と一次記憶装置２を備える。また、制御部１上では、ＯＳが稼動する。図１に示すように、本実施例のマルチプロセッサシステムは、実行するタスクに使用するＣＰＵの割り当てを行うスケジューラ１０と、ＣＰＵ実行権を獲得する度にＷＤＴに対してカウンタのクリアを行うＷＤデーモン１１と、ＷＤ管理部１２と、ＷＤデーモン１１により障害が検出された場合にダンプファイルを生成するダンプファイル出力部１３と、で構成される。また、出力先装置３は、磁気ディスク，メモリ，表示装置などで構成され、ダンプファイル出力部１３が生成するダンプファイルの出力先となる装置である。

なお、スケジューラ１０，ＷＤデーモン１１，ダンプファイル出力部１３は、ここでは、ＯＳの一般的な機能の一部とするが、これに限らず、同様の機能を実現するＯＳ以外の手段を用いるようにしてもよい。

一次記憶装置２には、各タスクがどのＣＰＵが使用されるかの情報であるＣＰＵ情報を含むタスク情報と、ＷＤデーモン１１に割り当てるＣＰＵの移動ルールが格納されているＣＰＵ移動ルールとが記憶される。

つづいて、本実施例の動作について説明する。ここでは、本実施例のマルチプロセッサシステムが、計４個のＣＰＵ（ＣＰＵ＃０〜ＣＰＵ＃３）を備える場合を仮定して説明する。まず、前提条件として、図２に、これらのＣＰＵ上で動作するタスクの状態遷移を示す。「実行状態」とはスケジューラ１０によりそのＣＰＵの実行権を渡され、タスクが処理を実行している状態を指す。「待機状態」とはタスクの処理が終了し、他のタスクへＣＰＵ実行権を明け渡しスリープしている状態を指す。「実行待ち状態」とは、待機状態からタスクが起床されてＣＰＵ毎に用意された実行待ちキューへ入った状態を指す。ＷＤデーモン１１もタスクの一つであり、図２の状態遷移を行いつつ、「実行状態」となりＣＰＵ実行権を獲得する度にタスク処理としてＷＤＴに対してカウンタのクリアを行う。

図３は、ＣＰＵ毎に用意されたタスクの実行待ちキューを説明するための図である。実行待ちキューは、タスクごとのタスク情報として、データがリスト状に格納されている。起床されたタスクは実行待ちキューの最後尾（Ｔａｉｌ）に入る（最後尾のタスク情報として格納される）。スケジューリング契機が来ると、スケジューラ１０はキューの先頭（Ｈｅａｄ）に格納されているタスク情報に対応するタスクから優先して該当ＣＰＵの実行権を渡す。たとえば、図３では、先頭（Ｈｅａｄ）に格納されているタスク情報に対応するタスクから順に実行権が与えられる。そして、タスク情報の順に対応するタスクに実行権が与えられ、最後にＴａｉｌのタスク情報に実行権が与えられる。ＣＰＵ上で処理を終えたタスクは、待機状態に移行すると共にキューから外され、次の実行契機まで待機する。

以上を前提として、本実施例の処理手順を説明する。図４は、本実施例の処理手順の一例を示すフローチャートである。図５−１，５−２，５−３，５−４は、本実施例の動作を説明するためのそれぞれ第１，第２，第３，第４の概念図である。まず、ＣＰＵ移動ルールがあらかじめ決められ、一次記憶装置２に格納されているとする。ここでは、例として「ラウンドロビン形式かつＣＰＵ番号の降順（ＣＰＵ＃３→ＣＰＵ＃２→ＣＰＵ＃１→ＣＰＵ＃０）へ移動」というルールが設定されたとする。

ある時点で、ＣＰＵ＃３上で実行していたタスクＡが処理を終了し、スケジューラ１０がＷＤデーモン１１にＣＰＵ＃３の実行権を割当てたとする（ステップＳ１１）。具体的には、図５−１に示した第１の概念図のように、タスクＡのタスク処理の終了後、タスクＡはＣＰＵ＃３の実行待ちキューから外され待機状態へ移行し、ＣＰＵ＃３の実行待ちキューのＨｅａｄであったＷＤデーモン１１のタスクにスケジューラ１０により実行権が与えられる。そして、ＷＤデーモン１１がＷＤＴのカウンタのクリアを要求する（ステップＳ１２）。

ＷＤＴのカウンタのクリア要求の実行によりカウンタのクリアが終了すると、ＷＤデーモンはＷＤ管理部１２に対しＣＰＵ＃３上でＷＤＴのクリア処理を行った旨を通知する（ステップＳ１３）。通知を受けたＷＤ管理部１２は、一次記憶装置のＣＰＵ移動ルールを読み出し、ＣＰＵ移動ルールに基づいて、次回のＷＤデーモン１１のタスクを実行するＣＰＵを決定する（ステップＳ１４）。この場合には、ＣＰＵ移動ルールが「ラウンドロビン形式かつＣＰＵ番号の降順」であることから、次回ＷＤデーモン１１が起動される時の実行ＣＰＵをＣＰＵ＃２に決定する。

つぎに、ＷＤ管理部１２は各タスクに対応したタスク情報群の中から、ＷＤデーモン１１のタスク情報を検索して読み出し、読み出したタスク情報に含まれるＣＰＵ情報のエリアを参照する。この時点では、ＷＤデーモン１１のタスクはＣＰＵ＃３で実行された為、参照したＣＰＵ情報のエリアにはＣＰＵ＃３を示す数値（ここでは、“３”とする）が記録されている。ＷＤ管理部１２は、このＣＰＵ情報のエリアをステップＳ１４で決定したＣＰＵ＃２を示す数値（“２”）へ書き換える（ステップＳ１５）。ステップＳ１５の書き換えが終了すると、ＷＤ管理部１２はＷＤデーモン１１に対しＣＰＵ情報の変更完了を通知し（ステップＳ１６）、ＷＤデーモン１１は待機状態へと状態遷移する。そして、図５−２の第２の概念図に示すように、ＷＤデーモン１１はＣＰＵ＃３の実行待ちキューから外され、スケジューラ１０により次のタスクＢがＣＰＵの実行権を獲得し、タスク処理を開始する。

一定時間経過後、待機していたＷＤデーモン１１が起床されると、前述のようにＷＤデーモン１１のタスクは、再び実行待ちキューへ入ることになるが、この時、ＷＤデーモン１１のタスク情報内のＣＰＵ情報は“２”に書き換えられているため、図５−３の第３の概念図に示すように、ＷＤデーモン１１はＣＰＵ＃２の実行待ちキューへ自動的に入る（ＣＰＵ＃２のタスク情報として格納される）。この結果、図５−４の第４の概念図に示すように、さらに時間経過後に、ＷＤデーモン１１のタスクがキューの先頭へ移動すると、スケジューラによりＣＰＵ＃２の実行権を渡され、上述のステップＳ１２と同様にＷＤＴのカウンタのクリアを要求する。以降、ステップＳ１３以降の処理が行われるが、ステップＳ１４で決定されるＣＰＵは、ＣＰＵ移動ルールに従いＣＰＵ＃１となる。

このような動作を繰り返しながら、ＷＤデーモン１１が動作する（ＷＤＴのカウンタクリアを実施する）ＣＰＵは、ＣＰＵ＃３→ＣＰＵ＃２、ＣＰＵ＃２→ＣＰＵ＃１、ＣＰＵ＃１→ＣＰＵ＃０、ＣＰＵ＃０→ＣＰＵ＃３と、システムが正常に運用されている間はラウンドロビン形式に従って全ＣＰＵ間を満遍なく巡るよう移動していく。

つづいて、障害発生時の動作について説明する。図６は、本実施例の障害発生時の動作を説明するための図である。上述の本実施例の処理手順（以下、ＣＰＵ移動処理という）により、過去の時刻Ｔ１にＣＰＵ＃３上で、時刻Ｔ２にＣＰＵ＃２上で、時刻Ｔ３にＣＰＵ＃１上で、時刻Ｔ４にＣＰＵ＃０上で、それぞれＷＤデーモン１１によるＷＤＴのカウンタのクリアが実施されたとする。時刻Ｔ４の後に、ＣＰＵ＃３上で実行中のタスクＤ内で無限ループ等による障害が発生したと仮定する。時刻Ｔ４でＷＤデーモン１１がＣＰＵ＃０で起動されたため、障害発生の時点では、タスク情報のＣＰＵ情報エリアが３に書き換えられている。

しかし、ＷＤデーモン１１のタスクがＣＰＵ＃３の実行待ちキューの先頭にきても、タスクＤがＣＰＵ＃３の実行権を獲得したまま暴走し続けているため、ＣＰＵの実行権が回って来ないまま待ち続けざるを得ない。そして、時刻Ｔ４以降一定期間ＷＤＴのクリアが実施されないとＷＤＴはＷＤタイムアウトを検出し、ＯＳに対して割込み（割込みの要因はＷＤタイムアウト）を通知する。割込みが通知されると、ＯＳはそれを障害発生のトリガとみなし、ダンプファイル出力部１３が全ＣＰＵ分のメモリ情報をダンプファイルへと出力する処理を行う。ここでは、ＣＰＵ＃３で障害が発生した例について説明したが、他のＣＰＵで障害が発生した場合でも、上述のＣＰＵ移動処理によりいずれは障害が発生したＣＰＵの実行待ちキューにＷＤデーモン１１のタスクが入るため、障害発生を検出することができる。

なお、本実施例では、ＣＰＵ移動ルールを、ＣＰＵ番号の降順に従ってラウンドロビン方式に移動としたが、これに限らず、たとえば、ＣＰＵ番号の昇順にする、ラウンドロビン方式ではなく他の方式により巡回方式にする、など全てのＣＰＵを一定期間の間に一巡するようなルールであればどのようなルールとしてもよい。

以上のように、本実施例では、ＷＤデーモンの動作ＣＰＵを所定のＣＰＵ移動ルールに従って移動させるようにした。このため、専用ハードウェアを搭載することなく、マルチプロセッサシステム内のどのＣＰＵで障害が発生した場合でも、ＷＤタイムアウトによる障害の検出を行うことができる。

図７は、本発明にかかるマルチプロセッサシステムの実施例２の機能構成例を示す図である。図７に示すように、本実施例のマルチプロセッサシステムは、実施例１のマルチプロセッサシステムに、ＷＤ履歴記録部１４とＷＤ起動監視部１５を追加しているが、それ以外は実施例１と同様である。実施例１と同様の機能を有する構成要素は、実施例１と同一の符号を付して説明を省略する。

本実施例のＯＳは、ＣＰＵの実行待ちキュー内のタスク数に偏りが生じた場合に、実行待ちキュー内のタスク数が多いＣＰＵから少ないＣＰＵへ強制移動を行うロードバランス機能を備えていると仮定する。本実施例のＣＰＵ移動処理については実施例１と同様であり、以下、実施例１と異なる部分について説明する。

通常運用時は実施例１と同様に、ＷＤデーモン１１はＣＰＵ移動ルールに従って、動作ＣＰＵを移動しながらＷＤＴのカウンタのクリア処理を行う。ここでは、実施例１と同様に、ＣＰＵ移動ルールを、ＣＰＵ番号の降順に従ってラウンドロビン方式で移動しながらＷＤＴのクリアを行うこととする。

図８−１，２は、本実施例の障害発生時の動作を説明するための第１，第２の概念図である。まず、図８−１に示すように、前述のＣＰＵ移動ルールにより、過去の時刻Ｔ１にＣＰＵ＃３上で、時刻Ｔ２にＣＰＵ＃２上で、時刻Ｔ３にＣＰＵ＃１上で、それぞれＷＤデーモン１１によりＷＤＴカウンタのクリアが実施されたとする。この時点で（時刻Ｔ３以降）、ＣＰＵ＃３上で実行されているタスクＤ内で無限ループによる障害が発生したと仮定する。ＷＤデーモン１１が待機状態より起床すると、タスク情報のＣＰＵ情報エリアが“０”に変更されているため、ＷＤデーモン１１のタスクはＣＰＵ＃０の実行待ちキューに入る。

このため、つぎにＷＤデーモン１１がＷＤＴのカウンタのクリアを実施するのはＣＰＵ＃０上になるはずである。しかし、本実施例ではＯＳがロードバランス機能を備えているため、もしＣＰＵ＃０の実行待ちキューに入っているタスク数が多すぎるとＯＳが判断すると、ＯＳは、図８−２に示すように、ＣＰＵ＃０の実行待ちキュー内のタスクの一部を強制的に別のＣＰＵの実行待ちキューへ移動させてしまう。ＷＤデーモン１１もロードバランスの対象となる。ここでは、ＷＤデーモン１１のタスクがＣＰＵ＃０からＣＰＵ＃２の実行待ちキューへ移動させられたと仮定する。

以上のロードバランス機能による処理により、次にＷＤデーモン１１はＣＰＵ＃２上でＷＤＴのカウンタのクリアを実施し、以降は再びＣＰＵ番号の降順のＣＰＵ移動が続行される。このようなロードバランス機能による強制的な実行待ちキュー移動が、何度も繰り返されているような状況では、場合によってはＷＤデーモン１１がＣＰＵ＃３の実行待ちキューへ入ることができないことがある。この場合、ＷＤタイムアウトが発生しないため、ＣＰＵ＃３上でタスクＤが暴走していることを検出できないことになる。

こうしたケースに対応するため、本実施例では、ＷＤＴのカウンタのクリア処理（以下、ＷＤＴクリアという）を行ったＣＰＵ番号をＷＤ起動履歴として記憶し、所定の時間ＷＤＴクリアの行われていないＣＰＵを検出できるようにしている。図９は、本実施例の処理手順の一例を示すフローチャートである。まず、ＷＤ管理部１２がＷＤデーモン１１のタスク情報のＣＰＵ情報エリアを書き換えた（実施例１のステップＳ１６）後、ＷＤ管理部１２がＷＤ履歴記録部１４にＷＤＴクリアを行ったＣＰＵ番号（ＷＤデーモン１１が動作したＣＰＵ番号）を通知する（ステップＳ２１）。

通知を受けたＷＤ履歴記録部１４は、現在時刻をシステム時計より取得した上で、一次記憶装置２内にＷＤ起動履歴を書き込む（ステップＳ２２）。図１０はＷＤ起動履歴として書き込むテーブル情報の一例を示す図である。このテーブル内には少なくとも現在時刻およびＷＤＴをクリアしたＣＰＵ番号が含まれるものとする。

ＷＤ起動履歴への書込みが終了すると、ＷＤ履歴記録部１４はＷＤ起動監視部１５を起動する（ステップＳ２３）。ＷＤ起動監視部１５は、過去一定時間分のＷＤ起動履歴を遡って参照し、ＣＰＵ＃０〜ＣＰＵ＃３の中でＷＤデーモン１１が起動していない期間が所定の基準時間（例：１２０秒）を超えているＣＰＵがあるか否かを判断する（ステップＳ２４）。基準時間を超えてＷＤデーモン１１が起動されていないＣＰＵが存在すると判断した場合（ステップＳ２４ Ｙｅｓ）、ＷＤ起動監視部１５は、そのＣＰＵ上で障害が発生したものと判断し、障害発生の通知を出す（ステップＳ２５）。この通知を受けたダンプファイル出力部１３は、ＷＤタイムアウト発生の通知を受けた時と同様に、ダンプファイルを生成し、出力先装置３にダンプファイルを出力する（ステップＳ２６）。

図１１に本実施例の動作を説明するための第３の概念図を示す。図８−１と同様にＣＰＵ＃３上でタスクＤが無限ループ等の暴走を起こしている状況で、ＷＤデーモン１１が動作ＣＰＵを移動しながらＷＤＴのクリアを実施している。頻繁にロードバランス機能による処理が発生するためＣＰＵ＃０〜ＣＰＵ＃２の範囲内でのみＷＤデーモン１１が起動される状況がしばらく続いていることとする。この例では、ＣＰＵ＃１上でＷＤデーモン１１が動作したＴ３から、基準時間であるｍ秒経過したＴ１１の時点までの間で、ＣＰＵ＃３上でＷＤデーモン１１は動作していない。図１２は、本実施例のＷＤ起動履歴の一例を示す図である。図１２は、図１１で説明した例のＴ１１の時点でのＷＤ起動履歴の例である。このように、ＷＤ起動履歴に基づいてＴ３〜Ｔ１１までのｍ秒（基準時間：たとえば１２０秒）の間に一度もＣＰＵ＃３上でＷＤデーモンが起動されていないと判断できるため、この場合、ＣＰＵ＃３上で障害が発生したものとみなし、ＷＤ起動監視部１５は、障害発生の通知を出す。

このように、本実施例では、ＷＤ履歴記録部１４がＷＤＴクリアを行ったＣＰＵ番号とその時刻をＷＤ起動履歴として一次記憶装置２に格納し、ＷＤ起動監視部１５が、ＷＤ起動履歴に基づいて所定の基準時間の間ＷＤＴクリアが行われていないＣＰＵがある場合に、そのＣＰＵ上で障害が発生したと判断して障害通知を出すようにした。このため、ＯＳがロードバランス機能を有するシステムで、マルチプロセッサシステム内のどのＣＰＵで障害が発生した場合でも、ＷＤタイムアウトによる障害検出を行うことができる。

図１３は、本発明にかかるマルチプロセッサシステムの実施例３の機能構成例を示す図である。図１３に示すように、本実施例のマルチプロセッサシステムは、実施例１のマルチプロセッサシステムのＷＤ管理部１２をＷＤ管理部１２ａに替え、ＷＤ挙動指定部１６を追加しているが、それ以外は実施例１と同様である。実施例１と同様の機能を有する構成要素は、実施例１と同一の符号を付して説明を省略する。

本実施例では、ＣＰＵ移動ルールをユーザーが指定するためにＷＤ挙動指定部１６を追加し、ＷＤ管理部１２ａがユーザーの指定に基づいて一次記憶装置２のＣＰＵ移動ルールを書き換える。

図１４は、本実施例の処理手順の一例を示すフローチャートである。また、図１５は、本実施例のＷＤデーモン１１が動作するＣＰＵの流れを示す図である。まず、実施例１と同様にＣＰＵ移動ルールがあらかじめ定められ、一次記憶装置２に格納されているとする。ここでは、あらかじめ定められたＣＰＵ移動ルールとしてランダム巡回（ランダムな順番で全てのＣＰＵの移動を繰り返す）が設定されていたとする。そして、実施例１で説明したＣＰＵ移動処理によって、そのＣＰＵ移動ルールに基づいた処理が行われているとする。その状態ではＷＤデーモン１１は、たとえば、図１５の期間（ａ）のようにランダム巡回を行っている。

このとき、ユーザーがＣＰＵ移動ルールを「ラウンドロビン形式かつＣＰＵ番号の降順へ移動」というルールに変更したいとする。この場合、ＷＤ挙動指定部１６が、ユーザーの指示（この例では「ラウンドロビン形式かつＣＰＵ番号の降順へ移動」というルールへの変更指示）を受付け、指示内容をＷＤ管理部１２ａに通知する（ステップＳ３１）。ユーザーからの指示は、たとえば、図示しないキーボード，マウスなどの入力装置を経由して行われることとする。つぎに、通知をうけたＷＤ管理部１２ａは、その指示内容に基づいて一次記憶装置２上のＣＰＵ移動ルールを書き換える（ステップＳ３２）。

この処理以降、ＷＤ管理部１２ａは、ＷＤデーモン１１に対するＣＰＵ割り当てをユーザーにより変更された「ラウンドロビン形式かつＣＰＵ番号の降順へ移動」というルールに基づいて行うことになる（図１５の期間（ｂ））。なお、ＣＰＵ移動ルールのユーザーによる変更を受付けるタイミングに特に制約はない。

なお、本実施例では、実施例１のマルチプロセッサシステムのＷＤ管理部１２をＷＤ管理部１２ａに替え、ＷＤ挙動指定部１６を追加しているが、実施例２のマルチプロセッサシステムのＷＤ管理部１２をＷＤ管理部１２ａに替え、さらにＷＤ挙動指定部１６を追加して、上述のＣＰＵ移動ルールに対するユーザーの変更指示を反映する処理を行うようにしてもよい。

このように、本実施例では、ＷＤ挙動指定部１６が、ＣＰＵ移動ルールに対するユーザーの変更指示を受付け、ＷＤ管理部１２ａが変更指示に基づいて一次記憶装置２に格納されたＣＰＵ移動ルールを書き換えるようにした。このため、ＣＰＵ移動ルールをいつでも任意に変更することができる。

図１６は、本発明にかかるマルチプロセッサシステムの実施例４の機能構成例を示す図である。図１６に示すように、本実施例のマルチプロセッサシステムは、実施例１のマルチプロセッサシステムに、プログラム走行履歴記録部１７を追加し、一次記憶装置２にさらにプログラム走行履歴を格納するようにしているが、それ以外は実施例１と同様である。実施例１と同様の機能を有する構成要素は、実施例１と同一の符号を付して説明を省略する。

従来のＷＤタイムアウト検出により、出力されたダンプファイルからは、障害原因を調査する事が困難なケースが存在する。障害の原因がプログラム内で発生した不正メモリアクセスや論理矛盾の場合であれば、障害発生時に走行していたプログラムのアドレスが障害箇所そのものであるため、ダンプファイル内の情報から障害要因を特定する事は比較的容易である。これに対し、プログラム内で無限ループが発生しＷＤタイムアウトが検出された場合では、ダンプファイルから得られるＣＰＵの実行アドレス情報は、ループしているアドレス範囲のうちＷＤタイムアウトが発生した瞬間に走行していたアドレスに過ぎない。そのため、プログラムのどの範囲内でループが発生していたのか、そして何が原因でループ発生に至ったのかという要因についてはダンプファイル内に残る情報からは特定する事ができず、障害の根本原因の究明が困難であるという課題があった。したがって、こうした障害の場合は、プログラムの走行情報を実行命令毎に記録する事が解析の有効な情報となり得る。しかし、通常運用中にもそうした走行情報を常時記録することは、システムに多大な負荷をかける事になり実用的では無い。

上記の問題を解決するため、本実施例では、障害を検出した時点から一定時間プログラムの走行履歴を収集する機能を追加している。プログラムの走行履歴には、一般にダンプファイルとして出力される内容と同様な情報（たとえば、プログラムの実行命令を含むレジスタ情報、タスク情報、スタック情報、時刻情報など）と共に、システムから取得した各命令の実行時刻の情報も含まれる。

つづいて、本実施例の動作について説明する。図１７は、本実施例の処理手順の一例を示すフローチャートである。また、図１８は、本実施例の障害発生前後の処理概念を示す図である。まず、本実施例のマルチプロセッサシステムは、通常の状態では、実施例１と同様にＣＰＵ移動ルールに従ってＣＰＵ移動処理を行っている（図１８の（ａ）通常動作期間）。

このとき、プログラム暴走等が発生し、実施例１の障害発生時の動作と同様に、ＷＤＴはＷＤタイムアウトを検出し障害発生を通知したとする（ステップＳ４１）。障害発生通知をうけて、通常は、ＯＳがダンプファイルに必要な情報を収集してダンプファイル出力部１３がダンプファイルの生成を行う。つまり、障害発生通知が、障害情報収集のトリガとなっているため、以下では、障害発生通知を障害情報収集トリガとよぶこととする。

一般に、障害発生トリガをうけたＯＳは即座にその時点でのメモリの内容をダンプファイルとして出力するための情報として収集する処理を開始する。これに対し、本実施例では、まず、障害発生トリガが生じた場合に、ＯＳはプログラム走行履歴記録部１７に障害発生を通知し、通知を受けたプログラム走行履歴記録部１７が各ＣＰＵで実行されているプログラムの実行命令を含むレジスタ情報、タスク情報、スタック情報（通常ダンプファイルに出力されるのと同様の項目）と命令の実行時刻情報を収集し、プログラム走行履歴として一次記憶装置２へ格納する（図１７のステップＳ４２，図１８の（ｃ）ＣＰＵ毎の走行情報収集）。この収集および格納は、あらかじめ定められた任意の時間（図１８の例では５秒間）続行する。

そして、あらかじめ定められた任意の時間が経過すると、通常のダンプファイル出力処理が行われる（ステップＳ４３）。本実施例のこれ以外の動作は、実施例１と同様である。

なお、本実施例では、実施例１のマルチプロセッサシステムにプログラム走行履歴記録部１７を追加しているが、実施例２のマルチプロセッサシステムまたは実施例３のマルチプロセッサシステムにプログラム走行履歴記録部１７を追加し、本実施例と同様に、障害収集トリガが生じた場合にプログラム走行履歴を収集して、一次記憶装置２に格納するようにしてもよい。

このように、本実施例では、障害発生通知があった場合に、プログラム走行履歴記録部１７がプログラムの実行命令を含むレジスタ情報、タスク情報、スタック情報、時刻情報などをあらかじめ定められた任意の時間の間収集して、プログラム走行履歴として一次記憶装置２に格納するようにした。このため、無限ループが発生するような障害についても、格納されたプログラム走行履歴を解析することにより、容易に障害箇所を特定することができる。

図１９は、本発明にかかるマルチプロセッサシステムの実施例５の機能構成例を示す図である。図１９に示すように、本実施例のマルチプロセッサシステムは、実施例４のマルチプロセッサシステムに、ダンプファイル出力先指定部１８を追加しているが、それ以外は実施例４のマルチプロセッサシステムと同様である。実施例４と同様の機能を有する構成要素は、実施例４と同一の符号を付して説明を省略する。

また、本実施例では、出力先装置３は、磁気ディスクなどで構成されるディスク３１と、パケットとして出力しネットワーク上へ転送するパケット処理装置３２と、モニタなどで構成され表示を行う標準出力装置３３と、半導体などで構成されるメモリ３４と、を備えることする。

図２０は、本実施例の処理手順の一例を示すフローチャートである。本実施例の動作は、実施例４の動作と同様であるが、本実施例では、実施例４で出力されるダンプファイルとプログラム走行情報の出力先を選択できるようにしている。まず、実施例４と同様に障害発生が通知されたとする（ステップＳ５１）。その後、実施例４と同様にプログラム走行履歴記録部１７が、実施例４のステップＳ４２を実行し、その後、ダンプファイル出力部１３へダンプファイルの出力指示する（ステップＳ５２）。ダンプファイル出力部１３は、プログラム走行情報とダンプ情報（ダンプファイルの情報として収集した情報）をダンプファイル出力先指定部１８へ出力する（ステップＳ５３）。そして、ダンプファイル出力先指定部１８は、あらかじめユーザーにより設定されている出力先の指定に基づいて、プログラム走行情報とダンプファイルを出力する（ステップＳ５４）。たとえば、出力装置３のうち、ディスク３１，パケット処理装置３２，標準出力装置３３，メモリ３４のいずれかへと出力させる。なお、ダンプファイル出力先指定部１８は、あらかじめ設定された出力先を保持しており、ユーザーからの指定があった場合には、その設定内容を書き換えることとする。

なお、本実施例では、プログラム走行履歴情報と通常のダンプファイルの両方を出力先装置３へ出力するようにしたが、プログラム走行履歴情報のみを出力するようにしてもよい。

このように、本実施例では、ダンプファイルの出力先を指定できるようにした。このため、ユーザーの利用しやすい形態でダンプファイルを出力することができる。また、たとえば、ダンプファイルを出力する装置に障害があった場合、通常であればダンプファイルを記録することができなくなるが、本実施例では出力先を変更することによりダンプファイルの記録が可能となる。

（付記１）複数のプロセッサを備え、ウォッチドッグデーモンがウォッチドッグタイマを用いて障害の検出を行い、障害を検出した場合に障害発生の通知を行うマルチプロセッサシステムであって、
待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報と、ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールと、を格納するための記憶手段と、
ウォッチドッグデーモンのタスクに対応する前記プロセッサ情報を前記プロセッサ移動ルールに基づいて更新し、更新後のプロセッサ情報を前記記憶手段に書き込むウォッチドッグ管理手段と、
を備えることを特徴とするマルチプロセッサシステム。

（付記２）前記記憶手段に、ウォッチドッグデーモンが動作したプロセッサの識別子とウォッチドッグデーモンがウォッチドッグタイマをクリアした時刻とを対応付けてウォッチドッグ起動履歴として格納するウォッチドッグ履歴記録手段と、
前記ウォッチドッグ起動履歴に基づいて、所定の時間を超えてウォッチドッグデーモンが動作していないプロセッサがあると判断した場合には、そのプロセッサに障害が発生したことを示す障害発生を通知するウォッチドッグ起動監視手段と、
をさらに備えることを特徴とする付記１に記載のマルチプロセッサシステム。

（付記３）前記プロセッサ移動ルールに対するユーザーからの変更要求を受け付けるウォッチドッグデーモン挙動指定手段、
をさらに備え、
前記ウォッチドッグ管理手段が、前記変更要求に基づいて前記プロセッサ移動ルールを書き換えることを特徴とする付記１または２に記載のマルチプロセッサシステム。

（付記４）障害発生の通知が行われた場合、実行命令を含むレジスタ情報、タスク情報、スタック情報を含むプログラム走行情報を、所定の期間収集し、収集したプログラム走行情報を前記記憶手段へ書き込むプログラム走行履歴記録手段、
をさらに備えることを特徴とする付記１、２または３に記載のマルチプロセッサシステム。

（付記５）前記プログラム走行履歴の出力先の装置を変更可能とすることを特徴とする付記４に記載のマルチプロセッサシステム。

（付記６）複数のプロセッサを備え、ウォッチドッグデーモンがウォッチドッグタイマを用いて障害の検出を行行い、障害を検出した場合に障害発生の通知を行うマルチプロセッサシステムにおける障害検出方法であって、
ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールを格納するプロセッサ移動ルール格納ステップと、
待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報のうち、ウォッチドッグデーモンのタスクに対応するプロセッサ情報を、前記プロセッサ移動ルールに基づいて更新するウォッチドッグ管理ステップと、
を含むことを特徴とする障害検出方法。

（付記７）ウォッチドッグデーモンが動作したプロセッサの識別子とウォッチドッグデーモンがウォッチドッグタイマをクリアした時刻とを対応付けてウォッチドッグ起動履歴として格納するウォッチドッグ履歴記録ステップと、
前記ウォッチドッグ起動履歴に基づいて、所定の時間を超えてウォッチドッグデーモンが動作していないプロセッサがあると判断した場合には、そのプロセッサに障害が発生したことを示す障害発生を通知するウォッチドッグ起動監視ステップと、
をさらに含むことを特徴とする付記６に記載の障害検出方法。

（付記８）前記プロセッサ移動ルールに対するユーザーからの変更要求を受け付けるウォッチドッグデーモン挙動指定ステップと、
前記変更要求に基づいて前記プロセッサ移動ルールを書き換えるステップと、
をさらに含むことを特徴とする付記６または７に記載の障害検出方法。

（付記９）ウォッチドッグデーモンによる障害の検出により障害発生の通知が行われた場合、または、前記ウォッチドッグ起動監視ステップによる障害発生の通知が行われた場合に、実行命令を含むレジスタ情報、タスク情報、スタック情報を含むプログラム走行情報を、所定の期間収集し、収集したプログラム走行情報を記録するプログラム走行履歴記録ステップ、
をさらに含むことを特徴とする付記６、７または８に記載の障害検出方法。

（付記１０）前記プログラム走行履歴の出力先の装置を変更可能とすることを特徴とする付記９に記載の障害検出方法。

（付記１１）複数のプロセッサを備え、ウォッチドッグデーモンがウォッチドッグタイマを用いて障害の検出を行うマルチプロセッサシステムにおいて、障害を検出するための障害検出プログラムであって、
ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールを記憶部に格納するプロセッサ移動ルール格納手順と、
記憶部からプロセッサ移動ルールを読み出し、さらに待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報のうち、ウォッチドッグデーモンのタスクに対応するプロセッサ情報を記憶部から読み出し、読み出したプロセッサ情報を前記プロセッサ移動ルールに基づいて更新し、更新後のプロセッサ情報を記憶部に書き込むウォッチドッグ管理手順と、
をコンピュータに実行させることを特徴とする障害検出プログラム。

（付記１２）ウォッチドッグデーモンが動作したプロセッサの識別子とウォッチドッグデーモンがウォッチドッグタイマをクリアした時刻とを対応付けてウォッチドッグ起動履歴として記憶部に格納するウォッチドッグ履歴記録手順と、
記憶部からウォッチドッグ起動履歴を読み出し、読み出したウォッチドッグ起動履歴に基づいて、所定の時間を超えてウォッチドッグデーモンが動作していないプロセッサがあると判断した場合には、そのプロセッサに障害が発生したことを示す障害発生を通知するウォッチドッグ起動監視手順と、
をさらに含むことを特徴とする付記１１に記載の障害検出プログラム。

（付記１３）前記プロセッサ移動ルールに対するユーザーからの変更要求を受け付けるウォッチドッグデーモン挙動指定手順と、
前記変更要求に基づいて前記プロセッサ移動ルールを書き換える手順と、
をさらに含むことを特徴とする付記１１または１２に記載の障害検出プログラム。

（付記１４）ウォッチドッグデーモンによる障害の検出により障害発生の通知が行われた場合、または、前記ウォッチドッグ起動監視手順による障害発生の通知が行われた場合に、実行命令を含むレジスタ情報、タスク情報、スタック情報を含むプログラム走行情報を、所定の期間収集し、収集したプログラム走行情報を記憶部へ書き込むプログラム走行履歴記録手順、
をさらに含むことを特徴とする付記１１、１２または１３に記載の障害検出プログラム。

（付記１５）前記プログラム走行履歴の出力先の装置を変更可能とすることを特徴とする付記１４に記載の障害検出プログラム。

以上のように、本発明に係るマルチプロセッサシステム、障害検出方法および障害検出プログラムは、複数のプロセッサを有し、ＷＤＴを利用した障害検出機能を持つコンピュータシステムに適している。

本発明にかかるマルチプロセッサシステムの実施例１の機能構成例を示す図である。 タスクの状態遷移を示す図である。 タスクの実行待ちキューを説明するための図である。 実施例１の処理手順の一例を示すフローチャートである。 実施例１の動作を説明するためのそれぞれ第１の概念図である。 実施例１の動作を説明するためのそれぞれ第２の概念図である。 実施例１の動作を説明するためのそれぞれ第３の概念図である。 実施例１の動作を説明するためのそれぞれ第４の概念図である。 実施例１の障害発生時の動作を説明するための図である。 本発明にかかるマルチプロセッサシステムの実施例２の機能構成例を示す図である。 実施例２の障害発生時の動作を説明するための第１の概念図である。 実施例２の障害発生時の動作を説明するための第２の概念図である。 実施例２の処理手順の一例を示すフローチャートである。 ＷＤ起動履歴として書き込むテーブル情報の一例を示す図である。 実施例２の動作を説明するための第３の概念図である。 実施例２のＷＤ起動履歴の一例を示す図である。 本発明にかかるマルチプロセッサシステムの実施例３の機能構成例を示す図である。 実施例３の処理手順の一例を示すフローチャートである。 実施例３のＷＤデーモンが動作するＣＰＵの流れを示す図である。 本発明にかかるマルチプロセッサシステムの実施例４の機能構成例を示す図である。 実施例４の処理手順の一例を示すフローチャートである。 実施例４の障害発生前後の処理概念を示す図である。 本発明にかかるマルチプロセッサシステムの実施例５の機能構成例を示す図である。 実施例５の処理手順の一例を示すフローチャートである。 従来技術における通常運用時のＷＤＴとＷＤデーモンの動きを示す図である。 従来技術における障害発生時のＷＤＴとＷＤデーモンの動きを示す図である。 従来技術におけるＷＤＴが障害を検出できないケースを示す図である。

符号の説明

１ 制御部
２ 一次記憶装置
３ 出力先装置
１０ スケジューラ
１１ ＷＤデーモン
１２，１２ａ ＷＤ管理部
１３ ダンプファイル出力部
１４ ＷＤ履歴記録部
１５ ＷＤ起動監視部
１６ ＷＤ挙動指定部
１７ プログラム走行履歴記録部
１８ ダンプファイル出力先指定部
３１ ディスク
３２ パケット処理装置
３３ 標準出力装置
３４ メモリ

Claims (7)

1. 複数のプロセッサと、計数した時間が所定の時間を超過した場合には、障害発生を通知する１つのウォッチドッグタイマとを備えるマルチプロセッサシステムにおいて、
   待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報と、前記プロセッサにより実行された場合には、前記ウォッチドッグタイマが計数した時間をクリアするウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールと、を格納するための記憶手段と、
   ウォッチドッグデーモンのタスクに対応する前記プロセッサ情報を前記プロセッサ移動ルールに基づいて更新し、更新後のプロセッサ情報を前記記憶手段に書き込むウォッチドッグ管理手段と、
   を備えることを特徴とするマルチプロセッサシステム。
2. 前記記憶手段に、ウォッチドッグデーモンが動作したプロセッサの識別子とウォッチドッグデーモンがウォッチドッグタイマをクリアした時刻とを対応付けてウォッチドッグ起動履歴として格納するウォッチドッグ履歴記録手段と、
   前記ウォッチドッグ起動履歴に基づいて、所定の時間を超えてウォッチドッグデーモンが動作していないプロセッサがあると判断した場合には、そのプロセッサに障害が発生したことを示す障害発生を通知するウォッチドッグ起動監視手段と、
   をさらに備えることを特徴とする請求項１に記載のマルチプロセッサシステム。
3. 前記プロセッサ移動ルールに対するユーザーからの変更要求を受け付けるウォッチドッグデーモン挙動指定手段、
   をさらに備え、
   前記ウォッチドッグ管理手段が、前記変更要求に基づいて前記プロセッサ移動ルールを書き換えることを特徴とする請求項１または２に記載のマルチプロセッサシステム。
4. 障害発生の通知が行われた場合、実行命令を含むレジスタ情報、タスク情報、スタック情報を含むプログラム走行情報を、障害発生を検出してから所定の期間収集し、収集したプログラム走行情報を前記記憶手段へ書き込むプログラム走行履歴記録手段、
   をさらに備えることを特徴とする請求項１、２または３に記載のマルチプロセッサシステム。
5. 前記プログラム走行履歴の出力先の装置を変更可能とすることを特徴とする請求項４に記載のマルチプロセッサシステム。
6. 複数のプロセッサと、計数した時間が所定の時間を超過した場合には、障害発生を通知する１つのウォッチドッグタイマとを備えるマルチプロセッサシステムが実行する障害検出方法であって、
   前記プロセッサにより実行された場合には、前記ウォッチドッグタイマが計数した時間をクリアするウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールを格納するプロセッサ移動ルール格納ステップと、
   待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報のうち、ウォッチドッグデーモンのタスクに対応するプロセッサ情報を、当該ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールに基づいて更新するウォッチドッグ管理ステップと
   を含むことを特徴とする障害検出方法。
7. 複数のプロセッサと、計数した時間が所定の時間を超過した場合には、障害発生を通知する１つのウォッチドッグタイマとを備えるコンピュータが実行する障害検出プログラムであって、
   前記プロセッサにより実行された場合には、前記ウォッチドッグタイマが計数した時間をクリアするウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールを記憶部に格納するプロセッサ移動ルール格納手順と、
   記憶部からプロセッサ移動ルールを読み出し、さらに待機中のタスクが実行権を獲得した際に動作するプロセッサの識別子が対応するタスクごとに格納されているプロセッサ情報のうち、ウォッチドッグデーモンのタスクに対応するプロセッサ情報を記憶部から読み出し、読み出したプロセッサ情報を、当該ウォッチドッグデーモンが動作するプロセッサを順次移動させて巡回させるためのルールであるプロセッサ移動ルールに基づいて更新するウォッチドッグ管理手順と
   をコンピュータに実行させることを特徴とする障害検出プログラム。

Images