JP2009238011A - 実行環境の制御方法およびプログラム - Google Patents

Abstract

【課題】自立型の障害検出により、システムの複雑性およびその制御の複雑性を排除した実行環境の制御方法およびプログラムを提供すること。
【解決手段】タイマスレッドがＪａｖａヒープ情報を取得して、取得した情報の履歴と、プロパティ情報を比較するステップと、ガベージコレクションの発生間隔とメモリ使用量に関する相関図に照らして、自ら停止する必要があると判断した場合は、ＷｅｂＯＴＸ基盤が、自身を閉塞した後、要求を受け付けたプロセスの停止を行うステップと、ＴＰモニタがプロセスの停止を確認後、プロセスの再起動を行うステップとを有する。
【選択図】図４

Description

本発明は、不正動作の影響を極力Ｊａｖａ（登録商標）プロセス内に隠蔽する技術に関する。

関連技術として、Ｊａｖａのメモリ量を調べるＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を使ってＪａｖａ仮想マシンが管理しているメモリ（ヒープ）サイズの定期調査を行い、メモリ不足を検出する技術がある。この技術では、メモリの空きがしきい値より不足した場合に、ガベージコレクションを強制実行することにより、メモリの空きの回復を促している。

上述の関連技術では、処理が自動的に行われているが、トラブルを予測するアルゴリズムに問題があった。Ｊａｖａ仮想マシンのメモリ（ヒープ）不足はトラブルの主要因ではあるが、空き容量としきい値を比較してヒープ不足を検出するだけでは必ずしも正しい判断ができているとはいえない。

ヒープが不足した場合には、Ｊａｖａ仮想マシンは自動的にガベージコレクションを実行してメモリの回復を図るが、上述の関連技術では、それより前に強制的なガベージコレクションでメモリの回復を図っている。この技術は、メモリの使用量がしきい値を超えた後に徐々にメモリ使用量が増え、自動的なガベージコレクションが起きるまでに比較的長い時間がかかる場合には、有効かもしれない。

しかし、すべてがこのような状況であるとは限らない。例えば、メモリの絶対量が不足していてガベージコレクションの頻度が高い場合には、強制的にガベージコレクションを起こしてもすぐに次のガベージコレクションが起きてしまい、負荷の高いガベージコレクション処理を何度も行ってしまうことになる。

そこで、ガベージコレクション以外のイベント発生時（例えば、メモリの割り当てのイベント発生時など）にはメモリ使用量などの測定を行わず、主にガベージコレクションのイベント発生時の測定と、必要に応じて比較的長い周期での定期的な測定によって、メモリ使用量などの測定を行い、アプリケーションの運用に負荷をかけずにデータの測定を行う技術が提案されている（例えば、特許文献１参照）。
ＷＯ２００４／０９９９８５号公報

Ｊａｖａあるいはミドルウェア、業務アプリケーション（ＡＰ）には必ずといってよいほどバグが存在し、それを原因としてメモリリークが発生する。通常メモリ内部で回収し、その判断はＡＰ側で行うが、バグが存在し、指示を出すのを忘れることが多い。

ここで、１つのシステムが、１つのＡＰの不具合により、全面的に停止してしまうのでは不都合である。むしろ不具合を発生した１つのＡＰが自ら消滅し、再起動してくれるのであればこれにこしたことはない。

しかしながら、上述の特許文献１記載の技術では、メモリリークが内在した場合に、ヒープ枯渇を検知し、当該プロセスが自ら自プロセスの停止を実施して、その後再起動することで、不正動作の影響を極力Ｊａｖａ（登録商標）プロセス内に隠蔽することが困難である。そのため、マルチスレッド上で動作する業務オブジェクト等の相互干渉を極力排除することが困難であった。

本発明は、上記の課題を解決するためになされたものであり、自立型の障害検出により、システムの複雑性およびその制御の複雑性を排除した実行環境の制御方法およびプログラムを提供することを目的とする。

本発明の実行環境の制御方法は、実行環境のＡＰが定期的に動作するタイマスレッドを生成するステップと、
生成したタイマスレッドが定期的に動作する度にＪａｖａヒープ情報を取得してその情報の履歴を所定の記憶部に保持するステップと、
取得した前記情報の履歴と、所定のデータベースに格納されているＡＰ動作時の本来あるべき値であるプロパティ情報を比較するステップと、
ガベージコレクションの発生間隔とメモリ使用量に関する相関図に照らして、本来あるべき値に基づくしきい値を超えているため自ら停止する必要があると判断した場合は、詳細情報をＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）から採取するステップと、
必要な情報採取が完了した後に、終了ＡＰＩにより自プロセスの停止をＷｅｂＯＴＸ基盤に要求するステップと、
ＷｅｂＯＴＸ基盤が、自身を閉塞して新規要求を受け付けなくし、既に実行中の処理は最後まで実施し、その後要求を受け付けたプロセスの停止を行うステップと、
ＴＰモニタがプロセスの停止を確認後、前記プロセスの再起動を行うステップと
を有することを特徴とする。

本発明のプログラムは、コンピュータに、
実行環境のＡＰが定期的に動作するタイマスレッドを生成する処理と、
生成したタイマスレッドが定期的に動作する度にＪａｖａヒープ情報を取得してその情報の履歴を所定の記憶部に保持する処理と、
取得した前記情報の履歴と、所定のデータベースに格納されているＡＰ動作時の本来あるべき値であるプロパティ情報を比較する処理と、
ガベージコレクションの発生間隔とメモリ使用量に関する相関図に照らして、本来あるべき値に基づくしきい値を超えているため自ら停止する必要があると判断した場合は、詳細情報をＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）から採取する処理と、
必要な情報採取が完了した後に、終了ＡＰＩにより自プロセスの停止をＷｅｂＯＴＸ基盤に要求する処理と、
ＷｅｂＯＴＸ基盤が、自身を閉塞して新規要求を受け付けなくし、既に実行中の処理は最後まで実施し、その後要求を受け付けたプロセスの停止を行う処理と、
ＴＰモニタがプロセスの停止を確認後、前記プロセスの再起動を行う処理と
を実行させることを特徴とする。

本発明によれば、自立型の障害検出により、システムの複雑性およびその制御の複雑性を排除した実行環境の制御方法およびプログラムを提供することができる。

以下、本発明の第一の実施の形態について図面を参照して詳細に説明する。図１に本実施の形態におけるＪａｖａアプリケーション等の運用環境の一例を示す。

Ｊａｖａアプリケーションの実行環境において、ＷｅｂＯＴＸ基盤（ＯＳでもよい）の上位層にＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）があり、その上位層にＳｅｒｖｌｅｔ、ＪＳＰ（Ｊａｖａ Ｓｅｒｖｅｒ Ｐａｇｅｓ）、ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ）等のアプリケーションが動作する。Ｊａｖａアプリケーションの運用状況を最もよく知っているのは、実行環境の中で最下層に位置して実際にアプリケーションを実行しているＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）である。

ＡＰ動作時の適正値として本来あるべき値はＡＰの完成時の実験等により判明している。この本来あるべき値は所定のデータベースにプロパティ情報として格納されている。

所定のデータベースのプロパティ情報としての値は、コマンドを発行して設定することができる。また、事前に設定用プログラムを用いてシステム管理者等が設定してもよい。

次に、図４のフローチャートを参照して本実施の形態の動作について詳細に説明する。
まず、ＷｅｂＯＴＸ上のＡＰ起動時のｓｔａｒｔｕｐ処理により、定期的に（例えば、数秒間隔に）動作するタイマスレッドを生成する（Ｓ４０１）。

Ｊａｖａ仮想マシン（ＭＣ−Ｊａｖａ）で使用されているメモリ（ヒープ）の量は、"メモリの割り当て／解放"のイベント発生時に測定されたものが正確な量である。しかし、イベントの発生頻度は非常に高く、すべてのイベント発生時にデータを測定するとアプリケーションの運用に負荷がかかってしまう。統計的な分析のためには、定期的に取得するデータで行うことが可能であり、"メモリの割り当て／解放"イベント発生時にデータの測定を行う必要はない。

Ｊａｖａ仮想マシン（ＭＣ−Ｊａｖａ）は、自分自身の動作状況をよく知っているため、自身内でメモリ（ヒープ）不足を検出することができる。このメモリ不足によってマシン性能が低下する。Ｊａｖａ仮想マシン（ＭＣ−Ｊａｖａ）のメモリの解放処理、すなわちガベージコレクションは、マシン性能に対して非常に大きな影響を与えるが、上述したＡＰ等のバグが存在することでメモリの解放処理等が適切になされない場合がある。

次に、上記のステップＳ４０１で生成したタイマスレッドが定期的に動作する度にＪＶＭＴＩ経由でＪａｖａヒープ情報を取得する（Ｓ４０２）。そしてその情報の履歴を所定の記憶部に保持しておく。

そして、ステップＳ４０２で取得した情報と、プロパティ情報を比較し、自ら停止する必要があると判断した場合は、詳細情報をＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）から採取する（Ｓ４０３）。すなわち、メモリリークを解析するためにＨｅａｐＤｕｍｐを出力（ＪａｖａＳＥ５のｊｍａｐ相当の実行）する。これにより、自プロセスはどのような状態になったから停止するのかのログをＭＣＯｎｅログ等に残してＴＰモニタに知らせることができる。これまではＨｅａｐＤｕｍｐはメモリ空間の情報を出力する負荷のかかる処理であるので、通常は実行されなくこれまでのＡＰの不具合によりＡＰが消滅してしまうときには何も分析のための情報が残されていなかった。

ここで、プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準を、ガベージコレクションの発生間隔とメモリ使用量に関する相関図を用いて説明する。

図２および図３は、メモリ使用量２０、３０の変化とガベージコレクション２１、３１の発生をグラフ化して示したものである。

図２および図３のグラフでは、縦軸をメモリ量とし、横軸を時間としている。図２および図３において、実線はメモリ使用量２０、３０の時間変化を示し、点線は設定されている最大ヒープサイズ２２、３２を示す。Ｊａｖａ仮想マシン（ＭＣ−Ｊａｖａ）は、"メモリの割り当て"イベントによりメモリ使用量２０、３０が最大ヒープサイズ２２、３２を超えそうなときに、ガベージコレクション２１、３１を実行し、メモリの解放を行う。

図２は、ガベージコレクション２１０の発生間隔が短くなる傾向にあるが、ガベージコレクション２１０によってメモリの空きが回復する状態を表している。なお、ガベージコレクション２１０が発生しない安定した状態、あるいは、ガベージコレクション２１０の発生間隔が比較的長く、ガベージコレクション２１０によってメモリの空きが回復する状態ではメモリ使用量２００を示す線は横軸と平行となる。

ここで、図２のガベージコレクション２１０によってメモリの空きが回復する状態での最下点を結ぶ直線２３はフラットとなる。しかし、以下で説明する図３に示すような、なんらかの異常が発生していると直線（折線）３３は右肩上がりとなる。

図３は、ガベージコレクション２１０の発生間隔が短く、ガベージコレクション２１０によってメモリの空きが十分に回復しない状態を表している。ガベージコレクション２１０の発生頻度が通常なら２回のところが３回になるなど、その頻度も大きくなる。

プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、図３に示す直線（折線）３３の傾きの大きさである。また、ガベージコレクション２１０の発生頻度が考慮されてもよい。また、ＡＰの通常のオブジェクトの生成の特性が正規分布に近い特性が考慮されてもよい。ＡＰの完成時の実験等により判明している本来あるべき値に基づくしきい値を超えている場合には自ら自プロセスを停止する必要があると判断する。

なお、自ら停止する必要があると判断するルールは、自ら変更できてもよい。また自プロセスとしては変調をきたしているが、システム全体としては余裕があるので自プロセスを停止しないという判断がなされてもよい。

上記のステップＳ４０４で必要な情報採取が完了した後に、終了ＡＰＩ（新規）により自プロセスの停止をＷｅｂＯＴＸ基盤に要求する（Ｓ４０４）。

一方、ＷｅｂＯＴＸ基盤は、ステップＳ４０４における要求を受け付けたプロセスの停止を行う（Ｓ４０５）。すなわち、停止要求を受け付けたＷｅｂＯＴＸ基盤は、まず、自身を閉塞して新規要求を受け付けなくする。そして既に実行中の処理（浮いてなく張り付いているもの）は最後まで実施し、その後終了処理を行う。

最後に、ＴＰモニタはプロセスの停止を確認後、再起動を行う（Ｓ４０６）。そしてステップＳ４０１の処理へと戻ることとなる。例えば、入金と出金の両方が成功した場合にのみ認証されるトランザクション処理を実現するソフトウェアに有用である。

なお、上述する各実施の形態は、本発明の好適な実施の形態であり、本発明の要旨を逸脱しない範囲内において種々変更実施が可能である。例えば、Ｊａｖａ仮想マシン（ＭＣ−Ｊａｖａ）等の機能を実現するためのプログラムをＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）に読込ませて実行することにより機能を実現する処理を行ってもよい。さらに、そのプログラムは、コンピュータ読み取り可能な記録媒体であるＣＤ−ＲＯＭまたは光磁気ディスクなどを介して、または伝送媒体であるインターネット、電話回線などを介して伝送波により他のコンピュータシステムに伝送されてもよい。

本発明の実施の形態に係るＪａｖａアプリケーション等の運用環境の一例を示す図である。 通常のメモリ使用量の変化とガベージコレクションの発生をグラフ化して示した図である。 異常時のメモリ使用量の変化とガベージコレクションの発生をグラフ化して示した図である。 本発明の実施の形態の処理動作を示すフローチャートである。

Claims (10)

1. 実行環境のＡＰが定期的に動作するタイマスレッドを生成するステップと、
   生成したタイマスレッドが定期的に動作する度にＪａｖａヒープ情報を取得してその情報の履歴を所定の記憶部に保持するステップと、
   取得した前記情報の履歴と、所定のデータベースに格納されているＡＰ動作時の本来あるべき値であるプロパティ情報を比較するステップと、
   ガベージコレクションの発生間隔とメモリ使用量に関する相関図に照らして、本来あるべき値に基づくしきい値を超えているため自ら停止する必要があると判断した場合は、詳細情報をＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）から採取するステップと、
   必要な情報採取が完了した後に、終了ＡＰＩにより自プロセスの停止をＷｅｂＯＴＸ基盤に要求するステップと、
   ＷｅｂＯＴＸ基盤が、自身を閉塞して新規要求を受け付けなくし、既に実行中の処理は最後まで実施し、その後要求を受け付けたプロセスの停止を行うステップと、
   ＴＰモニタがプロセスの停止を確認後、前記プロセスの再起動を行うステップと
   を有することを特徴とする実行環境の制御方法。
2. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、前記相関図に示す直線（折線）の傾きの大きさであることを特徴とする請求項１記載の実行環境の制御方法。
3. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、ガベージコレクションの発生頻度であることを特徴とする請求項１または２記載の実行環境の制御方法。
4. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、ＡＰの通常のオブジェクトの生成の特性が正規分布に近い特性が考慮されることを特徴とする請求項１から３のいずれか１項に記載の実行環境の制御方法。
5. 自プロセスとしては変調をきたしているが、システム全体としては余裕があるので自プロセスを停止しないという判断がなされてもよいことを特徴とする請求項１から４のいずれか１項に記載の実行環境の制御方法。
6. コンピュータに、
   実行環境のＡＰが定期的に動作するタイマスレッドを生成する処理と、
   生成したタイマスレッドが定期的に動作する度にＪａｖａヒープ情報を取得してその情報の履歴を所定の記憶部に保持する処理と、
   取得した前記情報の履歴と、所定のデータベースに格納されているＡＰ動作時の本来あるべき値であるプロパティ情報を比較する処理と、
   ガベージコレクションの発生間隔とメモリ使用量に関する相関図に照らして、本来あるべき値に基づくしきい値を超えているため自ら停止する必要があると判断した場合は、詳細情報をＪａｖａ仮想マシン（ＭＣ−Ｊａｖａ）から採取する処理と、
   必要な情報採取が完了した後に、終了ＡＰＩにより自プロセスの停止をＷｅｂＯＴＸ基盤に要求する処理と、
   ＷｅｂＯＴＸ基盤が、自身を閉塞して新規要求を受け付けなくし、既に実行中の処理は最後まで実施し、その後要求を受け付けたプロセスの停止を行う処理と、
   ＴＰモニタがプロセスの停止を確認後、前記プロセスの再起動を行う処理と
   を実行させることを特徴とするプログラム。
7. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、前記相関図に示す直線（折線）の傾きの大きさであることを特徴とする請求項６記載のプログラム。
8. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、ガベージコレクションの発生頻度であることを特徴とする請求項６または７記載のプログラム。
9. 前記プロパティ情報との比較により、自ら停止する必要があると判断する際の判断基準は、ＡＰの通常のオブジェクトの生成の特性が正規分布に近い特性が考慮されることを特徴とする請求項６から８のいずれか１項に記載のプログラム。
10. 自プロセスとしては変調をきたしているが、コンピュータシステム全体としては余裕があるので自プロセスを停止しないという判断がなされてもよいことを特徴とする請求項６から９のいずれか１項に記載のプログラム。

Images