(57)【要約】【課題】マルチタスクオペレーティングシステムにおいて障害タスクを精度良く検出し得る構成を提供することを目的とする。【解決手段】ＣＰＵの高負荷状態を検出する高負荷継続検出手段と、タスク間切替動作の履歴を保存するタスク間切替履歴保存手段と、前記高負荷継続検出手段によってＣＰＵの高負荷状態が検出された場合、タスク間切替履歴保存手段によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の原因たる異常タスクの候補を抽出する異常タスク候補抽出手段とよりなる。【選択図】図５
2008102778.tif 000002
【特許請求の範囲】
【請求項１】
マルチタスクオペレーティングシステムを有する情報処理装置であって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出手段と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存手段と、
前記高負荷継続検出手段によってＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存手段によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出手段とよりなる情報処理装置。
【請求項２】
更に前記異常タスク候補抽出手段によって抽出された異常タスクの候補としてのタスクの動作を監視することによって前記異常タスクを検出する異常タスク検出手段よりなる請求項１に記載の情報処理装置。
【請求項３】
マルチタスクオペレーティングシステムを有する情報処理装置の制御方法であって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出段階と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存段階と、
前記高負荷継続検出段階においてＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存段階によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出段階とよりなる制御方法。
【請求項４】
更に前記異常タスク候補抽出段階において抽出された異常タスクの候補としてのタスクの動作を監視することによって前記異常タスクを検出する異常タスク検出段階よりなる請求項３に記載の制御方法。
【請求項５】
マルチタスクオペレーティングシステムを有する情報処理装置の制御をコンピュータに実行させるためのプログラムであって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出段階と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存段階と、
前記高負荷継続検出段階においてＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存段階によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出段階とをコンピュータに実行させるための命令よりなるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、情報処理装置の制御方法及びプログラムに係り、特にマルチタスクオペレーティングシステムを有する情報処理装置、当該情報処理装置の制御方法及び同情報処理装置の制御方法をコンピュータに実行させるためのプログラムに関する。
【背景技術】
【０００２】
例えば優先度付きマルチタスクオペレーティングシステム（以下、オペレーティングシステムを単にＯＳと称する）を搭載したコンピュータシステムにおいて、ＣＰＵの負荷が100％の状態がある一定時間継続する状態を異常状態として検出するための手法として以下の方法が考えられる。すなわち、異常監視タスク(最高優先度)と異常検出タスク(最低優先度)とで構成されたプログラムにおいて、同異常検出タスクが一定時間動作していないことを異常監視タスクが検出することで判定する方法である（特許文献１参照）
又ＣＰＵ負荷が100％の状態がある一定時間継続して発生した際、その原因として、あるタスク上で動作するプログラムが無限ループ動作を行っている場合が考えられるが、その原因となっているタスクを検出するための手法として以下の方法が考えられる。すなわち異常監視タスク(最高優先度)が異常を検出した際、異常検出タスク(最低優先度)だけでなく全てのタスクに対し、それらが動作しているかどうかについての検査を行うことにより当該異常の原因となったタスクを特定する方法である(特許文献２参照)。
【０００３】
上記特許文献１に開示された方法では、上記の如く、ＣＰＵの負荷が100％の状態がある一定時間継続する状態を異常状態として検出するが、実際には無限ループ動作状態に陥っていなくとも負荷の高い処理により一時的にＣＰＵ負荷が100％状態になるような場合も想定される。同方法によればそのような場合であっても異常状態として誤検出されてしまう。ここで異常状態が検出されると自動的に何らかのリカバリー処理が実行されるようにプログラムされていた場合には不要なリカバリー処理を行うこととなってしまう。
【０００４】
又高優先度のタスクが高負荷になった場合、それより低優先度のタスクは動作できなくなる場合が想定される。そのような場合特許文献２の開示技術による手法では被疑タスクを特定することができなくなってしまう。又複数のタスク間でメッセージのやり取りが無限に行われる現象(いわゆる「ピンポン現象」)が発生すると当該複数のタスクが高負荷状態となるため、一の被疑タスクを特定することはできなくなる。
【０００５】
ここで上記ピンポン現象については後述する。
【特許文献１】特開２０００−１８１７５５号公報
【特許文献２】特開平１０−１１３２７号公報
【特許文献３】特開２０００−２６７８９５号公報
【特許文献４】特開２００３−３４５６２９号公報
【特許文献５】特開２００５−０６３２９５号公報
【特許文献６】特開２００６−０１１６８６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は上記問題点に鑑み、マルチタスクオペレーティングシステムにおいて障害タスクを精度良く検出し得る構成を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明ではＣＰＵの高負荷状態の継続を検出する高負荷継続検出手段と、タスク間切替動作の履歴を保存するタスク間切替履歴保存手段と、前記高負荷継続検出手段によってＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存手段によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出手段とを設けた。
【０００８】
このように高負荷継続検出手段によってＣＰＵの高負荷状態の継続が検出された場合にタスク間切替履歴保存手段によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出するようにしたため、異常タスクの候補を効果的に絞り込むことが可能となる。このようにして異常タスクの候補を絞り込むことにより、それら異常タスクの候補に対してのみ以後集中して継続監視を行うことが可能となる。したがって効率的に確実な異常タスクの検出が可能となる。
【発明の効果】
【０００９】
本発明によれば上記の如く効果的に異常タスクの候補を絞り込むことが可能であり、その後それら異常タスクの候補に対してのみ集中して継続監視を行うことにより、効率的に確実な異常タスクの検出を行い得る。
【発明を実施するための最良の形態】
【００１０】
本発明の一実施例としての障害タスク検出プログラムは、優先度付きの複数タスクを持つ機能を有するＯＳ上で動作するアプリケーションプログラムが何らかの原因で無限ループ動作状態に陥ったような場合に、それを検出する機能を提供する。
【００１１】
すなわち本発明の実施例によれば、マルチタスクＯＳの動作中、ＣＰＵ負荷が100％の状態が継続して発生した場合に、その原因がプログラムの不正処理(無限ループ動作等)によるものであるのか、或いは単に負荷の高い処理による一時的な高負荷状態の継続であるのかを判別し、プログラムの不正処理によるものであると判別された場合にはその原因と見られるタスク（以下「被疑タスク」と称する）を特定する機能を提供する。
【００１２】
またプログラムの不正処理によるものと判別された場合、異常状態として外部に通知する機能を提供する。
【００１３】
またプログラムの不正処理によるものと判別された場合、当該障害に対する対応処理を選択して設定する機能を提供する。
【００１４】
また高負荷状態の継続が検出された場合に、その原因たるタスクの情報を履歴として取得し、後ほどその履歴情報を参照するための機能を提供する。
【００１５】
また高負荷状態の継続が検出された場合に、それが負荷の高い処理による一時的な事象では無く、複数タスク間でデータのやり取りが無限に行われる事象、すなわちピンポン現象であった場合に、それを検出する機能を提供する。
【００１６】
ここで本実施例では、ＯＳが以下の４つの機能ｉ），ｉｉ）、ｉｉｉ）、ｉｖ）を有することを前提とする。
ｉ）タスク優先度に従って各タスクを実行する機能(図１参照：すなわちタスクスケジューラ機能)
ｉｉ）実行されるタスクの切替（いわゆる「タスクスイッチ」）が発生した場合、該当するタスクを判別する機能(図２中の機能２)
ｉｉｉ）タスクの現実行状態(図３参照)を取得する機能
ｉｖ）タスク間のメッセージ送受信状態(図４参照)を取得する機能
上記機能ｉ）は、図１で示されるように、予め各タスクに優先度が与えられた場合、各タスク（すなわちアプリケーションタスク）をその優先度に従って動作させる機能である。
【００１７】
上記機能ｉｉ）は図２中の機能2に相当する機能であり、タスクスイッチが発生した際にあらかじめ登録された対応するハンドラ処理を実行する機能（機能２の説明として後述する）である。
【００１８】
上記機能ｉｉｉ）は、各タスクの現実行状態が図３で示される３種の実行状態、すなわち実行中の状態（Ｒｕｎｎｉｎｇ）、実行可能な状態（Ｒｅａｄｙ）及び実行待ち状態（Ｗａｉｔｉｎｇ)のうちのどの状態にあるのかを取得する機能である。
【００１９】
尚図３中、各用語の意味は以下の通りである。
【００２０】
Ｄｉｓｐａｔｃｈ：実行権を与えることにより他のタスクを実行中の状態に移行させ自己が実行可能な状態に移行する動作
Ｐｒｅｅｍｐｔｉｏｎ：実行権を受けて実行中の状態に移行する動作
Ｒｅｃｅｉｖｅ：実行中の状態にあるタスクがメッセージの受信を待つために実行待ち状態に移行する動作
Ｓｅｎｄ，Ｓｔａｒｔ：実行待ち状態にあるタスクが所定のメッセージを送信し実行可能な状態或いは実行中の状態に移行する動作
Ｓｔｏｐ：所定の条件により実行可能な状態から実行待ち状態に移行する動作
又、各タスク状態の定義を以下に示す。
【００２１】
実行中の状態（Running）：
・ある与えられた時間において、Running状態になることができるタスクは、１プロセッサにつき１つのみである。
・Running状態のタスクは、プログラム中の命令を実行する。
・タスクスケジューラは、現在実行中のタスクよりも優先度の高いReady状態のタスクが一つも無くなるまでは、そのタスクを待たせる。
・タスクスケジューラは、優先度がより高い他のタスクがReady状態になると、即座にコンテキストスイッチ（すなわちタスクスイッチ）を行い、その優先度の高いタスクを先行して実行させる。
・現在実行中のタスクがシステムコール等でブロッキングされると、そのプロセス状態はWaitingに遷移する。その時、スケジューラは次に優先度の高いタスクを選択して、Ready状態に遷移させると共に、そのタスクを実行させる。
【００２２】
実行可能な状態（Ready）：
・そのタスクは実行可能状態にある。自分よりも優先度の高い全てのタスクの処理が終了するとすぐに実行される。
【００２３】
実行待ち状態（Waiting）：
・そのタスクは、ある特定のイベントが起こるのを待っているか、又は既にそのタスクは停止（stop）状態にあるかのどちらかとされる。
・Waiting状態にあるタスクは、この段階でCPUを必要としない。
・タスクをWaiting状態にするシステムコールは、ブロッキングシステムコールと呼ばれる。
・タスクは以下の理由でWaiting状態になり得る。
１）信号メッセージが到着するのを待っている。
２）所定の遅延（delay）時間が終了するのを待っている。
３）セマフォ待ち状態にある。
４）高速セマフォ待ち状態にある。
５）システムコールが完了するまで待っている。
６）システムコール(suspend等)で、明示的に停止（stop）とされた場合。
７）ブレイクポイント（breakpoint）に到達した場合。
【００２４】
又以下に、それぞれの場合においてタスク状態が遷移する例を挙げる。
●Runningを起点にした時の遷移：
Running⇒Ready(dispatchの矢印)：
・現在実行中の自タスクよりも高優先度のタスクが実行された場合に、その実行権をdispatchする。
【００２５】
Running⇒Waiting(receiveの矢印)：
・現在実行中のタスクが、信号メッセージの受信待ち、遅延（delay）時間の経過待ち、セマフォ待ちなどになった場合。
●Readyを起点にした時の遷移：
Ready⇒Running(preemptionの矢印)：
・現在実行中の自タスクよりも高優先度かつRunning/Ready状態のタスクが無くなった場合に、実行権をpreemptionする。
【００２６】
Ready⇒Waiting(stopの矢印)：
・Ready状態のタスクを、システムコールを用いて強制的にサスペンド（suspend）した場合にWaiting状態に遷移する。
(suspendしたタスクは、resumeする事で元の状態に戻る)
●Waitingを起点にした時の遷移：
Waiting⇒Running(send,startの矢印)：
・自タスクがメッセージ待ち状態で、現在実行中(Running状態)のプロセスより高優先度の場合に、他のタスクよりメッセージが送信（send）されてメッセージを受信するもしくは、タスク自体をクリエート&スタート（create&start）されるとRunning状態に遷移する。
【００２７】
Waiting⇒Ready(send,startの矢印)：
・自タスクがメッセージ待ち状態で、現在実行中(Running状態)のタスクより低優先度又は同一優先度の場合に、他のプロセスよりメッセージが送信（send）されて、メッセージを受信するか、もしくは、タスク自体をクリエート&スタート（create&start）されるとReady状態に遷移する。
【００２８】
上記機能ｉｖ）は、図４に示されるようなタスク間のメッセージ送受信において、メッセージの宛先などの情報 (メッセージキューなど)を取得する機能である。
【００２９】
ここで本実施例による障害タスク検出プログラムは、図２に示される以下の機能１（Ｆ１）、機能２（Ｆ２），機能３（Ｆ３），機能４（Ｆ４）をコンピュータに実行させるための命令を有する構成とされる。又図５はこれら各機能間の関係を示す。
機能１：ＣＰＵ負荷監視機能
機能２：タスクスイッチ履歴取得機能
機能３：異常被疑タスク抽出機能
機能４：異常被疑タスク監視機能
以下にこれら各機能につき詳述する。
【００３０】
機能１は、ＣＰＵの負荷が100％の状態が継続していないか監視し、ＣＰＵ負荷が100％の状態が一定時間以上継続したことを検出した場合に、機能３の処理を行う。
【００３１】
機能２は、タスクスイッチが発生した際に、その履歴情報として該当するタスクのID、そのときのシステム時間(粒度は１ミリ秒以下が理想)を取得する機能である。
【００３２】
機能３は、機能１により一定時間ＣＰＵ負荷が100％になったことが検出された場合に起動され、機能２で取得されたタスクスイッチ履歴情報を基に、ある一定の閾値以上のタスク、すなわち実行回数の多いタスク、実行時間が長いタスク等、の更に上位のものを異常発生の被疑タスクとして抽出する機能である。ここで上記ある一定の閾値以上のタスクがひとつも無い場合には、再び機能１へ戻る。
【００３３】
機能４は、機能３で抽出された被疑タスクの実行状態を定期的に一定期間監視し、無限ループ動作状態に陥っていないかチェックする機能である。
【００３４】
当該機能４で監視期間内に被疑タスクの実行状態が実行待ち状態に遷移しなかった場合には、被疑タスクが一度も実行権を離していないことを意味する。したがって当該タスクが無限ループ動作状態に陥ったと断定し、所定の障害対応処理、すなわち当該タスクの再起動、システムリスタート等、を実施する。
【００３５】
他方監視期間内に被疑タスクの状態が実行待ち状態に遷移したことが確認できた時点で、当該タスクは無限ループ動作状態には無いと断定し、監視対象から除外する。すなわち被疑タスクから除外される。
【００３６】
このようにして監視対象の被疑タスクが一つも無くなった場合には、機能４を終了する。また、機能４での被疑タスクの監視中に、機能１でＣＰＵ負荷の低下を検出した場合にも機能４を終了する。
【００３７】
又機能４において無限ループ動作状態に陥っているタスクが発見された際に、その旨を外部に通知する。すなわちコンソールへの出力等を実施する。
【００３８】
又機能４において無限ループ動作状態に陥っているタスクが発見された際に、当該タスクをリカバリーするための障害対応処理を選択できるようにする。
【００３９】
又更に、機能４において、被疑タスクとして抽出されたタスクの情報を履歴として保存しておき、所定のコマンド等による参照を可能にする機能５、すなわち被疑タスク履歴取得機能を設ける。
【００４０】
ここで機能４による監視動作中、抽出された全てのタスクが被疑タスクから除外され、且つ機能１によりＣＰＵ負荷が100％の状態が長時間継続していることが検出された場合には、特定のタスクが無限ループ動作状態に陥っているのではなく、ピンポン現象が生じている可能性が考えられる。そこで、機能４を実行するタスクに更に以下の機能６、すなわちピンポン現象監視機能（すなわち機能６）を持たせ、ピンポン現象の有無を判別するようにする。
【００４１】
図６はこれら機能５，６（Ｆ５，Ｆ６）を加えた各機能間の関係を示す図である。
【００４２】
又機能６において、機能５で取得された被疑タスクの履歴情報を参照し、同履歴中に常に出現しているタスクが２つ以上存在する場合は、それらの被疑タスクのメッセージ送受信状態(メッセージキュー情報などによる)を参照し、メッセージの宛先が当該被疑タスク同士となっていないかチェックする。その結果被疑タスクによるメッセージの送受信が当該被疑タスク同士間のメッセージの送受信であると判定された場合には、ピンポン現象によるプログラム異常が生じたものと判断し、所定の障害対応処理、すなわちシステムリスタート処理等を行う。
【００４３】
このような構成とすることにより本実施例による障害タスク検出プログラムは以下の作用効果を奏する。
【００４４】
すなわち従来はＣＰＵが高負荷になった場合に、正常な状態であっても異常状態と誤検出される場合があったが、本実施例によれば、当該ＣＰＵの高負荷状態の継続が、負荷の高い処理による一時的なものであるのか、或いは無限ループ動作等のプログラム異常による高負荷状態の継続であるのかを高精度で判別することができる。
【００４５】
又従来はピンポン現象の継続により高負荷状態の継続が生じていた場合にも、負荷の高い処理による一時的な高負荷状態、すなわち正常な状態と明確に区別することができなかったが、本実施例によればピンポン現象によるプログラム異常を正確に検出することができる。
【００４６】
以下にピンポン現象につき説明する。
【００４７】
これは例えば、図７に示す如く、タスクＡからタスクＢに対してメッセージＡが送信されるとそれを受信したタスクＢがタスクＡに対してメッセージＢを送信するように構成されていた場合、タスクＡが何らかの要因でメッセージＡをタスクＢに対して送信し続けるような動作が発生すると、タスクＡ、Ｂ間で永遠にメッセージのやり取りが行われる。このような現象をピンポン現象と称する。
【００４８】
以下に本実施例による障害タスク検出プログラムが提供する上記各機能につき、更に詳細に説明する。
【００４９】
上記機能１（Ｆ１）では、CPUの負荷が１００％の状態が継続しているかどうかが判定される。
【００５０】
この動作は図８に例示するように、最高優先度の監視用タスクA（ＴＡ：図２中、タスクＴ１に対応するタスク）及び、最低優先度の検出用タスクB（ＴＢ：図２中、タスクＴ２に対応するタスク）により実行される。
【００５１】
図８に示す如く、検出用タスクBは定期的に監視用タスクAに対し、所定のｋｅｅｐ  ａｌｉｖｅ通知を定期的に送信する。ｋｅｅｐ  ａｌｉｖｅ通知の送信周期は任意に設定可能であり、本実施例では１０秒に１度とされている。
【００５２】
図９はこのタスクAによる機能１に係る動作の流れを説明するためのフローチャートを示す。
【００５３】
同図中ステップＳ１にてタスクAの起動直後にタイマー(この例では５分タイマー；図８参照))が起動され（ステップＳ１）、タスクBからの上記ｋｅｅｐ  ａｌｉｖｅ通知を待つ状態とされる（ステップＳ２）。当該通知が受信されたら動作中のタイマーが即座にリセットされ（ステップＳ３）、所定の連続タイムアウトカウンタがクリア（ステップＳ４）された後、再度タイマーが起動され（ステップＳ１）タスクBからの応答を待つ状態とされる（ステップＳ２）。
【００５４】
他方タイマーがタイムアウトした場合（ステップＳ２のタイムアウト）は、連続タイムアウトカウンタがカウントアップされ（ステップＳ５）、機能３が実行される（ステップＳ６）。尚機能3はタスクAが実行する。
【００５５】
図８の例の場合、監視用タスクＡが検出用タスクＢからのｋｅｅｐ  ａｌｉｖｅ通知を時刻ｔ１，ｔ２，ｔ３，ｔ４に受信し、それぞれの場合、タイマーの設定時間の５分以内の受信なのでタイマーはリセットされる。その後、何らかの要因でタスクスイッチが滞り、もって最低優先度の検出用タスクＢの実行のタイミングが遅れたとする。その場合、監視用タスクＡはｔ５の時点でｋｅｅｐ  ａｌｉｖｅ通知を受信するが、すでに５分経過したためタイムアウトとなる（すなわち図９中、ステップＳ２のタイムアウト）。
【００５６】
次に、上記機能２（Ｆ２）では、タスクスイッチが発生した際の全ログが常時収集される。同機能はタスクスイッチが発生する度に実行され、図１２で示すフローチャートの動作がなされる。
【００５７】
すなわちタスクスイッチが発生したことを契機としてＯＳからシステム時刻(１ミリ秒の粒度のもの)及び、該当するタスクのタスクＩＤが取得され、図１１に示すフォーマットで順次記録される。図１１に示す当該記録のためのロギングエリアは最大２０００個(変更可能)まで取得可能な容量を有し、２０００番目まで記載した場合1番目のロギングポイントまで戻され、サイクリックに延々と記録し続けられる。
【００５８】
この機能２はＯＳが持つハンドラ機能、例えばＯＳＥ（Ｏｆｆｉｃｅ  Ｓｅｒｖｅｒ  Ｅｘｔｅｎｓｉｎ）の場合にはＳｗａｐＩｎハンドラ機能によって実行される。したがって同機能はタスクによって実行されるものではなく、プログラムの関数機能によりＯＳ自体によって起動され実行される。
【００５９】
次に、機能３（Ｆ３）では、CPUの負荷が１００％の状態の継続の原因として特定のタスクによる無限ループ動作状態を想定した場合の該当するタスクとして、被疑タスクが抽出される。
【００６０】
具体的には図１４のフローチャートの動作が実行される。すなわち機能３が実行される状態に遷移された（図９中、ステップＳ６の実行）直後に、機能２で取得されているタスクスイッチのログが参照され、上記延べ最大２０００個のタスクのそれぞれの動作時間が算出される。時間の算出は直前のログとの差分を算出することにより行われ、図１３（ａ）に示される如くその算出結果がリスト化される。
【００６１】
すなわち当該最大２０００個のログから、タスクＩＤ単位で、各タスクが合計何ミリ秒動作したかを示す合計動作時間が算出される（図１２中、ステップＳ３１）。そして算出されたタスク毎の合計動作時間が、動作時間の長い順に並び変えられる(ステップＳ３２)。図１３（ｂ）は、このようにして図１３（ａ）に示される差分時間のリストから合計動作時間が算出され並び替えられた結果の例を示す。
【００６２】
そして図１３（ｂ）に示される如く、このようにして得られたリストから上位６個(この個数は全体のタスク数などに応じて変更可能である)がリスト上位タスクとして選択される（ステップＳ３３）。更にその６個の中で、所定のCPU占有率閾値１５％(この値も変更可能である)以上のタスクＩＤが抽出される（ステップＳ３４）。ここで1つも該当するタスクIDが存在しない場合は異常状態の発生はなく、純粋に単なる過負荷状態が継続しているだけであると判断され、機能１が実行される状態に遷移される（ステップＳ３４のＮｏ）。
【００６３】
他方該当するタスクＩＤが存在する場合（ステップＳ３４のＹｅｓ），所定のメッセージが他のタスクに通知されることにより、当該他のタスク（図２中、タスクＴ３に対応するタスク）によって機能４が実行される。
【００６４】
機能４（Ｆ４）は無限ループ動作状態が生じているかどうか判断する機能である。機能４はアプリケーションタスク郡よりも高い優先度で実行され（図２参照）、図１５のフローチャートの動作が実行される。
【００６５】
機能４を実行するタスクは、機能１及び機能３を実行する最高優先度のタスクＡとは別のタスク（図２中、タスクＴ３に対応するタスク）とされ、上記タスクAから送信されたメッセージ通知を契機として図１５の動作を開始する。
【００６６】
機能４の実行開始直後、機能３にて抽出された被疑タスクリストの情報が機能５によりロギングされる（ステップＳ４１）。このロギング後、機能１で監視している負荷１００％の状態が引き続き継続しているかがチェックされ、継続していなければ無限ループ動作等の誤動作の発生はなく一時的な過負荷状態であると判断され、機能４の実行が終了される（ステップＳ４２のＮｏ）。他方ＣＰＵ負荷１００％状態が継続していると判断された場合はステップＳ４３に進む（ステップＳ４２のＹｅｓ→ステップＳ４３）。
【００６７】
ステップＳ４３では被疑タスクの状態がＯＳによって実行される関数機能により取得される。例えば上記ＯＳＥの場合、ｇｅｔ＿ｐｃｂという関数が使用される。タスクの状態は図３に示す上記実行可能な状態（Ｒｅａｄｙ）、（実行中の状態（Ｒｕｎｎｉｎｇ）及び実行待ち状態（Ｗａｉｔｉｎｇ）の3状態があり得るが、ここでは実行待ち状態の状態であるかどうかがチェックされる。
【００６８】
実行待ち状態の場合（ステップＳ４５のＹｅｓ）、対象のタスクがメッセージ待ちなどの状態であることを意味するため、無限ループ動作を生じていないと判断できる。そのため実行待ち状態のタスクは被疑タスクリストから削除され監視対象外とされる（ステップＳ４６）。
【００６９】
対象のタスクが実行待ち状態以外の状態であった場合は当該タスクが継続動作していることを意味するので、当該タスクは被疑タスクリストに残される（ステップＳ４５のＮｏ）。
【００７０】
機能４実行開始時の被疑タスクリストに含まれる全タスクに対して繰り返し同様のチェックが行われ（ステップＳ４４，Ｓ４５，Ｓ４６，Ｓ４７のループ）、これが完了するとステップＳ４８が実行される。
【００７１】
ステップＳ４８では被疑タスクリストに存在する全タスクにつき、チェック終了時点で、それぞれに設けられたチェックカウンタが１だけカウントアップされる。次にステップＳ４９にて各カウンタの計数値が、所定の閾値６００回(変更可能)に到達したかチェックされる。
【００７２】
チェックカウンタが6００回になった被疑タスクが存在した場合（ステップＳ４９のＹｅｓ）、該当するタスクが問題のタスクであると判断され、当該問題のタスクによる無限ループ動作が発生していると断定される。そして所定の障害対応処理がスタートされる（ステップＳ５０）。
【００７３】
他方各被疑タスクのチェックカウンタが６００回に満たない場合（ステップＳ４９のＮｏ）は、もうしばらく監視し続けることが必要であると判断され、所定のリトライ待ち時間の１００ミリ秒(変更可能)の経過の後（ステップＳ５１）、再度機能４の動作が最初から繰り返される（ステップＳ４２以降）。
【００７４】
尚上記１００ミリ秒周期で最大６００回チェックすることで合計1分間機能４によるチェックが継続される。
【００７５】
ここで、このように機能４の動作が繰り返し実行された結果、どの被疑タスクも問題なしと判断（すなわちステップＳ４５のＮｏ→Ｓ４６）され、被疑タスクリストに残る被疑タスクが無くなるような場合が想定される。このような場合には、無限ループ動作が無いと判断して機能４の動作を終了させるか、或いはピンポン現象が発生している可能性があるとして機能６を実行する状態に遷移させることが可能である。そのどちらの状態に遷移させるかは任意の設定による。
【００７６】
次に機能５（Ｆ５）は、上記機能４の実行開始直後に実行されるロギング機能（図１５中、ステップＳ４１）であり、図１７のフローチャートの動作が実行される。
【００７７】
このロギング機能では図１６に示す如くのロギング情報が記録される。図１６のロギング情報の先頭には、何回機能５が実行されたかを示すロギングカウンタ（Ｌｏｇｇｉｎｇ  ｃｏｕｎｔｅｒ）が設けられ、機能５の実行の度毎に1ずつカウントアップされる（図１７中、ステップＳ６１）。
【００７８】
ここでは1回のロギングで、カウンタ(Ｃｏｕｎｔｅｒ)の更新（ステップＳ６１）、装置内時刻(Ｔｉｍｅ)の記録（ステップＳ６２）、装置内システム時刻(ＳｙｓｔｅｍＴｉｍｅｒ)の記録（ステップＳ６７）、その時点の被疑タスクのリスト(ＴａｓｋＬｉｓｔ)の記録（ステップＳ６８）が一度に実行される。
【００７９】
次に機能６（Ｆ６）は、機能４により無限ループ動作が生じていないと判断された場合にピンポン現象が発生していないかチェックするための機能である。同機能では図１８のフローチャートの動作が実行される。
【００８０】
図１８中、最初に、機能１により図９中ステップＳ５でカウントアップされる連続タイムアウトカウンタの計数値が参照され（ステップＳ７１）、同計数値が所定の高負荷継続時間として設定された２５分に到達する連続5回以上になっているかがチェックされる（ステップＳ７２）。5回に満たない場合（Ｎｏ）は継続時間が短いと判断され機能６の実行が終了される。すなわちピンポン現象の発生はないとの判定がなされる。他方５回以上の場合（Ｙｅｓ），ステップＳ７３が実行される。
【００８１】
ステップＳ７３では、機能５の実行により記録されているロギング情報の内、最後の5回分のログが参照され、毎回同じタスクIDが存在しているかがチェックされる。
【００８２】
図１６の例ではＣｏｕｎｔ  ３以降、0x000Bと0x000Cの２つのタスクが毎回出現しているので、ステップＳ７３の条件が満たされる（Ｙｅｓ）。
【００８３】
ステップＳ７３にて条件を満たす２つ以上のタスクが見つからなかった場合（Ｎｏ）、ピンポン現象が生じていないと判定され、機能６の実行が終了される。他方条件を満たす２つ以上のタスクが見つかった場合ステップＳ７４が実行される。
【００８４】
ステップＳ７４では、ステップＳ７３にて見いだされたタスクが被疑タスクとされる。すなわち上記例の場合、タスク0x000Bと0x000Cが被疑タスクとされる。その後当該被疑タスクの状態が解析される。
【００８５】
すなわちこの例の場合、タスク0x000Bと0x000Cのタスク状態が取得される。その際、例えば上記ｇｅｔ＿ｐｃｂ関数が使用され、該当するシグナルのキュー情報が参照される。同キュー内には該当するタスクに送信されたメッセージが格納されており、このメッセージ内部の送信元タスク情報が参照される。その結果メッセージの送信元タスクが各々当該被疑タスク(上記例の場合、タスク0x000Bまたは0x000C)であれば（ステップＳ７５のＹｅｓ）、被疑タスク間でメッセージをやり取りしていることになる。したがってこの場合ピンポン現象が生じていると判定する。このようにしてピンポン現象の発生の判定がなされた場合は、設定済みの所定の障害対応処理がスタートされる（ステップＳ７６）。
【００８６】
この障害対応処理では、図１９のフローチャートの動作が実行される。
【００８７】
ここでは最初に障害内容の通知の要否についての設定が参照され（ステップＳ８１）、通知要の場合（Ｙｅｓ）は前もってコマンドで設定済みの通知処理が実行される（ステップＳ８２）。その後、指定された所定の障害オペレーションの内容が実行される（ステップＳ８３）。
【００８８】
以下に上記各機能の実行において設定される各パラメータの一覧を示すとともに、併せて本実施例での設定値を括弧内に示す。
●機能１：
連続タイムアウトカウンタ（０から開始）
keep alive通知周期（１０秒）
タイマー時間（５分）
●機能２：
最大ロギング数（２０００個）
●機能３；
リスト上位タスク数（６個）
CPU占有率の閾値（１５％）
●機能４；
チェックカウンタ（６００回）
リトライ待ち時間（１００ミリ秒）
●機能５；
なし
●機能６：
機能有効設定（有効）
高負荷継続時間（２５分＝5履歴）
●障害対応処理：
通知要否設定（要）
通知方法（以下の２）を選択）
１）別タスクへ通知する。
２）コンソールから出力する。
３）トラップ（TRAP）通知を行う。
４）アラーム（ALM）を発生させる。
【００８９】
障害オペレーション（以下の５）を選択）
１）問題のタスクを削除する。
２）問題のタスクを削除するとともに再生成する。
３）題のタスクを一定時間停止させて再度動作開始する。
４）システムを停止する。
５）システムを再起動する。
６）特に対応を行わない。
【００９０】
図２０は上記本発明の実施例を適用可能な情報処理装置のハードウェア構成例を示す。
【００９１】
図示の如く、同情報処理装置はコンピュータ１００よりなり、ＯＳ及び各アプリケーションプログラムを実行することにより対応する動作を行うＣＰＵ１１１，キーボード６０との通信用のＬＡＮインタフェース１１５、ＣＲＴ，液晶表示装置等のディスプレイ５０との通信用のシリアルインタフェース１１６、プログラム、データ等の読み書きを行うＳＤＲＡＭ１２，ＯＳ、各種アプリケーションプログラム等を格納するフラッシュメモリ等の不揮発メモリ１１３，ネットワーク等を介し外部との情報のやりとりを行うＨＤＬＣ，ＬＡＮ等の通信デバイス１１４及びそれらを接続するバス１１７が設けられたＣＰＵカード１１０と、上記通信デバイス１１４に接続された各種インタフェースカード１２０とを備える。
【００９２】
同コンピュータ１００のＯＳはマルチタスクＯＳであり、上記４つの機能ｉ），ｉｉ）、ｉｉｉ）、ｉｖ）を有する
又前述の本実施例による障害タスク検出プログラムがフラッシュメモリ等の不揮発メモリ１１３に格納され、或いはインタフェースカード１２０及び通信デバイス１１４を介しネットワーク経由でダウンロードされた後にＳＤＲＡＭ１１２に格納される。
【００９３】
その後ＣＰＵ１１１によって同障害タスク検出プログラムが実行されることにより、図２〜図１９とともに上述の機能１〜６が実行される。
【００９４】
本発明は以下の付記の各々に記載の構成をとり得る。
（付記１）
マルチタスクオペレーティングシステムを有する情報処理装置であって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出手段と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存手段と、
前記高負荷継続検出手段によってＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存手段によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出手段とよりなる情報処理装置。
（付記２）
更に前記異常タスク候補抽出手段によって抽出された異常タスクの候補としてのタスクの動作を監視することによって前記異常タスクを検出する異常タスク検出手段よりなる付記１に記載の情報処理装置。
（付記３）
前記高負荷継続検出手段は、ＣＰＵの負荷が１００％の状態の継続時間によって高負荷状態の継続を検出する構成とされてなる付記１に記載の情報処理装置。
（付記４）
前記タスク間切替履歴保存手段が保存する履歴は、該当するタスクの識別情報及びタスク間切替動作発生時刻を含む構成とされてなる付記１に記載の情報処理装置。
（付記５）
前記異常タスク候補抽出手段は、タスクの累計実行時間を指標として異常タスクの候補を抽出する構成とされてなる付記１に記載の情報処理装置。
（付記６）
前記異常タスク検出手段は前記異常タスク候補抽出手段によって抽出された異常タスクの候補としてのタスクの状態を定期的に監視し、同タスクが無限ループ動作状態に陥っているか否かを検出する構成とされてなる付記２に記載の情報処理装置。
（付記７）
前記異常タスク検出手段は、監視中にＣＰＵの負荷が低下した場合には現在監視中の異常タスクの候補としてのタスクの全てを同候補から除外する構成とされてなる付記２に記載の情報処理装置。
（付記８）
前記異常タスク検出手段は、監視中に待ち状態となった異常タスクの候補としてのタスクを同候補から除外する構成とされてなる付記２に記載の情報処理装置。
（付記９）
更に前記異常タスク候補抽出手段によって抽出された異常タスクの候補としてのタスクのうちの特定の複数のタスク間でのメッセージのやりとりの継続を検出することによってピンポン現象の発生を検出するピンポン現象検出手段を含む付記１に記載の情報処理装置。
（付記１０）
マルチタスクオペレーティングシステムを有する情報処理装置の制御方法であって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出段階と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存段階と、
前記高負荷継続検出段階においてＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存段階によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出段階とよりなる制御方法。
（付記１１）
更に前記異常タスク候補抽出段階において抽出された異常タスクの候補としてのタスクの動作を監視することによって前記異常タスクを検出する異常タスク検出段階よりなる付記１０に記載の制御方法。
（付記１２）
前記高負荷継続検出段階では、ＣＰＵの負荷が１００％の状態の継続時間によって高負荷状態の継続を検出する構成とされてなる付記１０に記載の制御方法。
（付記１３）
前記タスク間切替履歴保存段階で保存する履歴は、該当するタスクの識別情報及びタスク間切替動作発生時刻を含む構成とされてなる付記１０に記載の制御方法。
（付記１４）
前記異常タスク候補抽出段階では、タスクの累計実行時間を指標として異常タスクの候補を抽出する構成とされてなる付記１０に記載の制御方法。
（付記１５）
前記異常タスク検出段階では前記異常タスク候補抽出段階において抽出された異常タスクの候補としてのタスクの状態を定期的に監視し、同タスクが無限ループ動作状態に陥っているか否かを検出する構成とされてなる付記１１に記載の制御方法。
（付記１６）
前記異常タスク検出段階では、監視中にＣＰＵの負荷が低下した場合には現在監視中の異常タスクの候補としてのタスクの全てを同候補から除外する構成とされてなる付記１１に記載の制御方法。
（付記１７）
前記異常タスク検出段階では、監視中に待ち状態となった異常タスクの候補としてのタスクを同候補から除外する構成とされてなる付記１１に記載の制御方法。
（付記１８）
更に前記異常タスク候補抽出段階において抽出された異常タスクの候補としてのタスクのうちの特定の複数のタスク間でのメッセージのやりとりの継続を検出することによってピンポン現象の発生を検出するピンポン現象検出段階を含む付記１０に記載の制御方法。
（付記１９）
マルチタスクオペレーティングシステムを有する情報処理装置の制御をコンピュータに実行させるためのプログラムであって、
ＣＰＵの高負荷状態の継続を検出する高負荷継続検出段階と、
タスク間切替動作の履歴を保存するタスク間切替履歴保存段階と、
前記高負荷継続検出段階においてＣＰＵの高負荷状態の継続が検出された場合、タスク間切替履歴保存段階によって保存されているタスク間切替動作の履歴を参照することにより前記ＣＰＵの高負荷状態の継続の原因たる異常タスクの候補を抽出する異常タスク候補抽出段階とをコンピュータに実行させるための命令よりなるプログラム。
（付記２０）
更に前記異常タスク候補抽出段階において抽出された異常タスクの候補としてのタスクの動作を監視することによって前記異常タスクを検出する異常タスク検出段階をコンピュータに実行させる命令よりなる付記１９に記載のプログラム。
【産業上の利用可能性】
【００９５】
本発明はスタンドアロンのコンピュータに限られず、自動車の制御用コンピュータ等を制御する各種組み込みＯＳについても適用可能である。
【図面の簡単な説明】
【００９６】
【図１】マルチタスクオペレーティングシステムによるタスク制御を説明するための図である。
【図２】図１の構成について本発明の一実施例の適用について説明するための図である。
【図３】タスクの実行状態を表す遷移図である。
【図４】メッセージキューとタスク間のメッセージ送受信状態を説明するための図である。
【図５】本発明の実施例における各機能及びその相関関係を説明するための図（その１）である。
【図６】本発明の実施例における各機能及びその相関関係を説明するための図（その２）である。
【図７】いわゆるピンポン現象におけるタスク間のメッセージ送受信状態を説明するための図である。
【図８】本発明の実施例における機能１について説明するための図である。
【図９】本発明の実施例における機能１を果たす監視用タスクの動作について説明するための動作フローチャートである。
【図１０】本発明の実施例における機能１を果たす検出用タスクの動作について説明するための動作フローチャートである。
【図１１】本発明の実施例における機能２によって取得される履歴情報について説明するための図である。
【図１２】本発明の実施例における機能２の動作について説明するための動作フローチャートである。
【図１３】本発明の実施例における機能３で被疑タスクを抽出する際の履歴情報解析処理について説明するための図である。
【図１４】本発明の実施例における機能３の動作について説明するための動作フローチャートである。
【図１５】本発明の実施例における機能４の動作について説明するための動作フローチャートである。
【図１６】本発明の実施例における機能５によって取得される履歴情報について説明するための図である。
【図１７】本発明の実施例における機能５の動作について説明するための動作フローチャートである。
【図１８】本発明の実施例における機能６の動作について説明するための動作フローチャートである。
【図１９】本発明の実施例における障害対応処理の動作について説明するための動作フローチャートである。
【図２０】本発明の実施例における情報処理装置のハードウェア構成の一例を示すブロック図である。
【符号の説明】
【００９７】
１００  コンピュータ本体
１１０  ＣＰＵカード
１１１  ＣＰＵ
【図１】
2008102778.tif 000003
【図２】
2008102778.tif 000004
【図３】
2008102778.tif 000005
【図４】
2008102778.tif 000006
【図５】
2008102778.tif 000007
【図６】
2008102778.tif 000008
【図７】
2008102778.tif 000009
【図８】
2008102778.tif 000010
【図９】
2008102778.tif 000011
【図１０】
2008102778.tif 000012
【図１１】
2008102778.tif 000013
【図１２】
2008102778.tif 000014
【図１３】
2008102778.tif 000015
【図１４】
2008102778.tif 000016
【図１５】
2008102778.tif 000017
【図１６】
2008102778.tif 000018
【図１７】
2008102778.tif 000019
【図１８】
2008102778.tif 000020
【図１９】
2008102778.tif 000021
【図２０】
2008102778.tif 000022