JP2005190038A - プロセッサの診断処理方法および診断処理プログラム - Google Patents

Abstract

【課題】
プロセッサ障害を検出するための診断用のプログラムを実行する際、システムの性能低下を招かない診断処理方法を提供する。
【解決手段】
一個または複数個のプロセッサからなるシステムにおいて、診断プログラムが各プロセッサの診断を行うための一個または複数個のプロセス又はスレッドを所定の間隔で生成し、生成されたプロセス又はスレッドが各プロセッサ上で所定の診断を実行し、自プロセッサでの障害の発生を検出したプロセス又はスレッドは障害情報を記憶手段に格納して終了し、前記障害発生プロセッサとは別のプロセッサのプロセス又はスレッドが障害発生プロセッサの障害情報を参照して所定の障害処理を行う。
【選択図】 図１

Description

本発明は、情報処理システムを構成する要素であるプロセッサの障害をシステム稼動の状態でも検出可能な診断方法に関し、特に、診断を行うことにより発生するシステムへの負荷を低減可能な診断方法に関するものである。

情報処理システムの信頼性向上は、システム規模の大小やシステムの種別に依らず、古くからの重要な課題である。信頼性向上の対象となる部位は多岐に渡るが、特にプロセッサはシステムの中核であるため、信頼性向上のために様々な方式が用いられている。信頼性向上のためにハードウエアを設ける方法、あるいは、ソフトウエアによる方法、あるいはその両方を用いる方法である。

ハードウエアを設ける方法としては、例えば、特許文献１にあるように、プロセッサ内部に信頼性向上専用の資源を設け専用のマイクロコードを用いる方法や、あるいは、特許文献２にあるようにプロセッサとは別に信頼性向上専用のハードウエアを設ける方法、あるいは、このほかに、信頼性を高めたい資源を多重化して実装する方法など様々な方式がある。

信頼性向上のためにハードウエアを設ける方法は、診断をバックグラウンドで行うことができる点や、診断に要する時間の短縮という点では有効であるがコストの増加という問題がある。したがって、システム全体の性能、または、価格性能比に重点を置く場合には採用が困難な場合がある。このような場合、診断をソフトウエア単独で行う方式、または、最小限のハードウエアの追加を行ったうえで、診断をソフトウエアで行う方式が用いられることが多い。

信頼性向上のために診断用のプログラムを実行する方法としては、例えば、特許文献３にあるように、診断対象となる資源を占有ないし占有に近いかたちで確保し、主として診断プログラムのみを単独で実行して検査する方法がある。あるいは、特許文献４にあるように、アプリケーションを実行中に診断プログラムを並行して実行させる方法が存在する。

特開平６−２８３２８号公報

特開平１０−２４７１８５号公報 特開平６−１４９６１２号公報 特開平６−８３６６７号公報

信頼性向上のために診断用のプログラムを実行する場合、システムの性能低下や、診断を行う頻度について問題が発生する。例えば特許文献３のように、診断プログラムのみを単独で実行して検査する場合、アプリケーションを実行中の状態では診断を行うことができない。アプリケーションの種類によっては、１週間あるいは１ヶ月の単位で連続運転するプログラムも存在するため、このような場合には十分な診断を行うことができない。

特許文献４においては、アプリケーションを実行中に診断プログラムを並行して実行可能ではあるが、診断プログラムの実行頻度に関する制御方法が開示されていないため、アプリケーションの性能低下を招きうるという問題点がある。また、特許文献４においては、診断の結果、プロセッサに障害が存在していた場合の制御方法も開示されていないため、障害発生後に十分な回復処置を行うことができない可能性があるという問題点も存在する。

本発明の目的は、前述した従来技術の問題を解決し、アプリケーションの実行の有無に関わらずプロセッサに障害が発生していないか、診断を行うことが可能で、かつ、診断実行時にアプリケーションの性能低下を最小限に留め、プロセッサ障害が発生した場合にも適切な回復処置を行うことのできる診断方法を、特別なハードウエアを用いることなく提供することにある

本発明においては、プロセッサ障害を診断するためのプログラムは、通常のアプリケーションと同様、ＯＳの管理化で実行される。診断プログラムは実行時に、前記実行頻度を調整する手段の内容を参照し、自らの実行時間の制限を行う。具体的には、診断を行わない期間を設け、その期間は休止処理を行って、システムに対する負荷をゼロとなるように制御する。前記実行頻度を調整する手段には、１回の診断を行う時間と、診断を実行する間隔が記録されている。例えば、１回の診断を行う時間を０．１秒以下とし、診断を実行する間隔を１００秒と記録しておくことで、診断プログラムは１００秒毎に診断を０．１秒の時間だけ実行するため、システムへの負荷を平均０．１％以下とすることが可能となる。

診断プログラムは診断実行時にシステムに存在するプロセッサの個数分だけ自らの複製を作成し、該複製された診断プログラムはシステムの各プロセッサの上で実行され、各プロセッサについて診断を実行する。このように、通常は各プロセッサには診断のためのプログラムは存在せず、必要なときにだけ複製を作成することでシステムの資源消費がおさえられるため、システムへの負荷を軽減することができる。

プロセッサの診断の結果、障害を検出した場合には障害発生を示す情報を記録して、当該プロセッサ上の診断プログラムは処理を停止する。障害発生したプロセッサに隣接するプロセッサは、自身の診断処理を終了した後、前記障害発生を示す情報を参照し、隣接プロセッサでの障害発生を確認する。障害発生を検出した場合には、隣接プロセッサの障害を処置するための処理を行う。

障害時の処理を障害が発生したプロセッサとは別の正常なプロセッサが行うことにより、より信頼性の高い障害処理が可能となる。障害処置方法は、ユーザの指定で選択することが可能であり、例えば障害発生したプロセッサのみをシステムから切り離し、他のプロセッサは処理を継続することも可能であるし、システム全体を停止することも可能である。

本発明により、システムにおいて通常のアプリケーションを実行中にも定期的に診断プログラムを実行することが可能となるため、システムの信頼性を高めることができる。また、診断プログラムがシステムに与える負荷を制限することが可能なため、システムにおいて実行されるアプリケーションの性能低下を最小限に留めることができる。さらに、プロセッサに障害が発生した場合、障害処理を正常な隣接プロセッサがおこなうため、システムに発生する障害を未然に予防し、障害の影響を最小限に留めることが可能となる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。

図１は本発明の一実施形態によるプロセッサの診断処理方法の動作を示すフローチャートであり、図２は各プロセッサでの診断方法を示すフローチャートであり、図３はプロセッサの診断処理方法が実行されるシステムの構成を示すブロック図である。図１および図２中、Ｓ１からＳ２５は処理手順であり、図３中、１から３はプロセッサであり、４は主記憶であり、５から６は外部記憶装置であり、７はバスであり、１０はＯＳであり、１１はアプリケーションであり、１２は診断プログラムである。

図３において、プロセッサ１から３は複数個としているが、プロセッサの個数は１個でも構わないし、複数個の場合にはその個数は何個でも構わない。また図３ではプロセッサ１から３は、バス７を介して主記憶４、外部記憶装置５から６と接続されているが、接続の形態はこれ以外でも構わない。例えば、プロセッサ１から３と主記憶４の間に主記憶制御装置が介在していてもよい。プロセッサ１から３と外部記憶装置５から６との接続に関しても同様に、他の制御装置が介在していても構わない。主記憶４と外部記憶装置５から６との接続に関しても同様である。図３では外部記憶装置５および外部記憶装置６の２つが存在しているが、１つの外部記憶装置であっても構わないし、３つ以上の外部記憶装置であっても構わない。

システム起動時には、外部記憶装置５に格納されたＯＳ１０が読み出され、プロセッサ１から３がこれを実行することで、システムが使用可能となる。ＯＳ１０の起動完了後、ユーザは必要に応じてアプリケーション１１を実行することができる。前記ＯＳ１０の起動時には、その起動過程で外部記憶装置５に格納された診断プログラム１２が起動される。診断プログラム１２が実行されることで、本発明の目的であるプロセッサ障害の診断を行う。ＯＳ１０の起動時に診断プログラム１２を起動する方法については、ＯＳ１０に備えられた標準的機能を用いて行う。例えばＵＮＩＸの場合であれば、（ＵＮＩＸは登録商標です）/etc/inittabというファイルに診断プログラム１２の起動を示す行を加えることで、目的を達成することが可能である。この際、診断プログラム１２が実行状態となっていても、ユーザは同時にアプリケーション１１を実行することができる。診断プログラム１２はＯＳ１０の上で実行される１つのプログラムであるため、他のプログラムの実行を妨げるものではない。

次に、図１から図３を用いてプロセッサ障害の診断の詳細について説明を行う。診断プログラム１２はＯＳ１０によって起動されると、図１に示す処理手順によって実行される。まず、処理手順Ｓ１にしたがい、実行頻度の判定を行う。診断プログラム１２はＯＳ１０の上で実行される１つのプログラムであるため、診断プログラム１２の実行により、ＯＳ１０が実行するその他のプログラム（例えばアプリケーション１１）の性能に影響を及ぼす。この影響を最小限にするために実行頻度の判定を行う。診断プログラム１２は前回診断を行った時刻情報を外部記憶装置６におかれた実行頻度指定情報１５に記録を行っている。なお、図３では実行頻度指定情報１５は外部記憶装置６におかれているが、主記憶４、または、外部記憶装置５においても構わないし、それ以外の記憶装置においてもよい。

診断プログラム１２はこの時刻情報を処理手順Ｓ１において参照し、前回診断を行った時刻から一定時間が経過するまでは、診断プログラム１２を休止状態とする。休止状態とすることで、他のプログラム（例えばアプリケーション１１）はシステムにおいて性能低下することなく実行することが可能となる。休止状態とする手段については、ＯＳ１０に備えられた標準的機能を用いて行う。例えばＵＮＩＸの場合であればsleep関数を実行することで目的を達成することが可能である。診断プログラム１２を休止状態とする時間については、固定値としてもよいし、ユーザが設定できるよう、設定手段を設けても構わない。休止状態が終了して診断を開始する際、その時刻を実行頻度指定情報１５に新たに記録を行う。

処理手順Ｓ１の後、処理手順Ｓ２が実行される。処理手順Ｓ２ではプロセッサ障害の診断を行うための診断項目の選択が行われる。後述するように、診断プログラム１２は前回診断を行った診断項目の情報を外部記憶装置６におかれた診断内容指定情報１６に記録を行っている。なお、図３では診断内容指定情報１６は外部記憶装置６におかれているが、主記憶４、または、外部記憶装置５においても構わないし、それ以外の記憶装置においてもよい。

診断プログラム１２はこの診断内容指定情報１６を処理手順Ｓ２において参照し、今回の診断において実施する診断の内容を決定する。診断内容を図４を用いて説明する。図４は診断内容の集合を表すテーブルである。テーブル中２０から２４はフィールドである。フィールド２０は個々の診断内容に割り当てられた番号を示しており、フィールド２１は診断内容の項目を示しており、フィールド２２は診断で用いる演算値を示しており、フィールド２３は診断に要する時間の見積値を示している。なお、図４中、フィールド２０およびフィールド２１は本発明を説明するため便宜上設けたフィールドであり、実際のプログラムでは必ずしも物理的実体としてこれらのフィールドは設けなくても動作に支障はない。

図４のテーブルに示されたエントリの一つ一つが具体的な診断内容を示している。例えば、フィールド２０の値が「１」であるエントリは、固定小数点演算のうち、加算が正しく行われるか否かを診断することを表しており、この診断のためにフィールド２２で示される演算値を用いる。つまり、実際の診断においては、各プロセッサでフィールド２２で示される「Ａ」と「Ｂ」の値の加算を行い、「Ｃ」の値と比較を行う。両者が等しければ診断結果は正常でありプロセッサに異常はないと判断する。もし両者が等しくなければプロセッサに異常が発生したと判断して、障害処理を行う（詳細は後述する）。なお、図４ではフィールド２２で示した演算値が各エントリで同じ表記になっているが、実際にはエントリ毎に異なった値であってもかまわない。

なお、上記診断にあたり、異常と判定された場合については、異常となった診断内容を複数回反復して診断を行ってもよい。例えば、あらかじめ基準回数を定めておき、一定回数以内しか異常が発生しない場合には、診断結果の報告のみを行い、後述する障害処理を行わないという処理方式をとっても構わない。

診断内容指定情報１６には図４のテーブルの各エントリの内容を診断する毎に、診断が終了したエントリのフィールド２０の値が格納される。ただし、後述するように、図４のテーブルの内容を複数一度に診断する場合は、診断内容指定情報１６の更新はまとめて行っても構わない。また、図４においては、加減乗除算のように単純な診断項目のみを例示しているが、より複雑な診断内容であっても構わない。

このようにして、診断プログラム１２はこの診断内容指定情報１６を処理手順Ｓ２において参照し、今回行う診断の内容を更新していく。診断プログラム１２は１回の診断で図４のテーブルの複数エントリを一度に診断することができる。このとき何項目を一度に診断すべきか判定するために図４のフィールド２３の値を参照する。フィールド２３の値は診断に要する時間の見積値であり、複数エントリについてこの値を積算することで診断に要する時間の総計を知ることができる。本実施例では、フィールド２３の値は時間であるとしたが、最終的に実行時間の情報を得られるものであれば、フィールド２３の内容は時間でなくても構わない。例えば診断の命令数などであってもよい。

１回の診断における診断時間については、固定値としてもよいし、ユーザが設定できるよう、設定手段を設けても構わない。また、例えば、診断の実行時にシステムの負荷に関する情報を収集して、この値に応じて診断時間を増減してもよい。仮に実行頻度指定情報１５も用いて判断する、診断プログラムの診断間隔を１００秒とし、１回の診断における診断時間を０．１秒とすれば、診断プログラム１２によるシステムへの負荷を平均して０．１％以下とすることができる。このようにして、本発明では診断プログラム１２を実行していても、ユーザが実行するプログラム（例えばアプリケーション１１）にほとんど性能低下を与えないよう制御を行うことが可能である。また、必要に応じて診断プログラム１２を優先的に実行するよう設定を行うことも可能である。

処理手順Ｓ２の後、処理手順Ｓ３が実行される。処理手順Ｓ３ではシステムで使用可能なプロセッサの数を取得する。

処理手順Ｓ３の後、処理手順Ｓ４が実行される。処理手順Ｓ４では取得したプロセッサの数に応じて、診断プログラム１２の複製を行う。これは、診断プログラム１２をシステムで使用可能な全てのプロセッサにおいて実行させるためである。なお、本実施例では、診断プログラム１２をシステムで使用可能な全てのプロセッサにおいて同時に診断を行うものとして説明しているが、各プロセッサでの診断タイミングは必ずしも同時でなくても構わない。例えば、１回の診断時には１個のプロセッサのみ診断し、診断毎に別のプロセッサを順番に診断するような方式でも構わない。

診断プログラム１２の複製は、ＯＳ１０に備えられた標準的機能を用いて行う。例えばＵＮＩＸの場合であればsystem関数でもよいし、fork関数を用いてもよい。また、必ずしもプロセッサ毎にプロセスを生成せず、単一プロセスのままでマルチスレッドを用いてもよい。例えばＰＯＳＩＸに準拠したシステムであれば、pthread_create関数を実行することで目的を達成することが可能である。

上記複製によって、処理手順Ｓ１０からＳ１２に示されるプロセスないしスレッドが生成される。処理手順Ｓ１０からＳ１２は後述するようにそれぞれ異なったプロセッサの上で実行されるが処理内容は全く同一である。処理手順Ｓ１０からＳ１２の処理内容を図２を用いて説明する。

最初に処理手順Ｓ２０が行われる。処理手順Ｓ２０では、前記処理手順Ｓ１０からＳ１２をシステムに存在する個々のプロセッサで実行させるために、バインド処理を行う。例えば、処理手順Ｓ１０はプロセッサ１で実行され、処理手順Ｓ１１はプロセッサ２で実行され、処理手順Ｓ１２はプロセッサ３で実行されるようにバインド処理を行う。バインド処理はＯＳ１０に備えられた標準的機能を用いて行う。例えば、Sun Microsystems社のSolarisの場合には、pbindによって、HP社のHP-UXの場合にはpsrsetによって、IBM社のAIXの場合には、bindprocessorを実行することによって、目的を達成することが可能である。

処理手順Ｓ２０の後、処理手順Ｓ２１が実行される。処理手順Ｓ２１では個々のプロセッサにおいて、具体的な診断が行われる。診断の項目については、先に図４を用いて説明したとおりである。診断内容指定情報１６によって示された診断内容について、診断を実施する。

処理手順Ｓ２１の後、処理手順Ｓ２２が実行される。処理手順Ｓ２２では診断の結果障害が存在したか否かが判定される。複数の診断内容について診断を行う場合には、複数の処理手順Ｓ２１をまとめて実施の後、対応する処理手順Ｓ２２をまとめて行ってもよいし、個々の診断毎に処理手順Ｓ２１の後、処理手順Ｓ２２を実行し、これを繰り返してもよい。個々の診断に際しては、診断状態が診断状態情報１７に格納される。なお、図３では診断状態情報１７は外部記憶装置６におかれているが、主記憶４、または、外部記憶装置５においても構わないし、それ以外の記憶装置においてもよい。

診断状態情報１７に格納される情報について図５を用いて説明する。図５は診断状態情報１７に格納される内容を表すテーブルである。テーブル中３０から３２はフィールドである。フィールド３０は診断状態がどのプロセッサの状態であるかを示しており、フィールド３１は診断実行の結果がどのような状態であるかを示しており、フィールド３２は診断に関するその他の情報を示している。診断状態情報１７には、プロセッサ分だけエントリが用意されている。

処理手順Ｓ２２で診断結果の判定を行う度に、自プロセッサのエントリについて、診断状態情報１７の内容が更新される。まず、処理手順Ｓ２０において、フィールド３１に状態「実行中」が格納される。そして、診断を実施する毎にフィールド３２には、診断項番（図４で示したフィールド２０の値）が格納される。１回の診断で行う診断内容について、すべて正常であった場合には、フィールド３１に状態「実行完」が格納され、処理手順Ｓ２３へ移行する。処理手順Ｓ２３では今回の診断に関するログ情報の記録と、診断内容指定情報１６の更新が行われる。

処理手順Ｓ２２で障害が検出された場合には、処理手順Ｓ２５へ移行する。そして、診断状態情報１７の自プロセッサに対応するエントリにおいて、フィールド３１に状態「障害」が格納される。フィールド３２には、障害発生を検出した診断の診断項番（図４で示したフィールド２０の値）と、障害に関する情報が格納される。障害に関する情報には診断時に行った演算結果の値、プロセッサのその他の情報などが格納される。これらの処理の後、障害の発生したプロセッサでは診断プログラム１２は実行を終了する。

障害を検出して以降は、当該プロセッサでは診断プログラム１２は実行されない。すなわち、それ以降の実行時には、処理手順Ｓ４において診断状態情報１７の内容を参照し、フィールド３１が状態「障害」となっていたプロセッサについては、診断プログラム１２は実行されない。これを図６を用いて説明する。図６は診断状態情報１７のフィールド３１に示される状態の状態遷移を表した図である。図６中、４０から４２は状態である。

診断開始時には、処理手順Ｓ２０において、フィールド３１は状態「実行中」４０になる。ただし、処理手順Ｓ２０開始時に状態が「障害」４２であった場合は、状態は「実行中」４０にならない。診断が終了し、診断結果が正常であった場合には、状態は「実行完」４１となる。通常は、状態は「実行中」４０と「実行完」４１のみを移る。そして障害検出時に状態は「障害」４２となり、診断プログラム１２の実行中は「障害」４２のまま状態は保たれる。

障害検出後に、当該プロセッサを交換した場合、または、交換をしていなくても、当該プロセッサにおいて障害の再現試験を行う場合については状態は「障害」４２から「実行完」４１に移行させることができる。移行のための手段は診断プログラム１２とは別に用意される。

障害が検出された場合、その後の処置は障害が発生したプロセッサとは別のプロセッサにおいて行われる。以下、その手順を説明する。処理手順Ｓ２３の後、処理手順Ｓ２４が実行される。処理手順Ｓ２４では他のプロセッサでの障害発生時の処置を行う。処理手順Ｓ２４においては、診断状態情報１７の内容を参照し、自プロセッサに隣接しているプロセッサのフィールド３１の値を確認する。もしフィールド３１が状態「実行完」であれば、何もせずに処理手順Ｓ２４を終了する。もしフィールド３１が状態「障害」の場合には、そのプロセッサに対する障害処置を行う。この際に実行する処置の内容は固定的であってもよいし、ユーザが選択できるよう、選択手段を設けてもよい。障害処置としては、例えば、当該プロセッサのみをシステムから切り離し、残りのプロセッサについては処理を継続させてもよいし、あるいは、システム全体をシャットダウンさせてもよい。また、プロセッサの切り離しを行わず、ユーザに警告を発するだけでシステムをそのまま継続処理させてもよい。

例えば、システムに２個以上のプロセッサが存在する場合にはプロセッサの切り離しを行い、システムにプロセッサが１個だけ存在する場合にはシステム全体をシャットダウンさせるという方式でもよい。

なお、障害が発生したプロセッサの処置をどのプロセッサが行うかについては、必ずしも隣接プロセッサが行わなくてもよい。例えば、２個のプロセッサが同一のＬＳＩに実装されているような場合には、隣接プロセッサにも障害が発生している可能性があるため、このような場合には隣接ではない対応関係をあらかじめ決めておき、その対応関係によってどのプロセッサが、どのプロセッサの障害処置を行うか上記と異なる方法を用いても構わない。

また、複数プロセッサで同時に障害が発生した場合については、同様に、対応関係を定めておき、それにしたがって処置を行えばよい。例えば、隣接プロセッサに障害が検出された場合には、さらにその隣のプロセッサに障害が発生していないか確認を行う方法などを用いればよい。

本発明においては、上記のようにプロセッサに障害が発生した場合、障害処置を他の正常なプロセッサが行うため、障害発生時でもその対応を正常に実施することのできる可能性が高く、より信頼性の高いシステムとすることが可能である。

処理手順Ｓ４で、診断プログラム１２の複製を行ったプロセス（またはスレッド）は、処理手順Ｓ５を実行する。処理手順Ｓ５では各プロセッサで実行している処理手順Ｓ１０からＳ１２について、実行時間の監視を行う。既に述べたように、個々の処理手順Ｓ１０からＳ１２においては、診断時間を定められた時間以内にするための処理を行っているが、システムの状況によっては診断プログラムの実行時間があらかじめ想定した時間では終了しない場合も存在しうる。このような場合でもシステムに対する負荷を保証するために、処理手順Ｓ５では実行時間の監視を行い、もし定められた時間を超過した場合には、処理手順Ｓ１０からＳ１２を中途で打ち切り、強制終了させる。

もし、強制終了中に診断状態情報１７において障害検出が見出された場合には、まず、障害が発生していないプロセッサに自身のプロセスないしスレッドのバインド処理を行う。その後、前述と同様の手順で障害処置を行い、処理手順Ｓ５を終了し、処理手順Ｓ６に移行する。

処理手順Ｓ５においては、さらに、システムの監視を行う。システムによっては稼動中にプロセッサ数の増減が可能なものが存在する。例えば、１つのハードウエアを仮想的に複数のハードウエアとして分割して使用することの可能なシステムにおいて、分割後に複数のハードウエア相互の間でプロセッサの授受を実行するようなシステムがその例である。処理手順Ｓ５ではプロセッサ数の変更要求を検出し、プロセッサ数が変化する場合、特にプロセッサ数が減少する場合に必要な処理を行う。すなわち、削減の対象となったプロセッサで実行されている診断プログラム１２を強制終了させ、システムによるプロセッサの増減に速やかに対応する。処理手順Ｓ５で強制終了が必要でなかった場合には、そのまま処理手順Ｓ６に移行する。

処理手順Ｓ６では、診断プログラム１２の複製の終了の待ち合わせを行う。全ての複製が終了したら、処理手順Ｓ７に移行する。処理手順Ｓ７では、診断内容指定情報１６の更新を行う。すなわち、診断状態情報１７のフィールド３２に記録された診断項番の情報で診断内容指定情報１６に更新する。

処理手順Ｓ５で強制終了が行われた場合には、診断状態情報１７のフィールド３２の内容はプロセッサ毎に異なっている可能性が高い。このような場合には、最も処理数の少なかったプロセッサの情報を用いて診断内容指定情報１６の更新を行う。

処理手順Ｓ７の後、処理手順Ｓ８を実行する。処理手順Ｓ８では、診断プログラム１２自身に問題が発生していないか自己確認を行う。問題が検出されなければ、処理手順Ｓ１に移行して、システムの診断の続行を行う。もし何らかの問題が検出された場合には、診断プログラム１２を終了させる。

上記においては、診断対象をプロセッサとして説明を行ったが、本発明は診断の対象をシステムの他の資源、たとえばＰＣＩカードのようなＩ／Ｏ資源に対して同様の手段で適用することが可能である。

その際、本実施例においては、図４で示した診断内容を診断対象に適合した内容に置きかえを行う。また、処理手順Ｓ２１を実行する際には診断対象について、前記診断内容の診断を実施することが可能か否かの確認を行う。これは、例えばＩ／Ｏ資源の場合には他のプロセスの処理の途上にある可能性があるため、診断を行う時点で必ずしも全ての診断内容を実施可能とは限らないためである。

このように、診断内容を変更することで、本発明はプロセッサ以外のシステムの資源に対してもそのまま適用することができる。これにより、より広範な資源に関して、アプリケーション稼動時にシステムの障害を検出することが可能となり、システムの信頼性向上に寄与する。

次に、本発明の第２の実施の形態について説明を行う。本発明は第１の実施の形態の変形であり、第１の実施の形態よりも障害検出の効率を向上させることが可能である。

本実施例においては、図１の処理手順Ｓ２を実行する際の手順が第１の実施例とは異なる。本実施例では処理手順Ｓ２において、その実行が診断プログラム１２の起動直後であった場合には、診断内容指定情報１６の示す診断内容およびその前後の項番の診断内容について、通常診断を試行する回数の数倍の回数だけ診断を行う。

プロセッサで障害が発生した場合、診断プログラム１２で検出する以前にシステムの障害として症状が発生してシステムダウンが起こる可能性がある。また、診断プログラム１２が検出に成功した場合でも障害処置より前に診断プログラム１２に障害が発生するか、システムに障害が発生するかのどちらかにより、障害を報告、処置する前にシステムダウンが起こる可能性がある。

このような場合、診断内容指定情報１６に障害を検出した診断内容そのものかまたは、近傍の診断内容が格納されている可能性が高い。したがって、システム起動時に診断内容指定情報１６の指し示す診断内容の近傍の診断を実行することで再度障害を検出できる可能性が高い。

このように、本実施例によれば、プロセッサ障害が発生して障害後の処置に失敗した場合でも、障害を再現させることが容易となり、障害原因を突き止めることが可能になるため、より信頼性の高いシステムを構築することが可能となる。

次に、本発明の第３の実施の形態について説明を行う。本発明は第１の実施の形態または第２の実施の形態の変形であり、第１の実施の形態または第２の実施の形態よりもシステムに負荷をかけずに診断プログラム１２を実行させることが可能である。

図７は本発明の一実施形態によるプロセッサの診断処理方法と診断処理装置および診断プログラムにおいて、第１の実施の形態で述べた診断プログラム１２を監視するプログラム（以下監視プログラムと呼ぶ）の動作を示すフローチャートである。図１中、Ｓ３０からＳ３４は処理手順である。

本実施例においても診断プログラム１２の動作は第１の実施例と同様である。ただし、以下の一点のみ異なる。すなわち、診断プログラム１２はＯＳ１０から起動されるのではなく、図７で動作を説明する監視プログラムによって起動される。

監視プログラムは診断プログラム１２と同様、図３に示すシステム上で実行される。監視プログラムは、ＯＳ１０の起動時にＯＳ１０によって起動される。起動方法は、第１の実施例における診断プログラム１２の起動方法と同様である。起動後の監視プログラムの動作について、図７を用いて詳細に説明を行う。監視プログラムはＯＳ１０によって起動されると、図７に示す処理手順によって実行される。まず、処理手順Ｓ３０にしたがい、実行頻度の判定を行う。処理手順Ｓ３０の実現手段、および、目的は、第１の実施例における処理手順Ｓ１と同様である。すなわち、監視プログラムの実行がシステムに負荷を与えないようにするために、処理手順Ｓ３０を行う。

処理手順Ｓ３０の後、処理手順Ｓ３１が実行される。処理手順Ｓ３１では診断プログラム１２の動作状況の確認を行う。システムに何らかの問題が発生した場合、または、診断プログラム１２自身に問題点が存在したために、診断プログラム１２が実行を終了していないかどうか確認を行う。また、何らかの制御の異常によって、診断プログラム１２が複数個同時に起動されているような事態が発生していないかも同時に確認を行う。

上記確認の後、処理手順Ｓ３２で診断プログラム１２の再実行の必要性について判定を行う。診断プログラム１２が実行を終了してる場合または、診断プログラム１２が複数個同時に起動されているような場合には、処理手順Ｓ３３に移行する。

処理手順Ｓ３３では、診断プログラム１２の再実行を行う。すなわち、診断プログラム１２が実行を終了してる場合には、診断プログラム１２を再度起動し、診断プログラム１２が複数個同時に起動されているような場合には、一旦全ての診断プログラム１２を終了させた後、診断プログラム１２を再度起動する。

処理手順Ｓ３４では監視プログラム自身に問題が発生していないか自己確認を行う。問題が検出されなければ、処理手順Ｓ３０に移行して、監視の続行を行う。もし何らかの問題が検出された場合には、監視プログラムを終了させる。

監視プログラムを実行することには次のような利点が存在する。第１の実施例のままであっても、診断プログラム１２の再起動だけであれば次のような手段を用いることで実現可能である。例えば、ＵＮＩＸの場合であれば、/etc/inittabというファイルに診断プログラム１２を登録する際に、respawn属性を指定すれば、ＯＳ１０が診断プログラム１２の監視を行い、診断プログラム１２が停止している場合にはＯＳ１０が再起動を行う。この場合、/etc/inittabから起動するプログラムは１つに限定される。

現在存在するシステムにおいては、同一のＯＳであっても設定を変更するだけで複数のモードで実行できるものが存在する。例えば、３２ビット／６４ビットのモード切り替えをファイル設定だけで行えるシステムが存在する。しかし、３２ビットモードと６４ビットモードではそれぞれ専用のプログラムが必要であることが多いため、単一の診断プログラム１２を用いると、プログラムサイズが巨大化するという問題点がある。３２ビット／６４ビット以外にもシステムに同様のモード切り替え事由が存在した場合、診断プログラム１２のプログラムサイズはさらに巨大化する
このような場合、起動時にモードを判定して起動する診断プログラム１２を環境に応じて切り替えられれば、より効率良く診断を行うことができる。本実施例により、起動時に診断プログラム１２を選択することが可能になるため、診断プログラム１２の個々のファイルサイズを削減することが可能となり、実行時に消費する主記憶容量を削減することが可能になり、したがって、プロセッサ上で消費する命令キャッシュの容量も削減可能となるため、システムに対する影響をさらに軽減することが可能になる。

診断プログラムの動作を示すフローチャートである。 診断プログラムの動作を示すフローチャートである。 診断プログラムが実行されるシステムの構成図である。 診断内容の集合を表すテーブルである。 診断状態情報に格納される内容を表すテーブルである。 診断状態の状態遷移図である。 監視プログラムの動作を示すフローチャートである。

符号の説明

１〜３ プロセッサ
４ 主記憶
５、６ 外部記憶装置
７ バス

Claims (9)

1. 一個または複数個のプロセッサからなるシステムの各プロセッサの診断を行う診断処理方法において、前記システムの起動時に記憶手段から読み出された診断プログラムが起動され、前記診断プログラムが各プロセッサの診断を行うための一個または複数個のプロセス又はスレッドを所定の間隔で生成し、前記生成されたプロセス又はスレッドが各プロセッサ上で所定の診断を実行して終了することを特徴とするプロセッサの診断処理方法。
2. 前記診断プログラムは前記プロセス又はスレッドの実行状態を監視し、所定時間内に診断の実行が終了しなかった場合には前記プロセス又はスレッドを強制終了させることを特徴とする請求項１記載のプロセッサの診断処理方法。
3. 自プロセッサでの障害の発生を検出したプロセス又はスレッドは障害情報を記憶手段に格納して終了し、前記障害発生プロセッサとは別のプロセッサのプロセス又はスレッドが前記記憶手段に格納された前記障害発生プロセッサの障害情報を参照して所定の障害処理を行うことを特徴とする請求項１記載のプロセッサの診断処理方法。
4. 前記所定の障害処理は、障害が発生したプロセッサのみをシステムより切り離す処理であるか又はシステム全体を停止する処理であることを特徴とする請求項３記載のプロセッサの診断処理方法。
5. 前記システムの起動時に監視プログラムが起動され、前記監視プログラムが所定の診断プログラムを起動し、起動した診断プログラムの走行状態を監視し、前記診断プログラムに異常があれば前記診断プログラムの停止又は再起動を行うことを特徴とする請求項１記載のプロセッサの診断処理方法。
6. 前記システムはプロセッサ構成を動的に変更可能なシステムであって、前記診断プログラムがプロセッサの構成変更を検出した場合には、構成変更後の各プロセッサ上で診断を実行させることを特徴とする請求項１記載のプロセッサの診断処理方法。
7. 前記診断プログラムはプロセッサ診断を実行中にプロセッサの構成変更を検出した場合には、プロセッサ診断の実行を中断し、プロセッサの構成変更の完了後にプロセッサ診断の再実行を行わせることを特徴とする請求項６記載のプロセッサの診断処理方法。
8. プロセッサを診断する内容は独立に実行可能な複数の診断内容の集合として構成され、前回診断を行った診断内容を示す診断内容指定情報を格納する記憶手段を備え、前記診断プログラムは前記診断内容指定情報により今回診断を行う診断内容を決定することを特徴とする請求項１記載のプロセッサの診断処理方法。
9. 一個または複数個のプロセッサを具備するコンピュータシステムに各プロセッサの診断を実行させるための診断処理プログラムであって、プロセッサ診断を実行しない期間に休止処理を行うステップと、プロセッサ診断を開始するタイミングを決定するステップと、システム上のプロセッサ数に対応してプロセッサ診断のための一個または複数のプロセス又はスレッドを生成するステップと、前記生成されたプロセス又はスレッドをシステム上の各プロセッサ上で実行させるステップとをコンピュータシステムに実行させるための診断処理プログラム。
   

Images