(57)【要約】【課題】  メモリリークのあるソフトウェアを使って継続的なサービスを実現し、メモリリークの対処の間隔をマシン台数に関係なく実現し、メモリリークの程度や頻度が異なる処理が混在してもメモリリークの開放を可能とする。【解決手段】  本発明は、プロセス管理手段では、同時再起動数に応じて、同時再起動数分の処理手段を選択して、その処理手段に停止を指示し、停止分の処理手段からの再起動完了通知を受信する処理を全ての処理手段に対して繰り返す手段を有し、処理手段では、任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じて再起動カウンタの値を増加させ、カウンタ値が事前に設定された基準値を超えた場合に、当該プロセスを停止する停止制御手段を有する。【選択図】  図１
2011054114.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理装置であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
前記処理手段群を管理するプロセス管理手段と、を有し、
前記プロセス管理手段は、
運用者からの再起動通知に応じて、または、定期的に、同時再起動数に応じて、同時再起動数分の処理手段を選択して、各処理手段に停止を指示し、そして、停止分の処理手段を再起動させ、該停止分の処理手段からの再起動完了通知を受信する処理を全ての処理手段に対して繰り返す再起動制御手段を有し、
前記処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、該再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合、及び、前記プロセス管理手段から停止を指示された場合に、当該プロセスを停止する停止制御手段と、
前記プロセス管理手段から再起動が指示された場合に再起動を行い、前記再起動完了通知を該プロセス管理手段に送信する手段と、を有する
ことを特徴とするメモリリーク対応処理装置。
【請求項２】
ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理装置であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
前記処理手段群を管理するプロセス管理手段と、を有し、
前記プロセス管理手段は、
実行中の処理手段の数をカウントし、予め設定された管理対象処理手段の数に満たなければ不足分の処理手段を起動させる処理を、該処理手段からの停止通知を受信するまで、または、定期的に繰り返す起動制御手段を有し、
前記処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、該再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止させ、停止通知を前記プロセス管理手段に送信する停止制御手段と、
前記プロセス管理手段から起動が指示されると、プロセスを起動させる手段と、を有する
ことを特徴とするメモリリーク対応処理装置。
【請求項３】
前記処理手段は、
複数のサービス用の処理モジュールと、
各サービス用モジュールを組み合わせて実行するためのスクリプトの制御手段と、
外部から入力された少なくとも１つ以上のサービスを実現するスクリプトを処理IDと対応させて記憶手段に格納するスクリプト格納手段と、
前記キュー管理手段から取得したデータもしくはデータを取得したキュー管理手段に直接的または間接的に付随する処理IDに基づいて前記記憶手段からスクリプトを取得して実行するスクリプト実行手段と、
を更に有することを特徴とする請求項１または２記載のメモリリーク対応処理装置。
【請求項４】
ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理方法であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
前記処理手段群を管理するプロセス管理手段と、を有する装置において、
前記処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、該再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止させ、
プロセス管理手段は、
運用者からの再起動通知に応じて、または、定期的に、同時再起動数に応じて、同時再起動数分の処理手段を選択して、各処理手段に停止を指示し、
プロセス管理手段から停止を指示された処理手段は、
プロセスを停止させ、停止通知を前記プロセス管理手段に送信し、
前記プロセス管理手段は、停止させた処理手段に再起動を指示し、
前記プロセス管理手段から再起動を指示された処理手段は、
プロセスを再起動させて該プロセス管理手段に再起動完了通知を送信する再起動ステップを行う
ことを特徴とするメモリリーク対応処理方法。
【請求項５】
ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理方法であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
前記処理手段群を管理するプロセス管理手段と、を有する装置において、
前記処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、該再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止し、前記プロセス管理手段に停止通知を送信する停止制御ステップを行い、
前記プロセス管理手段は、
前記処理手段から前記停止通知を受信すると共に、実行中の処理手段の数をカウントし、予め設定された管理対象処理手段の数に満たなければ不足分の処理手段を起動させる起動指示を行う起動制御ステップを、該処理手段からの停止通知を受信するまで、または、定期的に行い、
前記処理手段は、
前記プロセス管理手段から起動指示があるとプロセスを起動させ、起動完了通知を該プロセス管理手段に送信する起動ステップを行う
ことを特徴とするメモリリーク対応処理方法。
【請求項６】
前記処理手段は、
外部から入力された少なくとも１つ以上のサービスを実現するスクリプトを処理IDと対応させて記憶手段に格納しておき、
前記キュー管理手段から取得したデータもしくはデータを取得したキュー管理手段に直接的または間接的に付随する処理IDに基づいて前記記憶手段からスクリプトを取得して各サービス用処理モジュールを組み合わせて実行する
ことを特徴とする請求項４または５記載のメモリリーク対応処理方法。
【請求項７】
請求項１乃至３のいずれか１項に記載のメモリリーク対応装置の各手段としてコンピュータを機能させるためのメモリリーク対応処理プログラム。
【請求項８】
請求項７記載のメモリリーク対応処理プログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メモリリーク対応処理方法及び装置及びプログラムに係り、特に、ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するためのメモリリーク対応処理方法及び装置及びプログラムに関する。
【背景技術】
【０００２】
従来、メモリリークの発生を前提とした技術として以下のようなものがあった。
【０００３】
第1の方法は、Act-Stby型の高可用クラスタ構成を活用する方法である。サービス用のアプリケーションサーバを上記クラスタ構成とし、所定時間毎にフェールオーバ（現用サーバから待機サーバへの切り替え）を実行し、旧現用系のＯＳやサービス用のアプリケーション・プログラムをリセット（再起動）することで、サービスの停止を未然に防ぐものである（例えば、特許文献1参照）。
【０００４】
また、第２の方法は、サービス中断を最小化する方法である。Ｗｅｂサービスや映像ストリーミングサービスなどの参照系サービスで主に用いられる方法である。
【０００５】
典型的な構成を図１０に示す。
【０００６】
これは、この同一コンテンツを持つＡｃｔサーバ群（図１０のマシン２１〜マシン２ｍ）を並べ、そのフロントに処理の振り分けを行うロードバランサ（ＬＢ）１を置いたクラスタ構成として外側の追記クライアント１０１〜１０ｘの処理リクエストに対して、ＬＢ１が処理をマシン２１〜マシン２ｍに振り分けて対応する。このとき各マシンの処理にメモリリークの発生の可能性がある場合、例えば、マシン２１で考えると、
（１）まず、各追記クライアント１０からの新たなコネクションやリクエストがマシン２１に行かないようにＬＢ１を設定変更し、マシン２１上で残るサービスが全て終了した段階で、マシン２１を停止し、リソースを開放し、再起動を行う。
【０００７】
（２）マシン２１の再起動が完了し、アプリケーション・プログラムの起動も整った段階で、ＬＢ１に対し、マシン２１への新たなコネクションやリクエストを許可するように設定変更する。
【０００８】
上記の作業を残りのマシン２２〜マシン２ｍについても順に実施する。
【０００９】
これらの一連の作業を定期的に行うことで、サービスを停止することなく各マシンのメモリリークを解放することが可能になる。
【００１０】
第３の方法として、先の例でＬＢ（ロードバランサ）という部分の代わりに、管理サーバを設け、評価式に基づいて複数の処理装置のうち再起動を行う装置を選択するようにすることで、再起動の影響をできるだけ受けないようにする再起動サーバを選択するようにする方法がある（例えば、特許文献２参照）。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００１−１８８６８４号公報
【特許文献２】特開２００６−３１０９６号公報
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、上記従来の第1の方法は、フェールオーバの間に、アプリケーション・プログラム、つまりサービスが中断するという問題があり、無停止が求められるサービスに向かない。
【００１３】
また、第２の方法は、以下のような問題がある。
【００１４】
・サービスの停止もしくはアプリケーション・プログラムの停止を確認するための手段の汎用化がなく、自動化ができていない点；
・全体の再起動までにマシンの台数に応じた時間がかかる点；
・マシン単位での再起動となるため、全体に復帰までの時間がかかる点；
これらの問題から、高い頻度のメモリリークへの対応には向かないことも問題であった。
【００１５】
また、第３の方法は、一般にＬＢに相当する集中サーバ部分がシステム全体のボトルネックとなるケースがあり、その部分で評価を行うことは、性能面で良い方式とはいえないという問題があった。
【００１６】
同様に、ＬＢで各マシンの状態を把握する方法もシングルポイントであるＬＢの負荷を高くするため、性能面でよい方式とはいえない。
【００１７】
本発明は、上記の点に鑑みなされたもので、
・メモリリークのあるソフトウェアを使って、継続的なサービスを実現すること；
・その際、シングルポイントなるボトルネック部分を設けないこと；
・メモリリークの頻度の高い場合にも対応できること；
が可能なメモリリーク対応処理方法及び装置及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
図１は、本発明の原理構成図である。
【００１９】
本発明（請求項１）は、ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理装置であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段２０のキュー２１からデータを取得して処理を行う少なくとも２つ以上の処理手段３２と、
処理手段３２群を管理するプロセス管理手段３１と、を有し、
プロセス管理手段３１は、
運用者からの再起動通知に応じて、または、定期的に、同時再起動数に応じて、同時再起動数分の処理手段を選択して、各処理手段に停止を指示し、そして、停止分の処理手段３２を再起動させ、該停止分の処理手段からの再起動完了通知を受信する処理を全ての処理手段に対して繰り返す再起動制御手段３１１を有し、
処理手段３２は、
任意のアルゴリズムによって１つのキュー管理手段２０を選択し、該キュー管理手段２０からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合、及び、プロセス管理手段３１から停止を指示された場合に、当該プロセスを停止する停止制御手段３２１と、
プロセス管理手段３１から再起動が指示された場合に再起動を行い、再起動完了通知を該プロセス管理手段３１に送信する手段と、を有する。
【００２０】
本発明（請求項２）は、ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理装置であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
処理手段群を管理するプロセス管理手段と、を有し、
プロセス管理手段は、
実行中の処理手段の数をカウントし、予め設定された管理対象処理手段の数に満たなければ不足分の処理手段を起動させる処理を、該処理手段からの停止通知を受信するまで、または、定期的に繰り返す起動制御手段を有し、
処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じたカウンタの値を増加（もしくは減少）させ、再起動カウンタが事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止させ、停止通知を前記プロセス管理手段に送信する停止制御手段と、
プロセス管理手段から起動が指示されると、プロセスを起動させる手段と、を有する。
【００２１】
また、本発明（請求項３）は、請求項１または２の処理手段において、
複数のサービス用の処理モジュールと、
各サービス用モジュールを組み合わせて実行するためのスクリプトの制御手段と、
外部から入力された少なくとも１つ以上のサービスを実現するスクリプトを処理IDと対応させて記憶手段に格納するスクリプト格納手段と、
キュー管理手段から取得したデータもしくはデータを取得したキュー管理手段に直接的または間接的に付随する処理IDに基づいて記憶手段からスクリプトを取得して実行するスクリプト実行手段と、を更に有する。
【００２２】
図２は、本発明の原理を説明するための図である。
【００２３】
本発明（請求項４）は、ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理方法であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
処理手段群を管理するプロセス管理手段と、を有する装置において、
処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し（ステップ１）、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ（ステップ２）、再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止させ、プロセス管理装置に停止通知を送信し（ステップ３）、
プロセス管理手段は、
運用者からの再起動通知に応じてまたは定期的に、同時再起動数に応じて（ステップ４）、同時再起動数分の処理手段を選択して（ステップ５）、各処理手段に停止を指示し（ステップ６）、
プロセス管理手段から停止を指示された処理手段は、
プロセスを停止させ、プロセス管理手段に停止通知を送信し（ステップ７）、
前記プロセス管理手段は、停止させた処理手段に再起動を指示し（ステップ８）、
前記プロセス管理手段から再起動を指示された処理手段は、
プロセスを再起動させて（ステップ９）該プロセス管理手段に再起動完了通知を送信する（ステップ１０）。
【００２４】
本発明（請求項５）は、ソフトウェアの品質によるメモリの解放漏れ（以下、メモリリーク）に対応しながらサービスを提供するメモリリーク対応処理方法であって、
外部から受け付けたデータをキューイングして管理するキュー管理手段のキューからデータを取得して処理を行う少なくとも２つ以上の処理手段と、
処理手段群を管理するプロセス管理手段と、を有する装置において、
処理手段は、
任意のアルゴリズムによって１つのキュー管理手段を選択し、該キュー管理手段からデータを少なくとも１件以上取得し、該データに応じた処理を実行する中で、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値を増加（もしくは減少）させ、再起動カウンタの値が事前に設定された基準値を超えた（もしくは下回った）場合に、当該プロセスを停止し、プロセス管理手段に停止通知を送信する停止制御ステップを行い、
プロセス管理手段は、
処理手段から停止通知を受信すると共に、実行中の処理手段の数をカウントし、予め設定された管理対象処理手段の数に満たなければ不足分の処理手段を起動させる起動指示を行う起動制御ステップを、該処理手段からの停止通知を受信するまで、または、定期的に行い、
処理手段は、
プロセス管理手段から起動指示があるとプロセスを起動させ、該プロセス管理手段に起動完了通知を送信する。
【００２５】
また、本発明（請求項６）は、請求項４または５の処理手段において、
外部から入力された少なくとも１つ以上のサービスを実現するスクリプトを処理IDと対応させて記憶手段に格納しておき、
キュー管理手段から取得したデータもしくはデータを取得したキュー管理手段に直接的または間接的に付随する処理IDに基づいて記憶手段からスクリプトを取得して各サービス用処理モジュールを組み合わせて実行する。
【００２６】
本発明（請求項７）は、請求項１乃至３のいずれか１項に記載のメモリリーク対応装置の各手段としてコンピュータを機能させるためのメモリリーク対応処理プログラムである。
【００２７】
本発明（請求項８）は、請求項７記載のメモリリーク対応処理プログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体である。
【発明の効果】
【００２８】
上記のように本発明によれば、サービスを実現するプロセス（処理手段）群が複数存在し、その中の一部プロセス群の再起動を常態化することによって、メモリリークのあるソフトウェアを使って、継続的なサービスを実現することが可能になる。
【００２９】
また、個別のアプリケーション・プログラムに特化したサービス停止確認の方法を用意する必要がなく、汎用的であり、自動化が可能である。
【００３０】
さらに、処理モジュール毎に、再起動カウンタの増減値を調整すれば、メモリリークの程度や頻度が異なる処理が混在していても、プロセスの処理内容に応じたメモリリーク解放が可能になり、無駄なプロセスのリブートを避けることが可能になる。（ここで、現プロセスのメモリリーク量の観測手段等を組み合わせて、より再起動のタイミングを最適化することも、本発明の応用の範囲として可能である。
【００３１】
また、本発明は、一つのマシン内の複数のプロセスについて順に再起動を実施するため、マシン台数に関わらず、切り替え完了にかかる時間がほぼ一定という特徴を持ち、メモリリーク対処までの作業時間の見積がしやすい。よって、マシン台数が増えていく環境であっても、メモリリーク対処の間隔を一定に保ち易く、短時間のメモリリーク対応が可能になる。
【００３２】
以上から、メモリリークの頻度が高い場合にも対応が可能になる。
【００３３】
また、ロードバランサのような集中管理サーバが処理のメインの流れ内には存在しないため、ボトルネックが発生しにくい。
【００３４】
本発明では、マシンが1台の場合でも対処が可能で、かつ、複数台になった場合でも切り替えの方式が同一で理解し易い、という効果もある。
【図面の簡単な説明】
【００３５】
【図１】本発明の原理構成図である。
【図２】本発明の原理を説明するための図である。
【図３】本発明の第１の実施の形態におけるシステム構成図である。
【図４】本発明の第１の実施の形態におけるキュー部の動作を示す図である。
【図５】本発明の第１の実施の形態における処理マシンの処理部の動作を示す図である。
【図６】本発明の第１の実施の形態における処理マシンのプロセス管理部の動作を示す図である。
【図７】本発明の第２の実施の形態におけるプロセス管理部の動作を示す図である。
【図８】本発明の一実施例におけるシステム構成図（その１）である。
【図９】本発明の一実施例におけるシステム構成図（その２）である。
【図１０】従来のシステム構成図である。
【発明を実施するための形態】
【００３６】
以下、図面と共に本発明の実施の形態を説明する。
【００３７】
まず、本発明のアプローチの概要を示す。
【００３８】
・ＯＳからの再起動ではなく、アプリケーション・プログラムのプロセス（以下、単に、「プロセス」や「アプリケーション・プロセス」と呼ぶこともある）の自立的もしくは定時的もしくは運用者指示により再起動により、プロセスのメモリリークの解放を実施する。
【００３９】
・アプリケーション・プロセスは、同一の機能のプロセスを同一マシン内で複数実行させておくことで、1プロセスが停止してもサービスは停止しない状態を作る。
【００４０】
・アプリケーション・プロセスは、複数（多数）のマシンで実行させておくことで、サービスのスケーラビリティを維持することを可能にする。同時に、サービスの受付口を複数持つことで、ＬＢのようなシングルポイントのボトルネックを発生することを避ける。
【００４１】
・アプリケーション・プロセスは、特定機能の実行や特定データの処理に応じて、カウンタをアップさせて、カウンタが閾値を越えた段階で停止することで、メモリリークの解放を行う。
【００４２】
また、1つのアプリケーション・プロセスが、複数のサービス用のアプリケーション・プログラムを内包し、外部からの条件によって実行する処理内容を切り替えて異なるサービスとしての挙動を行うという構成を許容している。このため、サービス種別毎や、サービスの実行時に処理が流れるルート毎に、メモリリーク量が異なるという問題もある。この場合でもアプリケーション・プロセスの再起動回数も最低限にすることも行う。
【００４３】
そのため、特定の処理モジュールが一定実行回数実行された後、もしくは、残メモリ量に応じて自動的に再起動を実行することも行う。
【００４４】
［第1の実施の形態］
図３は、本発明の第1の実施の形態におけるシステム構成を示す。
【００４５】
同図に示すシステムは、少なくとも２つ以上のキュー部２０１〜２０ｊと、少なくとも２つ以上の処理マシン３０１〜３０ｍから構成される。なお、当該処理マシン３０は、図１０に示すＡＣＴサーバであるものとする。
【００４６】
各キュー部２０１〜２０ｊは、外部から受け付けたデータを、キュー領域にキューイングする。
【００４７】
処理マシン３０１〜３０ｍは、それぞれ、各処理マシン３０毎に１つのプロセス管理部３１１〜３１ｍと、少なくとも２つ以上存在する処理部３２１１〜３２mkを有する。
【００４８】
本実施の形態では、プロセス管理部３１が、運用者からの通知や提示通知等の外部トリガを元に、処理部３２を再起動させる場合を説明する。
【００４９】
図４、図５、図６は、本発明の第１の実施の形態における各構成要素の動作を示す図であり、図４は、キュー部２０１〜２０ｎ、図５は処理部３２１１〜３２mk、図６はプロセス管理部３１１〜３１ｍの各動作を示す。
【００５０】
各キュー部２０１〜２０ｎは、追記クライアント１０からのデータを受け付け（図４：Q‐AC‐1）、キュー領域へのデータを追加する（図４：Q-AC-2）。
【００５１】
各処理マシン３０１〜３０ｍのプロセス管理部３１１〜３１ｍは、運用者による処理部３２の再起動通知を受信、もしくは定時まで待機し（図６：MM-1）各処理マシン３０１〜３０ｍ内の処理部３２１１〜３２mk群を管理し（図６：MM-2）、同時再起動数（図６：D-3）に応じて、同時再起動数分の処理部３２を選択して各処理部３２に停止を指示し（図６：MM-3）、停止させた数分の処理部３２を再起動させ（図６：MM-4）、再起動後の処理部３２からの再起動完了通知を受信する（図６：MM-5）。各プロセス管理部３１１〜３１ｍは、上記の処理を全ての処理部３２について実施し（図６：MM-6）、当該処理を運用者から再起動通知に応じて、または、定期的に繰り返す。
【００５２】
また、各処理マシン３０の各処理部３２は、プロセスの起動（再起動完了通知）をプロセス管理部３１に通知し（図５：F-1）、再起動カウンタをゼロクリアする（図５：F-2）。任意のアルゴリズムによって１つのキュー部２０を選択し（図５：F-3）、キュー部２０に対してデータ取得要求を送る。キュー部２０は、データ取得要求を受け付け（図４：Q-F-1）、処理中フラグのないデータ群中で古いデータからデータを選択し、処理中フラグを付与した後、要求元の処理部３２に送信する（図４：Q-F-2）。キュー部２０は、この後、処理中のデータについてタイムアウト監視し、タイムアウトしたら処理中フラグを削除する（図４：Q-F-3）。
【００５３】
処理部３２は、キュー部２０からデータを少なくとも１件以上取得し（図５：F-4）、データに応じた処理を実行する（図５：F5）。ここで、データには情報源IDが付与され、その情報源IDに応じた処理が定義されており、その処理が実行されるものとする。処理部３２は、再起動カウンタを有し、処理実行の際、処理もしくはデータに応じてリソースリークが発生するリスクに応じて再起動カウンタの値を増加（もしくは減少）させ（図５：F-6）、キュー部２０に対して処理完了を通知する（図５：F-7）。キュー部２０は、処理部３２からデータ処理完了通知を受け付け（図４：Q-F-4）、キュー領域から対象データを削除する（図４：Q-F-5）。
【００５４】
処理部３２は、再起動カウンタが事前に設定される基準値を超えた（もしくは下回った）場合に（図５：F-8）、そのプロセスを停止する（図５：F-10）。なお、プロセスを停止する前に、プロセス管理部３１に対して停止通知を送信してもよい（図５：F-9）。
【００５５】
なお、各処理部３２１１〜３２mkに組み込まれる処理モジュール群は等価である。
【００５６】
上記の一連上記の処理により、メモリリーク対応処理モジュールの連続運転を行う。これにより、運用者の指示や定期的なタイミングに応じて、処理部３２の再起動が順に実行され、順にメモリリークが解放されると共に、残った処理部３２でサービス継続が可能となる。
【００５７】
［第２の実施の形態］
本実施の形態では、処理マシン３０のプロセス管理部３１が実行中の処理部３２の数を監視し、処理部３２を自動充足させる場合について説明する。
【００５８】
本実施の形態におけるシステム構成は前述の第1の実施の形態と同様であるので、その説明は省略する。
【００５９】
図７は、本発明の第２の実施の形態における処理マシンの動作を説明するための図である。
【００６０】
プロセス管理部３１は、各マシン３０内で実行中の処理部３２の数を監視し（図７：MA-2）、管理対象の処理部の数（図７：D-2）に満たなければ不足分の処理部３２を起動し（図７：MA-3）、それをマシン３０内の処理部３２からの停止通知の受信毎（図７：MA-1）、もしくは、定期的に繰り返す。
【００６１】
また、各処理マシン３０の各処理部３２は、プロセス管理部３１から起動が指示されると、プロセスを起動させ、起動完了通知をプロセス管理部３１に送信し(図５：F-1)、再起動カウンタをゼロクリアし（図５：F-2）任意のアルゴリズムによって１つのキュー部２０を選択し（図５：F-3）、キュー部２０に対してデータ要求を送る。キュー部２０は、データ取得要求を受け付け（図４：Q-F-1）、処理中フラグのないデータ群中で古いデータからデータを選択し、処理中フラグを付与した後、要求元の処理部３２に送信する（図４：Q-F-2）。キュー部２０は、この後、処理中のデータについてタイムアウトを監視し、タイムアウトしたら処理中フラグを削除する（図４：Q-F-3）。
【００６２】
処理部３２は、キュー部２０からデータを少なくとも１件以上取得し（図５：F-4）、データに応じた処理を実行する（図５：F5）。ここで、データには情報源IDが付与され、その情報源IDに応じた処理が定義されており、その処理が実行されるものとする。その際、処理もしくはデータに応じてリソースリークが発生するリスクに応じた再起動カウンタの値増加（もしくは減少）を行い（図５：F-6）、キュー部２０に対して処理完了を通知する（図５：F-7）。キュー部２０は、処理部３２からデータ処理完了通知を受け付け（図４：Q-F-4）、キュー領域から対象データを削除する（図４：Q-F-5）。
【００６３】
処理部３２は、再起動カウンタが事前に設定される基準値を超えた（もしくは下回った）場合に（図５：F-8）、そのプロセスを停止する（図５：F-10）。なお、プロセスを停止する前に、プロセス管理部３１に対して停止通知を送信してもよい（図５：F-9）。
【００６４】
なお、各処理部３２１１〜３２mkに組み込まれる処理モジュール群は等価である。
【００６５】
上記の一連上記の処理により、メモリリーク対応処理モジュールの連続運転を行う。これにより、処理部３２の再起動のためのカウンタ値が特定値を超えた場合に、処理部３２が停止するのに応じて再起動が自動的に実行され、順にメモリリークが開放されると共に、残った処理部３２でサービス継続が可能となる。
【実施例】
【００６６】
以下に、本発明の実施例を示す。
【００６７】
図８、図９は、本発明の一実施例のシステム構成を示し、図８は、運用指示がある場合の例であり、運用者による運用指示と各プロセス管理部３１による制御により再起動される例であり、図９は、キュー振り分けサーバを設けた構成であり、再起動はプロセス管理部３１により行われ、停止タイミングは処理部３２により制御される例である。
【００６８】
以下の例において、データとしての制限は特に無く、例えば以下のようなものである。
【００６９】
・ＲＤＢのレコード型やＸＭＬ；
・ラージオブジェクト（ＣＬＯＢやＢＬＯＢ）や画像や音声などメディアデータ；
・システムのログや処理リクエスト；
・Ｗｅｂデータ、ライフログデータ、メールなど；
データベースやデータストリーム管理システムで扱う多様なデータ型について、本発明では同等に扱える。
【００７０】
以下では、サービスが以下の２種類存在する場合の例を示すが、種類が増えても同様である。
【００７１】
＜サービス１＞
人感センサに反応したら、横のカメラ映像をチェックし、そのとき画像に顔があったら、顔認識を行って、その人を特定し、社員であれば、社員ＤＢに記録し、認識できなければ警報装置を起動する。
【００７２】
＜サービス２＞
監視カメラ映像を流し続ける。
【００７３】
上記のサービスは後述する処理モジュールでそれら組み合わせるスクリプトで実現され、同一プロセスの中でスクリプトが切り替えられることで、各サービスが実行される。
【００７４】
情報源としては、以下の人感センサ（ＪＩＮＫＡＮ）とＷｅｂカメラ映像（ＷＥＢＣＡＭ００１）があったとする。なお、各入力レコードには、
・人感センサ：
情報源ＩＤ：ＪＩＮＫＡＮ
出力：人感センサ値ｎ（int）−人を感じれば「１」、人を感じなければ「０」
・Ｗｅｂカメラ映像；
情報源ＩＤ：ＷＥＢＣＡＭ００１
出力：画像（jpeg）
また、処理モジュールとして、以下の顔検出(extractFace)、顔認識(recognitionFace)、社員DBへの登録（stioreDB）、警報装置を起動(alert)、端末にメッセージを出力(message),
ファイルを保存（saveAs）、入力レコードのカラム値参照（Get）、情報源の最新レコード参照（Read）が処理部３２内に組み込まれているとする。
【００７５】
●顔検出（顔数の取得）
名称：countFaces()
引数：画像(jpeg)
出力：顔数(int)
●顔検出（顔画像配列の取得）
名称：extraceFace()
引数：画像（jpeg）
出力：顔画像（jpeg）
●顔認識
名称：recognitionFace()
引数：顔画像（jpeg）
出力：顔が認識できた場合には社員コード(string)
顔が認識できなかった場合にはNULL文字列
●社員ＤＢへの登録
名称：storeDB()
引数：社員コード
時刻
出力：なし
●警報装置を起動
名称：altert()
引数：警報秒数ｎ(int)
出力：なし
●端末にメッセージを出力
名称：message()
引数：文字列
出力：なし
●ファイルを保存
名称：saveAs()
引数：保存先パス
保存対象
出力：なし
●入力レコードのカラム値参照
名称：get()
引数：入力レコードのカラム
出力：入力レコードのカラム値
●情報源の最新レコード参照
名称：readLatest();
引数：情報源ＩＤ
情報源ＩＤのカラム
出力：情報源ＩＤの指定カラムの最新カラム値
上記の処理モジュールをスクリプトによって組み合わせることによって構成されるサービス用のアプリケーション・プログラムとして、以下のような＜APPLICATION_PROGRAM1＞と＜APPLICATION_PROGRAM2＞があったとする。これらは前述のサービス１、サービス２の実装にそれぞれ対応する。なお、以下のスクリプトは独自の擬似コードで記述しているが，同等のプログラミング言語であって構わない。
【００７６】
＜APPLICATION_PROGRAM1＞
APPLICATION_PROGRAM1 = {
int T;  // 入力レコードの時刻値
int R;  // 入力レコードの人感センサ値
int T = get(JINKAN, Time);  // 時刻値の取得
int R = get(JINKAN, Image);  // 人感センサの状態取得
if ( R == 0 ) {  // 人感センサに反応しなかったらイベント終了
return;
}
else {  // 人感センサに反応したら
jpeg J; 
J = readLatest( WEBCAM001);  // 横のＷｅｂカメラの画像を参照
int num_Face;
num_Face = countFaces( J);
if ( num_Face <= 1 )  {  // 人感センサに反応があるが顔が映っていない
message( "感知したけど顔はなし");
return;
} 
else {  // 人感センサが反応して，顔が映っていた
int Faces[];  // 配列
Faces = extractFaces(J);
for( int i=0; i<num_Face; i++) { // 顔数分，社員か否かチェック
string C;
C = recognitionFace( Faces[i]);
if ( C != NULL ) {  //社員であれば，社員ＤＢに記録
storeDB( C, T);
}
else { // 社員以外の顔が映っていた
message("警報  未知の人物検出")
alert( 3);  // 警報を３秒
}
}
return;
}
}
}
＜APPLICATION_PROGRAM2＞
APPLICATION_PROGRAM2 = {
int T;  // 入力レコードの時刻値
int J;  // 入力レコードの人感センサ値
int T = get( WEBCAM001, Time);  // 時刻値の取得
int J = get( WEBCAM001, Image);  // カメラ映像の状態取得
saveAs( "/var/www/html/camlog/${T}.jpg", J);
return;
}
このとき処理として＜APPLICATION_PROGRAM1＞は、人感センサに反応したら、横のカメラ映像WEBCAM001をチェックし、そのとき画像に顔があったら、顔認識を行ってその人を特定し、社員であれば、社員ＤＢに記録し、認識できなければ、警報装置を３秒間起動という処理である。
【００７７】
また、このとき処理として＜APPLICATION_PROGRAM2＞は、Ｗｅｂカメラの映像の時刻をファイル名とする画像としてhtmlディレクトリ配下に保存する処理である。
【００７８】
これら＜APPLICATION_PROGRAM1＞、＜APPLICATION_PROGRAM2＞は図５のF-5に対応する。
【００７９】
このとき、顔認識処理である「recognitionFace」とＤＢへの投入処理である「storeDB」にメモリリークがそれぞれ残っており、「recognitionFace」は１００回実行される毎に再起動するのが概ね安全と仮定し、storeDBは５０００回実行される毎に再起動するのが概ね安全だったと仮に想定する。
【００８０】
その場合、処理部３２は、「recognitionFace」は「storeDB」の５０倍メモリリーク量が多いと判断し、「recognitionFace」の１回の実行に対して再起動カウンタの＋５０を「storeDB」の１回の実行に対して再起動カウンタの＋１を行い（図５：F‐6）、再起動カウンタの値が５０００を超えたら再起動する（図５：F‐8，F‐10）ように指定するには、再起動カウンタのカウントアップ処理をrebootCountup()とした場合、以下の＜APPLICATION_PROGRAM1'＞のように「rebootCountup(50)」を追加する。なお、この上限値５０００は別途何らかの方法（例えば、設定ファイル、起動パラメータ、スクリプトの宣言文など）でプロセスに指定してあるとする。
【００８１】
＜APPLICATION_PROGRAM1'＞
APPLICATION_PROGRAM1' = {
int T;  // 入力レコードの時刻値
int R;  // 入力レコードの人感センサ値
int T = get(JINKAN, Time);  // 時刻値の取得
int R = get(JINKAN, Image);  // 人感センサの状態取得
if ( R == 0 ) {  // 人感センサに反応しなかったらイベント終了
return;
}
else {  // 人感センサに反応したら
jpeg J; 
J = readLatest( WEBCAM001);  // 横のＷｅｂカメラの画像を参照
int num_Face;
num_Face = countFaces( J);
if ( num_Face <= 1 )  {  // 人感センサに反応があるが顔が映っていない
message( "感知したけど顔はなし");
return;
} 
else {  // 人感センサが反応して，顔が映っていた
int Faces[];  // 配列
Faces = extractFaces(J);
rebootCountup(50)
for( int i=0; i<num_Face; i++) { // 顔数分，社員か否かチェック
string C;
C = recognitionFace( Faces[i]);
if ( C != NULL ) {  //社員であれば，社員ＤＢに記録
storeDB( C, T);
rebootCountup(1)
}
else { // 社員以外の顔が映っていた
message("警報  未知の人物検出")
alert( 3);  // 警報を３秒
}
}
return;
}
}
}
＜APPLICATION_PROGRAM1'＞と＜APPLICATION_PROGRAM2＞は、図８、図９の各処理部３２１１〜３２ｍｋの各々の中に、何らかの契機（起動や運用者通知など）によって読み込まれている。
【００８２】
情報源「JINKAN」と「WEBCAM001」は、追記クライアント１０１〜１０ｘによっていずれかのキュー部２０に追記される。
【００８３】
この例では追記クライアント１０１が「JINKAN」の情報をキュー部２０1のキュー２に、追記クライアント１０２が「WEBCAM001」の情報をキュー部２０nのキューｎに連続して追記し続けているとする。
【００８４】
これらを、図４〜図７のフローチャートと対応付けて説明する。
【００８５】
まず、人感センサJINKANのデータは、例えば毎秒、追記クライアント１０１によって取得（図４：Q-AC-1）され、キュー部２０１のキュー２にデータ追加（図４：Q-AC-2）され続ける。
【００８６】
同様に、Ｗｅｂカメラ「WEBCAM001」の画像データは、例えば、秒４フレームで追記クライアント１０２によって取得（図４：Q-AC-1）され、キュー部２０nのキューｎにデータ追記（図４：Q-AC-2）され続ける。
【００８７】
処理部３２１１〜３２ｍｋの各々は、まず、プロセス管理部３１によって起動され（図５：F-1）、後に使う再起動カウンタを０クリアして、プロセスの空間内に保持し、停止するまで以下の過程（図５：F-３〜F-8）を繰り返す。
【００８８】
まず、システム内に存在する複数のキュー部２０の中から任意の１つを選択（図５：F-3）する。この選択手法はラウンドロビンのような単純なものであっても，確率を使った高度な方法であっても構わない。
【００８９】
ここで選択したキュー部２０は「JINKAN」のデータが追記されているキュー２だったとする。
【００９０】
これに対応するキュー２側の処理は、各処理部３２からのデータ取得要求（図４：Q-F-1）を受付け、キュー２上の処理中フラグのないデータ群の中で最も古いデータを選択し、キュー２上に処理中フラグをつけた後、要求元の処理部３２に送信（図４：Q-F-2）し、要求元の処理部３２の停止等に備えて、処理中データについて、タイムアウト監視を設定（図４：Q-F-3）して、次の処理部３２からの要求を待つ処理に戻る。この処理部を例えば処理部３２２３として以下説明する。
【００９１】
処理部３２２３は、選択したキュー２からのデータ送信（図４：Q-F-2）を受けて、１件データを取得する（図５：F-4）。
【００９２】
ここで「JINKAN」情報源から来たデータには、＜APPLICATION_PROGRAM1'＞を適用するという情報が事前に定義されているとし、先に示した擬似コードの＜APPLICATION_PROGRAM１'＞が実行（図５：F-5）され、その中で、再起動カウンタのカウントアップ（図５：F-6）が行われる。
【００９３】
＜APPLICATION_PROGRAM1'＞が完了した後、キュー部２０への処理完了を通知（Ｆ−７）し、それに対応して、キュー部２０のキュー２では、当該の処理部３２２３からのデータ処理完了通知を受付（図４：Q-F-4）、対象データの処理中フラグの削除と、対象データのキュー上からの削除（図４：Q-F-5）を行う。
【００９４】
キュー部２０への処理完了を通知（図５：F-7）した処理部３２２３では、事前に何らかの方法で指定された再起動の基準値を持ち、プロセス内に保有する再起動カウンタの値がその基準値を超えたか、を判断（Ｆ−８）し、越えていなければ、再度、接続先のキュー部２０の選択（図５：F-3）を行う。このとき、先ほどと同じキュー２が選択されれば、同様に＜APPLICATION_PROGRAM1'＞が実行されるが、別のキュー部２０が選択されることもある。
【００９５】
例えば、キュー部２０nのキューｎが選択されれば、＜APPLICATION_PROGRAM2＞が実行される。＜APPLICATION_PROGRAM2＞ではメモリリークの発生リスクに対応した「rebootCountup」は実行されないので、再起動カウンタはカウントアップされない。この再起動カウンタは処理部毎、つまり再起動単位であるプロセス毎に存在する。
【００９６】
先の比較（図５：F-8）において、再起動カウンタが基準値の値を超えていた場合、停止通知を同一マシン上のプロセス管理部３１に通知（F−9）し、処理部３２のプロセスを停止（図５：F-10）する。
【００９７】
この停止に応じて、同一マシン上のプロセス管理部３１の動作を説明する。
【００９８】
プロセス管理部３１は、処理部３２からの停止通知を受信（図７：MA-1）し、現状の処理部３２の数を把握し、管理している処理部３２の数に満たなければ不足分の処理部の数を起動（図７：MA-3）、この処理部の数の監視と不足分の再起動は、処理部３２の停止通知を受信する契機（図７：MA-1）以外にも、定期的に実行される（図７：MA-4、MA-2）。
【００９９】
これら一連の流れによる処理部３２の再起動によって、処理部３２内で発生するメモリリークは効率的に解放されることになる。
【０１００】
また、自動的な再起動だけではなく、運用者による再起動通知や、定期的な再起動発行が必要な場合がある。その場合を以下に説明する。
【０１０１】
マシン上のプロセス管理部３１は、運用者による処理部３２の再起動通知を受信（図６：MM-1）すると、管理下の全処理部３２について把握し（図６：MM-2）、事前に設定された同時再起動数（図６：D‐3）分の処理部３２を選択して、各処理部３２に停止を指示する（図６：MM-3）もしくは、プロセスの強制削除を行い、停止分の処理部３２を再起動（図６：MM-4）し、再起動後の処理部３２からの再起動完了通知を受けて（図６：MM-5）、以上の図６のMM-3〜MM-5の工程を、MM-2で把握した全処理部３２において実施することで、処理部３２内で発生するメモリリークは解放されることになる。
【０１０２】
上述の処理は、プロセス管理部３１についてはマシン毎に、また、処理部３２については処理部３２１１〜３２ｍｋの全てで並行して実行されるため、処理部３２内で発生するメモリリークを解消しながら、同時に、情報源追記クライアント１０１〜１０ｘから入力され続ける処理もいずれかの処理部３２にて実行されており、結果として、サービスを停止することなく、サービス中のプロセス群の中の一部プロセス群の再起動を常態化することにより、メモリリークのあるソフトウェアを使って、継続的なサービスを実現することが可能になる。
【０１０３】
なお、サービス２のように映像に適用した場合に処理部３２が独立に各画面（フレーム）を処理することで、場合によってはフレームの逆転が生じる場合がある。逆転を補正する必要がある場合には、各処理部３２から一度別の結合・整列部プロセスにフレームを送信し、その中で指定時間内データの整列処理を行ってから外部に出力することで対応することになる。
【０１０４】
なお、上記の図３、図８、図９の処理マシンのプロセス管理部３１、処理部３２の動作をプログラムとして構築し、処理マシンとして利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【０１０５】
また、構築されたプログラムをハードディスクや、フレキシブルディスク・ＣＤ−ＲＯＭ等の可搬記憶媒体に格納し、コンピュータにインストールする、または、配布することが可能である。
【０１０６】
なお、本発明は、上記の実施の形態及び実施例に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【産業上の利用可能性】
【０１０７】
本発明では、メモリリークを主に扱ったが、ファイル・ディスクリプタなどプロセス空間の開放によってリセットもしくは解放されるリソースについてもメモリリークと同様に扱うことが可能である。
【符号の説明】
【０１０８】
１０  追記クライアント
２０  キュー部
３０  処理マシン
３１  プロセス管理部
３２  処理部
【図１】
2011054114.tif 000003
【図２】
2011054114.tif 000004
【図３】
2011054114.tif 000005
【図４】
2011054114.tif 000006
【図５】
2011054114.tif 000007
【図６】
2011054114.tif 000008
【図７】
2011054114.tif 000009
【図８】
2011054114.tif 000010
【図９】
2011054114.tif 000011
【図１０】
2011054114.tif 000012