(57)【特許請求の範囲】
【請求項１】
プロセスがＣＰＵを使用して処理を実行する計算システムのプロセス障害対応装置において、
前記プロセスによるＣＰＵの使用率を算出するＣＰＵ使用率算出手段と、
算出されたＣＰＵ使用率が上限閾値を上回っているか否かを判定する上限判定手段と、
ＣＰＵ使用率が上限閾値を上回っていると判定された場合に、プロセスの優先度を低下させる優先度低下制御手段と、
第１の時間において前記優先度低下制御手段によるプロセスの優先度の低下制御にかかわらず前記上限判定手段によりＣＰＵ使用率が上限閾値を上回っていると判定された場合に、ループ状態を検出するループ検出手段と、
算出されたＣＰＵ使用率が下限閾値を下回っているか否かを判定する下限判定手段と、
ＣＰＵ使用率が下限閾値を下回っていると判定された場合に、プロセスの優先度を上昇させる優先度上昇制御手段と、
第２の時間において前記優先度上昇制御手段によるプロセスの優先度の上昇制御にかかわらず前記下限判定手段によりＣＰＵ使用率が下限閾値を下回っていると判定された場合に、ロック状態を検出するロック検出手段と
を具備することを特徴とするプロセス障害対応装置。
【請求項２】
ループ検出手段によりループ状態が検出された場合またはロック検出手段によりロック状態が検出された場合には、プロセスを強制終了させる指示手段が備えられていることを特徴とする請求項１に記載のプロセス障害対応装置。
【請求項３】
ループ検出手段によりループ状態が検出されたプロセスまたはロック検出手段によりロック状態が検出されたプロセスに関し、実行時の情報をモニタし、このモニタに係る出力部が備えられていることを特徴とする請求項１に記載のプロセス障害対応装置。
【請求項４】
プロセスの入力／出力情報をモニタし収集して、格納部へ格納する手段を備え、
ループ検出手段によりループ状態が検出された場合またはロック検出手段によりロック状態が検出された場合に、出力部は前記格納部へ格納された情報についても出力することを特徴とする請求項３に記載のプロセス障害対応装置。
【請求項５】
プロセスがＣＰＵを使用して処理を実行する計算システムのプロセス障害対応装置において用いられるプロセス障害検出方法であって、
前記プロセスによるＣＰＵの使用率を算出するＣＰＵ使用率算出ステップと、
算出されたＣＰＵ使用率が上限閾値を上回っているか否かを判定する上限判定ステップと、
ＣＰＵ使用率が上限閾値を上回っていると判定された場合に、プロセスの優先度を低下させる優先度低下制御ステップと、
第１の時間において前記優先度低下制御ステップによるプロセスの優先度の低下制御にかかわらず前記上限判定ステップによりＣＰＵ使用率が上限閾値を上回っていると判定された場合に、ループ状態を検出するループ検出ステップと、
算出されたＣＰＵ使用率が下限閾値を下回っているか否かを判定する下限判定ステップと、
ＣＰＵ使用率が下限閾値を下回っていると判定された場合に、プロセスの優先度を上昇させる優先度上昇制御ステップと、
第２の時間において前記優先度上昇制御ステップによるプロセスの優先度の上昇制御にかかわらず前記下限判定ステップによりＣＰＵ使用率が下限閾値を下回っていると判定された場合に、ロック状態を検出するロック検出ステップと
を具備することを特徴とするプロセス障害検出方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明は、プロセスの障害に対応するプロセス障害対応装置及びこの装置により採用されるプロセス障害検出方法に関する。
【０００２】
【従来の技術】
計算機システムにあっては、オペレーティングシステムの基において処理を実行する１または複数のプロセスが動作している。係る計算機システムにおいて、プロセスの処理にループ状態が生じたり、プロセスのロック状態（デッドロック状態）が発生することがある。
【０００３】
上記ループ状態のときには、計算機は負荷が大きいことを検出可能であるが、オペレータ等にとっては処理が極端に遅くなると気付く程度である。また、ロック状態のときには、計算機は処理すべき対象がないことを検出可能であるが、オペレータ等にとっては処理が進まないと気付く程度である。
【０００４】
【発明が解決しようとする課題】
いずれのときにも、オペレータ等がプロセスの終了を行うことになる。しかしながら、場合によっては外部割込みではプロセスを終了することができず、計算機をイニシャライズする必要が生じることもあった。更に、計算機システムでは、プロセスの異常を検出することができず、複数のプロセスを適切に切り換えて処理を進めることができなくなることがある。
【０００５】
また、プロセスの異常に関してプロセス自身がアボードしないため、アボードダンプリストの採取が困難であり、原因追究を行い難くしている面があった。
【０００６】
本発明は上記のような従来の計算機システムにおけるプロセス障害に対する対応の現状に鑑みなされたもので、その目的は、プロセス障害に適切に対応して運用を図ることが可能なプロセス障害対応装置を提供することである。また、他の目的は、プロセスの障害発生の原因追究を可能とする情報の収集を行うプロセス障害対応装置及びこの装置により採用されるプロセス障害検出方法を提供することである。
【０００７】
【課題を解決するための手段】
本発明に係るプロセス障害対応装置は、プロセスがＣＰＵを使用して処理を実行する計算システムのプロセス障害対応装置において、前記プロセスによるＣＰＵの使用率を算出するＣＰＵ使用率算出手段と、算出されたＣＰＵ使用率が上限閾値を上回っているか否かを判定する上限判定手段と、ＣＰＵ使用率が上限閾値を上回っていると判定された場合に、プロセスの優先度を低下させる優先度低下制御手段と、第１の時間において前記優先度低下制御手段によるプロセスの優先度の低下制御にかかわらず前記上限判定手段によりＣＰＵ使用率が上限閾値を上回っていると判定された場合に、ループ状態を検出するループ検出手段と、算出されたＣＰＵ使用率が下限閾値を下回っているか否かを判定する下限判定手段と、ＣＰＵ使用率が下限閾値を下回っていると判定された場合に、プロセスの優先度を上昇させる優先度上昇制御手段と、第２の時間において前記優先度上昇制御手段によるプロセスの優先度の上昇制御にかかわらず前記下限判定手段によりＣＰＵ使用率が下限閾値を下回っていると判定された場合に、ロック状態を検出するロック検出手段とを具備することを特徴とする。
【０００８】
本発明に係るプロセス障害対応装置では、プロセスを強制終了する指示手段が備えられている。これによって、設定変更に拘らず異常状態が検出されると、プロセスが強制終了される。また、本発明に係るプロセス障害対応装置では、ループ検出手段によりループ状態が検出されたプロセスまたはロック検出手段によりロック状態が検出されたプロセスに関し、実行時の情報をモニタし、このモニタに係る出力部が備えられていることを特徴とする。また、本発明に係るプロセス障害対応装置では、プロセスの入力／出力情報をモニタし収集して、格納部へ格納する手段を備え、ループ検出手段によりループ状態が検出された場合またはロック検出手段によりロック状態が検出された場合に、出力部は前記格納部へ格納された情報についても出力することを特徴とする。
【０００９】
本発明に係るプロセス障害検出方法は、プロセスがＣＰＵを使用して処理を実行する計算システムのプロセス障害対応装置において用いられるプロセス障害検出方法であって、前記プロセスによるＣＰＵの使用率を算出するＣＰＵ使用率算出ステップと、算出されたＣＰＵ使用率が上限閾値を上回っているか否かを判定する上限判定ステップと、ＣＰＵ使用率が上限閾値を上回っていると判定された場合に、プロセスの優先度を低下させる優先度低下制御ステップと、第１の時間において前記優先度低下制御ステップによるプロセスの優先度の低下制御にかかわらず前記上限判定ステップによりＣＰＵ使用率が上限閾値を上回っていると判定された場合に、ループ状態を検出するループ検出ステップと、算出されたＣＰＵ使用率が下限閾値を下回っているか否かを判定する下限判定ステップと、ＣＰＵ使用率が下限閾値を下回っていると判定された場合に、プロセスの優先度を上昇させる優先度上昇制御ステップと、第２の時間において前記優先度上昇制御ステップによるプロセスの優先度の上昇制御にかかわらず前記下限判定ステップによりＣＰＵ使用率が下限閾値を下回っていると判定された場合に、ロック状態を検出するロック検出ステップとを具備することを特徴とする。
【００１０】
【発明の実施の形態】
以下、添付図面を参照して本発明の実施の形態に係るプロセス障害対応装置を説明する。プロセス障害対応装置は、計算機システムにおいて実現され、図１に示されるように構成される。プロセス１１がＯＳ１２の基において処理を実行する。このプロセス１１は、１または複数である。
【００１１】
計算機システムには、ＯＳ１２の基で動作するプログラムにより、監視部１３、設定変更部１４、指示部１５、出力部１６が備えられる。監視部１３は、プロセス１１の異常状態を監視するものであり、特にループ状態とロック状態を監視すると共に、ＯＳ１２を介してプロセス１１の入力／出力情報をモニタし収集してモニタ情報エリア１７へ格納する。モニタ情報エリア１７は、例えば、主記憶装置に設けられる。また、監視部１３は、ループ状態とロック状態を検出した場合には、設定変更部１４へ該当プロセス１１に関する設定を変更するように指示を与える。
【００１２】
上記監視部１３からの指示に基づき設定変更部１４は、ＯＳ１２へ該当プロセス１１の優先順位を変更する依頼を送出する。監視部１３は、上記設定変更後に更に監視を継続し、改善が見られない場合には設定変更部１４を介して指示部１５へ該当プロセス１１の異常終了を指示する。これに応じて指示部１５は、ＯＳ１２へ該当プロセス１１の異常終了を指示する。
【００１３】
また、監視部１３は、上記設定変更後に更に監視を継続しても改善が見られない場合には設定変更部１４と指示部１５を介して出力部１６へＯＳ１２から該当プロセス１１の情報の受け取りを行うように指示する。これに応えて出力部１６は、ＯＳ１２から該当プロセスに関する各種ステータスやレジスタの情報を受け取り、モニタ情報エリア１７に格納されている該当プロセス１１の入力／出力情報を取り込み、これらを外部記憶媒体１８へ格納する。
【００１４】
上記各部は、図２に示されるフローチャートに対応するプログラムにより実現される。以下に説明を行う。この図２の処理はプロセス１１の起動時、プロセスの入力／出力要求時に実行される。プロセス１１が起動されたスタート時には、Ｔｌ（ループ時間）カウンタ、Ｔｒ（ロック時間）カウンタをクリアし（Ｓ２１）、適当な所定監視時間を区切るために設けられたＴｍタイマを起動させて当該Ｔｍタイマがタイムアップとなったか検出する（Ｓ２２）ことにより、実質的な障害監視に入るか否かを決定する。Ｔｌカウンタ、Ｔｒカウンタ、Ｔｍタイマは、各プロセスに対応して設けられる。
【００１５】
上記において、Ｔｍタイマがタイムアップしていない場合には、このＴｍタイマ対応のプロセスがモニタ対象のプロセスとされているのかを検出する（Ｓ４１）。モニタ対象のプロセスとして設定されている場合には、入力／出力情報をモニタ情報エリア１７に出力し（Ｓ４２）、ステップＳ２２へ戻る。この結果、モニタ対象のプロセスに対応して入力／出力情報がモニタ情報エリア１７に格納されてゆく。一方、モニタ対象のプロセスでない場合は終了する。
【００１６】
上記のように処理を続けると、Ｔｍタイマがタイムアップとなり、ステップＳ２２からステップＳ２３へ進むことになる。つまり、Ｔｍタイマがタイムアップであることを検出した場合には、当該プロセス１１のＣＰＵ使用率がＣｍａｘ
（上限ＣＰＵ負荷）より大きいか否かを検出する（Ｓ２３）。各プロセスのＣＰＵ使用率は、ＯＳ１２が計算している。ここで、当該プロセス１１のＣＰＵ使用率がＣｍａｘより大きい場合には、当該プロセス１１の優先度（ＣＰＵ等のリソースをプロセスに割り当てる順位）がＵｍｉｎ（下限優先度）より小さいかを検出する（Ｓ２４）。つまり、当該プロセス１１の優先度を低下させ得るかを検出するのである。
【００１７】
上記において、当該プロセス１１の優先度が下限優先度Ｕｍｉｎより大きい場合には、その優先度を１ランク下げる（Ｓ２６）。この処理の後、或いは当該プロセス１１の優先度が下限優先度Ｕｍｉｎより小さい場合（優先度が十分低下させられている場合）に、ループ時間計測用のＴｌカウンタの値がＴｌｍａｘ（限界ループ時間）より大きいかチェックする（Ｓ２５）。当初はＴｌカウンタの値は「０」であり、ＮＯへ分岐する。
【００１８】
ＴｌカウンタがＴｌｍａｘより小さい場合には、さらにＴｍ時間を継続して測定が必要であるため、Ｔｌカウンタの値ＴｌをＴｌ＝Ｔｌ＋Ｔｍとし、次のＴｍ時間における測定に入る（Ｓ２９）。このように、ステップＳ２２、Ｓ２３、Ｓ２４、Ｓ２５、Ｓ２６、Ｓ２９の処理を繰り返すうちに、ステップＳ２５においてＴｌカウンタの値がＴｌｍａｘより大きくなると、当該プロセス１１が障害（ループ状態）と判断して、当該プロセス１１の状態（レジストリの内容等からなるプロセスの制御情報）をＯＳ１２から採取し、モニタ対象のプロセスであることを設定する（Ｓ２７）。この結果、これ以降において当該プロセスが起動されると、ステップＳ４１、Ｓ４２において入力／出力情報が得られモニタ情報エリア１７に出力される。上記ステップＳ２７の処理に続いて、ＯＳ１２に対し当該プロセスのアボート処理を依頼する（Ｓ２８）。
【００１９】
一方、ステップＳ２３において、当該プロセス１１のＣＰＵ使用率が上限ＣＰＵ負荷Ｃｍａｘより小さい場合はループ状態は発生してないと判断し、Ｔｌカウンタをクリアする（Ｓ３０）。次に、当該ＣＰＵ使用率がＣｍｉｎ（下限ＣＰＵ負荷）より小さいか否かを検出する（Ｓ３１）。ここで、当該プロセス１１のＣＰＵ使用率がＣｍｉｎより小さい場合には、当該プロセス１１の優先度がＵｍａｘ（上限優先度）より大きいか否かを検出し、優先度を上昇させ得るか求める（Ｓ３２）。
【００２０】
ここで、当該プロセス１１の優先度がＵｍａｘより小さい場合には、当該プロセス１１の優先度を１ランク上げる（Ｓ３３）。このステップＳ３３の処理の後に、或いは上記ステップＳ２において当該プロセスの優先度が上限優先度Ｕｍａｘより大きいことが検出された場合には、ロック時間測定用のＴｒカウンタがＴｒｍａｘ（限界ロック時間）より大きいか否かを検出する（Ｓ３４）。当初はＴｒカウンタの値は「０」であり、ＮＯへ分岐する。
【００２１】
ＴｒカウンタがＴｒｍａｘより小さい場合には、さらにＴｍ時間を継続して測定が必要であるため、Ｔｒカウンタの値ＴｒをＴｒ＝Ｔｒ＋Ｔｍとし、次のＴｍ時間における測定に入る（Ｓ３５）。このように、ステップＳ２２、Ｓ２３、Ｓ３０、Ｓ３１、Ｓ３２、Ｓ３３、Ｓ３４の処理を繰り返すうちに、ステップＳ３４においてＴｒカウンタの値がＴｒｍａｘより大きくなると、プロセスの異常（ロック状態）と判断してプロセスの状態（レジストリの内容等からなるプロセスの制御情報）をＯＳ１２から採取し、次回よりモニタ対象のプロセスとする（Ｓ２７）。この結果、これ以降において当該プロセスが起動されると、ステップＳ４１、Ｓ４２において入力／出力情報が得られモニタ情報エリア１７に出力される。上記ステップＳ２７の処理に続いて、ＯＳ１２に対しプロセスのアボート処理を依頼する（Ｓ２８）。
【００２２】
ステップＳ３１において、当該プロセス１１のＣＰＵ使用率がＣｍｉｎより大きい場合は、ロック状態は発生してないと判断し（この場合は、ステップＳ２３においてＮＯへ分岐したことにより、ループ状態が発生していないことは検出済み）、Ｔｒカウンタをクリアする（Ｓ３６）。そして、次のＴｍ時間における測定へ移行する（Ｓ３７）。
【００２３】
斯して、プロセスのＣＰＵ使用率が所定より大きい場合に優先度を低く変更して、プロセスに割り当てられた優先度が低いにも拘らずＣＰＵ使用率が大きくなるループ状態を検出でき、また、プロセスのＣＰＵ使用率が所定より小さい場合に優先度を高く変更して、プロセスに割り当てられた優先度が高いにも拘らずＣＰＵ使用率が大きくならないロック状態を検出できる。
【００２４】
しかも、入力／出力情報とレジストリの情報等を収集して記憶するので、障害解析の場合に使用することができ、好適である。尚、図１の説明では、入力／出力情報を常にモニタ情報エリア１７に格納し、図２の説明では、プロセスがモニタ対象のプロセスに設定された場合に入力／出力情報をモニタ情報エリア１７に格納すると説明したが、いずれの手法を採用しても良い。
【００２５】
【発明の効果】
以上説明したように本発明に係るプロセス障害対応装置によれば、プロセスの異常状態を監視し異常状態を検出した場合には、当該プロセスを実行する条件の設定が変更され、幾つかの条件において異常状態となるかを検出可能である。
【００２６】
また、本発明に係るプロセス障害対応装置によれば、設定変更部による設定変更に拘らず異常状態が検出されると、プロセスを強制終了するので、外部からの割込み等がなくても適切に強制終了をさせることができる。
【００２７】
更に、本発明に係るプロセス障害対応装置によれば、設定変更部による設定変更に拘らず異常状態が検出されたプロセスに関する実行時の情報をモニタし、このモニタに係る情報を出力するので、プロセス障害の原因解析などに有効な情報を適切に収集することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るプロセス障害対応装置の構成例を示す図。
【図２】本発明の実施の形態に係るプロセス障害対応装置の動作を説明するためのフローチャート。
【符号の説明】
１１  プロセス
１２  ＯＳ
１３  監視部
１４  設定変更部
１５  指示部
１６  出力部
１７  モニタ情報エリア
１８  外部記憶媒体
【図１】
0003759852.tif 000002
【図２】
0003759852.tif 000003