JP6051733B2 - 制御システム、制御方法、及び、制御プログラム - Google Patents

Description

本発明は、制御システム等に関する。

バッチ処理は、所定のタイミングで処理を開始し、その後、所定のデータに対して、繰り返す処理である。分散並列処理は、複数のサーバ（コンピュータ、計算処理装置、情報処理装置、計算処理システム、情報処理システムなどとも表現する。）が大容量のデータを処理する方式である。

コンテキストハッシュ法や分散ハッシュテーブルを利用する方法等は、複数の計算処理ノード（情報処理ノード、以降、「ノード」と表す）を有するコンピュータにおいて、分散してデータを配置する手法である。例えば、コンテキストハッシュ法において、データ配置用のハッシュキーを仮想ノードに割り当てる方法は、分散並列コンピュータにおける任意のノードに、特定のデータを配置する方法である。

マルチタスクオペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ、以降、「ＯＳ」と表す）は、プロセスごとに仮想メモリ空間と物理メモリ空間とを関連付け、上述した２つのメモリ空間におけるアドレス変換、ページングの制御等、メモリを管理する機能（以降、「メモリ管理機能」と表す）を有する。マルチタスクＯＳは、メモリ管理機能を、ＯＳカーネル、および、プロセッサが提供するメモリ管理ユニット（Ｍｅｍｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ、以降「ＭＭＵ」と表す）により実現する。

メモリ管理機能は、プロセスからメモリへのアクセスする要求（以降、「アクセス要求」と略記する）を処理する。メモリ管理機能により、プログラマは、プロセスからメモリへのアクセス先が物理メモリであるか、あるいは、仮想メモリであるかを意識する必要がない。

ガベッジコレクション（Ｇａｒｂａｇｅ_Ｃｏｌｌｅｃｔｉｏｎ、以降、「ガベッジコレクタ」、あるいは、「ＧＣ」と表す）は、メモリリークを抑制する仕組み、あるいは、プログラミング技法である。それゆえ、ＧＣは、プログラマが明示的にメモリ領域を解放する手間を軽減すると共に、プログラマが行うメモリ領域の確保と解放とに関するシステムコールを実行する負荷を軽減する。また、ＧＣは、プロセスが確保したメモリ領域のうち、不要なメモリ領域を判別し、不要と判別したメモリ領域を回収する。それにより、プロセスは、ＧＣが回収したメモリ領域を再利用することが可能になる。その結果、ＧＣは、メモリ領域を確保するシステムコールと、メモリ領域を解放するシステムコールを低減する。

マークアンドスウィープモデルは、ＧＣを実装するモデルの一例である。マークアンドスウィープモデルは、マークフェーズと、スウィープフェーズとから構成される。マークフェーズは、全てのオブジェクトに対して有効な参照からメモリ領域を辿ることができるかをそれぞれチェックし、有効な参照から辿ることができるオブジェクトをマークする、即ち、所定のマークフラグ用メモリ領域を更新する処理である。スウィープフェーズは、マークされていない、即ち、他から有効に参照されない不要なオブジェクトに割り当てられたメモリ領域を解放する処理である。不要なオブジェクトに割り当てられたメモリ領域は、システムに点在する。メモリ管理機能は、システムにおける処理性能を向上させるため、スウィープフェーズ後に断片的にデータが存在するメモリをデフラグすることもある。

ジャバ（以降、「Ｊａｖａ（登録商標）」と表す）やドットネット（以降「．Ｎｅｔ」と表す）等のプログラミング言語において、それを実行する環境、例えば、Ｊａｖａ＿Ｖｉｒｔｕａｌ＿Ｍａｃｈｉｎｅ（以降、「ＪＶＭ」と表す）や．Ｎｅｔ＿Ｆｒａｍｅｗｏｒｋ＿Ｒｕｎｔｉｍｅ等の実行環境は、予めＧＣを実行する機能を有する。例えば、ＪＶＭにおいて、ＧＣは、ヒープメモリを監視する。即ち、ＧＣは、マークアンドスウィープモデルにより、ＪＶＭに割り当てられたヒープメモリにおける不要なメモリ領域を回収する。その後、メモリ管理機能は、断片化した領域をデフラグする。

上述した説明において、メモリ領域を回収することは、必ずしもＪＶＭに割り当てられたメモリ領域をＯＳに返すことを意味しない。メモリ領域を回収することは、例えば、ｍａｌｌｏｃとｆｒｅｅによるメモリ管理モデルにおいて、ｆｒｅｅされたメモリ領域をＯＳに返さずに、次に、ｍａｌｌｏｃ関数が呼び出された場合に、再利用される領域となることを意味する。

上述したようなバッチ処理を、分散並列処理にて実現する方法について説明する。

バッチ処理を実行する日時に関する情報等を定義する制御情報は、予め定められバッチ実行基盤に存在する。バッチ実行基盤は、その制御情報に従い、所定の日時に、バッチ処理を開始する。バッチ実行基盤にてバッチを処理する方法には、上述したような制御情報に従う方法の他に、クライアントがバッチ実行基盤にバッチ処理を開始する指示を方法もある。

図１５を参照しながら分散バッチ実行基盤３０にて行う処理について説明する。図１５は、本発明に関連する分散バッチ実行基盤３０におけるシステムの構成を示すブロック図である。

分散並列システム３２は、分散バッチ実行基盤３０と、分散データストア３１とを有する。分散バッチ実行基盤３０は、１つ以上のジョブを、処理する機能を有する。分散バッチ実行基盤３０は、並行しながら、あるいは、擬似的に並行しながら、複数のジョブを処理する。分散バッチ実行基盤３０を、ネットワークを介して接続する複数のコンピュータに実現することもできる。

分散バッチ実行基盤３０は、バッチ実行管理機構部３４を備えることにより、ローカルノードがジョブを処理する機能（以降、「バッチ実行機能」と表す）を管理するとともに制御する。バッチ実行管理機構部３４は、各ノードにおけるバッチ実行管理機構部３４、構成情報、及び、リソース情報を共有する。バッチ実行管理機構部３４は、ノードが相互に通信することにより、バッチを処理する機能全体を管理するとともに、制御を行う。

ジョブ制御部３５は、分散バッチ実行基盤３０におけるバッチ実行管理機構部３４と通信しながら、ジョブの処理を開始してから、ジョブの処理を終了するまでの間、ジョブを制御する。ジョブ制御部３５は、ジョブリポジトリ３８を有する。ジョブリポジトリ３８は、ジョブを実行する制御と、ジョブを実行した履歴と、ジョブを実行する状態とに関する情報を関連付けて記憶する。

バッチアプリケーションは、１つ以上のジョブ定義と、バッチプログラムとを有する。ジョブ定義は、予め、バッチ処理における処理内容と、処理対象のデータとについて定義する。また、バッチプログラムは、バッチ処理を実行する際の、データ配置計画を定義する。データ配置計画は、分散データストア３１において、データのやり取りにおけるオーバーヘッドを低減するデータを配置する状態について定義する。ジョブ定義は、バッチプログラム、および、データ配置計画を有していても、有していなくても良い。

ジョブ定義は、ジョブと、ジョブにおける一部の処理を表すステップ（Ｓｔｅｐ）とに関する定義、ジョブと該ステップとを実行する順序、ジョブが処理するデータ、該データの所在を示すパス名、該データのフォーマット、該データのプロパティ情報、及び、ジョブと上述したステップとを制御する定義に関する情報を含む。

ジョブ定義は、ジョブと、ステップとを実施する際の前処理、及び、後処理等、ジョブ制御が提供するハンドリングポイントにおいて実行する処理に関する定義を含んでもよい。また、上述したステップに関する定義は、分散バッチ実行機能上で分散並列実行するためのポリシ（処理方法）と、分散並列実行した分割ステップの処理が完了した際の同期に関するポリシ（処理方法）とに関する情報を含んでもよい。また、ジョブ定義は、上述した項目を必ずしも含んでいなくとも良い。

バッチ実行管理機構部３４は、管理インターフェース３６を介して、バッチアプリケーションを複数の分散バッチ実行基盤３０に配置する。アプリケーション管理部３３は、バッチ実行管理機構部３４が配置したバッチアプリケーションを、アプリケーションリポジトリ３７に格納するとともに管理する。アプリケーションリポジトリ３７は、バッチアプリケーションと、該バッチアプリケーションに関する管理情報（いつ、だれが、どのバッチアプリケーションを、どのような設定で配置するかという記録等を関連付けて記憶する）とを有する。アプリケーションリポジトリ３７には、異なるバッチアプリケーションが複数存在しても良い。

さらに、アプリケーション管理部３３は、バッチアプリケーションを解析する機構と、妥当性を検証する機構を備えることもできる。

ジョブは、分散バッチ実行基盤３０においてバッチアプリケーションを実行可能なバッチ処理プログラムである。ジョブは、該処理において、上述したようなステップを含む。ジョブは、ステップとして、単独の処理だけではなく、複数の処理を含んでも良い。

次に、分散データストアを実現する方法について説明する。

ジョブにおけるステップは、分散データストア３１における入出力インターフェースを介して、分散データストア３１が有するデータを、読み込み、書き込み、更新、削除などに関する処理を定義する。

分散データストア３１は、通信ネットワーク（以降、「ネットワーク」と表す）を介して接続する複数のコンピュータにおける１つ以上のデータストアを含む。分散データストア３１におけるデータは、メタデータと関連付けされている。該メタデータは、データにアクセスするのに必要なキー情報、データを格納する格納先に関する情報、及び、データを利用する状況を表すアクセス情報等を有する。分散データストア３１を構成する１つ以上のノードは、メタデータを共有する。クライアントは、入出力インターフェースを介して、データを記憶するノードを意識することなく、ローカルノード、あるいは、リモートノードにおけるデータをアクセスする。

データ管理部３９は、ローカルノードにおける分散データストア３１が記憶するデータと関連付けされたメタデータを管理する。図１６を参照しながら、データ管理部３９がメタデータを管理する処理について説明する。図１６は、本発明に関連するデータ管理部３９が管理するメタデータの一例を概念的に表す図である。メタデータは、該メタデータが表すデータと、配置に関する情報と、アクセスに関する情報とを関連付けする。

配置に関する情報は、データを持つマスターノードと、該データのコピーを持つコピーノードとに関する情報を有する。アクセス情報は、優先度を表す「ｐｒｉｏｒｉｔｙ」と、回数を表す「ｃｏｕｎｔ」と、計算時間の長さを表す「ｔｉｍｅ」とに関する情報を有する。例えば、ノード「２」は、「Ｙ」が表すデータを有し、ノード「１」は、該データのコピーを有する。該データの優先度は「Ｍｉｄ．」であり、該データは１００回参照され、該データにおける計算時間は、「ｌｏｎｇ」である。

データ管理部３９は、リモートノードにおけるデータ管理部３９と協調（連動）する。クライアントは、データ管理部３９が協調しながら処理を行うことにより、分散データストアの入出力インターフェースを介して、データが実際に存在するノードを意識することなく、データにアクセスすることができる。例えば、データ管理部３９は、Ｊａｖａ＿Ｖｉｒｔｕａｌ＿Ｍａｃｈｉｎｅ（以降、「ＪＶＭ」と表す）において動作する。

次に、分散データストア３１について説明する。分散データストア３１は、データの生成、読み込み、更新、削除が行えるデータの保持先であり、即ち、バッチ処理にて処理する対象データを記憶する。該対象データを記憶する格納先は、例えばハードディスクやメモリ（主記憶装置、メインメモリ）等、ローカルのコンピュータリソース、あるいは、ファイルシステム、データベース、オンメモリ型データストア等のデータ管理ソフトウェアとネットワークを介して利用可能なリモートのコンピュータリソースである。上述した格納先に関わらず、クライアントは、データが存在する格納先を意識せずに、透過的に格納先を利用することができる。以降、分散データストア３１は、１つの計算処理システムにおいて実現されるデータストアも含むものとする。

オンメモリ型データストアは、データの格納先がメモリ等のデータストアを表し、ディスク型データストアは、データの格納先がハードディスクディスク等のデータストアを表す。オンメモリ型データストアにおけるデータ処理は、ディスク型データストアよりも、データの生成、読み込み、更新、削除がより高速に行うことが可能である。

さらに、分散データストア３１は、ネットワークを介して、複数台のコンピュータに存在するデータストアが協調動作することにより、クライアントからは単一のデータストアであるかのように振舞うデータストアを表す。

特許文献１が開示するシステムは、ジョブ特性と入力データの件数から、そのジョブの実行にかかる時間を予測し、その時間の範囲全体で各実行サーバの負荷状況を予測し、それにもとづいてジョブを実行させる実行サーバを選択する。該システムは、上述した処理により、複数の実行サーバにおいて、ジョブの実行に要する時間を短縮する。

特許文献２が開示するＧＣ方式は、ポインタが指し示すデータの状況を判断することにより、ループを形成する参照関係にある不要なメモリ領域を回収する。

特許文献３が開示するデバイスは、ＧＣにおいて、メモリ使用状況を表すプロファイルを生成し、該プロファイルからメモリ領域が不足する可能性を予測する。

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

ＧＣは、特定のプロセスがメモリ領域を参照する予定があるとしても、プロセスが参照していないと判断する場合には、該メモリ領域を回収する。そのため、プロセスが該メモリ領域におけるデータを処理する場合に、メモリ管理機能は、再び、ディスクから該メモリ領域にデータを読み込む。プロセスとＧＣとの間において競合が発生するため、システムの処理性能は、劣化する。

図１７と図１８とを参照しながら、プロセスとＧＣとの間において競合が発生することに起因する性能劣化の例について説明する。図１７は、本発明に関連する分散データストアが有するデータの一例を概念的に表す図である。図１８は、本発明に関連するジョブに関する定義の一例を概念的に表す図である。

分散データストアは、処理すべきデータ（以降、「処理データ」と表す）を有する。
図１７において、処理データは、Ａ、Ｂ、Ｃ、Ｖ、Ｗ、Ｘ、Ｙ、及び、Ｚである。各ノードは、入出力インターフェースを介して、処理データを保持する。

また、分散システムは、１つのデータを、複数のノードにおいて重複して保持することもできる。その場合、分散システムは、あるノードにおいて障害が発生する場合でも、リモートノードが保持するデータから、自ノードにデータを復元する。この例において、分散システムは、１つのデータに対して、１つの複製データを保持する。

図１７において、データ（Ａ）は、処理データＡの複製であることを表す。即ち、Ｎｏｄｅ−３（ノード−３）におけるディスク型データストアは、処理データＡの複製と、処理データＢの複製とを記憶する。以下の説明においては、オリジナルのデータ（例えば、データセットＡ）をマスターデータと表し、複製したデータ（例えば、データセット（Ａ））を複製データと表すこともある。

データセットＡ、Ｂ、Ｃは、バッチ処理の処理対象データであり、それぞれのデータ間に依存関係が無いとする。例えば、データセットＡ、Ｂ、Ｃは、店舗エリアＡ、店舗エリアＢ、店舗エリアＣにおける商品の取引データである。以下の説明において、データセットＡ、Ｂ、及び、Ｃが、データセットＸ、Ｙ、及び、Ｚに依存するとする。例えば、データセットＡがデータセットＸに依存し、データセットＢがデータセットＸ、及び、Ｙに依存し、データセットＣがデータセットＸ、Ｙ、及び、Ｚに依存するとする
データセットＡ、Ｂ、Ｃのデータサイズは、それぞれ、図１７におけるＮｏｄｅ−１乃至Ｎｏｄｅ−３のオンメモリ型データストアが確保可能なメモリサイズを総和した値よりも極めて大きいとする。ただし、データセットＡ、Ｂ、及び、Ｃのデータサイズは、ディスク型データストアが確保可能なディスク容量の総和よりは十分に小さいとする。

データセットＸ、Ｙ、及び、Ｚは、それぞれのデータ間に依存性が無いとする。例えば、データセットＸ、Ｙ、及び、Ｚは、商品マスターデータのデータセットである。

さらに、データセットＸ、Ｙ、Ｚ、Ｖ、及び、Ｗのデータサイズを総和したサイズは、Ｎｏｄｅ−１乃至Ｎｏｄｅ−３におけるオンメモリ型データストアが確保可能なメモリサイズの総和よりも大きく、かつ、全てのデータは、オンメモリ型データストアに配置できないとする。さらに、本例では、データセットＸとＹとを合わせたデータサイズは、各ノードにおける各々のオンメモリ型データストアが格納可能な上限サイズであるとする。

図１７を参照すると、オンメモリ型データストア（図１７における「メモリ」の列にある値が記憶するデータを表す）は、データセットＸ、Ｙを有し、ディスク型データストア（図１７における「ディスク」の列にある値が記憶するデータを表す）は、データセットＺ、Ｖ、Ｗを有する。

ジョブ制御は、図１８に示すｊｏｂ１のジョブ定義に基づき、ｊｏｂ１に含まれるｓｔｅｐ１（図１８におけるｓｔｅｐ１−１と、ｓｔｅｐ１−２と、ｓｔｅｐ１−３とを合わせた処理と等価）の処理をＮｏｄｅ−１と、Ｎｏｄｅ−２と、Ｎｏｄｅ−３とに振り分ける。ジョブ制御は、分散データストアが保持するデータの配置情報を参照することにより、可能な限り処理対象のデータが存在するノードに、分割する処理を割り当てる。

図１７を参照すると、例えば、処理データセット（以降、単に「データセット」と表す）ＡのマスターデータがＮｏｄｅ−２に存在するため、Ｎｏｄｅ−２は、ｓｔｅｐ１−２が処理を開始する。Ｎｏｄｅ−１は、データセットＢのマスターデータを有するため、ｓｔｅｐ１−１を処理する。Ｎｏｄｅ−２は、データセットＣのマスターデータを有する一方で、Ｎｏｄｅ−１は、データセットＣの複製（コピー）データを有する。しかしながら、Ｎｏｄｅ−１は、ｓｔｅｐ１−１を処理し、Ｎｏｄｅ−２は、ｓｔｅｐ１−２を処理する。負荷分散のため、Ｎｏｄｅ−３は、残りのｓｔｅｐ１−３を処理する。

しかしながら、Ｎｏｄｅ−３は、分散データストアにデータセットＣを持たないため、マスターデータを有するＮｏｄｅ−２から、ネットワークを介して、データセットＣをコピーする。

Ｎｏｄｅ−２は、ｓｔｅｐ１−２において、ディスク型データストアからデータセットＡを読み取る。次に、Ｎｏｄｅ−２は、データセットＡがデータセットＸに依存するため、読み込んだデータセットＡと、Ｎｏｄｅ−２のオンメモリ型データストアにおけるデータセットＸとを結合し、結合したデータを処理する。

Ｎｏｄｅ−１は、ｓｔｅｐ１−１において、Ｎｏｄｅ−１のディスク型データストアからデータセットＢを読み取る。次に、Ｎｏｄｅ−１は、ｓｔｅｐ１−１において、データセットＢがデータセットＸとＹとに依存するため、読み込んだデータセットＡと、Ｎｏｄｅ−１のオンメモリ型データストアにおけるデータセットＸ、Ｙとを結合し、結合したデータを処理する。しかしながら、Ｎｏｄｅ−１におけるオンメモリ型データストアは、データセットＹを有さないため、ネットワークを介して、Ｎｏｄｅ−３にあるデータセットＹを参照する。

Ｎｏｄｅ−３は、ｓｔｅｐ１−３において、Ｎｏｄｅ−３のディスク型データストアからデータセットＣをと読み取る。次に、Ｎｏｄｅ−３は、ｓｔｅｐ１−３において、データセットＣがデータセットＸ、Ｙ、及び、Ｚに依存するため、読み取ったデータセットＣと、Ｎｏｄｅ−３のオンメモリ型データストアが有するデータセットＸ、Ｙ、及び、Ｚとの結合処理を行う。しかしながら、Ｎｏｄｅ−３におけるオンメモリ型データストアは、データセットＺを有さない。

そのため、Ｎｏｄｅ−３は、ｓｔｅｐ１−３において、データセットＺに含まれるデータに対するアクセスが発生するたびに、Ｎｏｄｅ−３のディスク型データストアからデータを読み込む。そのため、Ｎｏｄｅ−３は、ｓｔｅｐ１−３において処理性能が劣化し、その結果、ｊｏｂ１全体の処理性能も劣化する。

さらに、Ｎｏｄｅ−３は、データセットＺの全てを、オンメモリ型データストアに保持できない。加えて、Ｎｏｄｅ−３は、オンメモリ型データストアに、データセットＸおよびＹを既に有する。そのため、Ｎｏｄｅ−３のオンメモリ型データストアは、データセットＺを記憶する空き容量を持たない。その結果、Ｎｏｄｅ−３は、データセットＺを、空き容量が存在するＮｏｄｅ−１のオンメモリ型データストアに格納する。

データ管理部は、データセットＹ、または、Ｚに含まれるデータの中で、参照時刻が最も古いデータを、ディスク型データストアにパージする。しかしながら、該データを処理するノードは、パージされたデータを読み込むこともある。その処理は、追加的にディスクに対する入出力を伴うため、ｓｔｅｐ１−３およびｊｏｂ１の処理性能は、劣化する。

上述した説明においては、分散データストアを実現する方法として、各ノードは、１つのハッシュキーに関連付けされている。しかしながら、コンテキストハッシュ法における分散ハッシュテーブルによって、複数のノードが、１つのハッシュキーを共有することもある。

そこで、本発明の主たる目的は、処理性能の劣化を低減する制御システム等を提供することである。

前述の目的を達成するために、本発明に係る制御システムは、以下の構成を備えることを特徴とする。

即ち、本発明に係る制御システムは、
ジョブが参照する参照データと、記憶装置において回収される領域における第１データとが一致する場合に該第１データを前記記憶装置に読む第１命令を行い、一致しない場合には前記第１命令を行わないという実施判断を行う命令部を
備えることを特徴とする。

また、本発明の他の見地として、本発明に係る制御方法は、
ジョブが参照する参照データと、記憶装置において回収される領域における第１データとが一致する場合に該第１データを前記記憶装置に読む第１命令を行い、一致しない場合には前記第１命令を行わないことを特徴とする。

本発明に係る制御システム等によれば、処理性能の劣化を低減することできる。

次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。

＜第１の実施形態＞
本発明の第１の実施形態に係る制御システム１が有する構成と、制御システム１が行う処理とについて、図１と図２とを参照しながら詳細に説明する。図１は、本発明の第１の実施形態に係る制御システム１の構成を示すブロック図である。図２は、本発明の第１の実施形態に係る制御システム１における処理の流れを示すフローチャートである。

図１を参照すると、第１の実施形態に係る制御システム１は、参照データと第１データとの比較結果に応じて読み込み命令を発する命令部２を有する。計算処理システム（情報処理システム）６は、制御システム１と、ガベッジコレクタ３と、メモリ４（記憶装置、メインメモリ、オンメモリ型データストア）を有する。

ガベッジコレクタ３は、背景技術にて説明したように、マークアンドスウィープモデル等の処理方法によって、メモリ４において、不要なオブジェクトに割り当てられたメモリ領域を決定する。次に、メモリ管理部５は、ガベッジコレクタ３が決定したメモリ領域を回収（パージ、ガベッジコレクト、ガベッジコレクション、ＧＣ）する。

命令部２は、計算処理システム６が処理しているジョブ、計算処理システム６が将来処理するジョブ、あるいは、その両者が、参照するデータ（以降、これらのデータを総称して「参照データ」と表す）と、ガベッジコレクタ３がパージすると決定したメモリ４における第１データとを比較する（ステップＳ３）。命令部２は、第１データと参照データとが一致すると判断する場合（ステップＳ３にてＹＥＳと判断）、該第１データをメモリ４に読み込むことを命じる（ステップＳ４）。命令部２は、第１データと参照データとが一致しないと判断する場合（ステップＳ３にてＮＯと判断）、メモリ４に読み込む命令を行わない。

上述した説明において、処理しているジョブ、あるいは、将来実行するジョブの特定する機能は、例えば、図３に示すジョブスケジュールと、図４Ａと図４Ｂとに示すジョブ実行状態とを参照することなどにより実現できる。

図３を参照しながら、本発明の第１の実施形態における参照データを特定するデータの一例となるジョブスケジュールについて説明する。図３は、本発明の第１の実施形態における参照データを特定する元となるデータの一例を概念的に示す図である。ジョブスケジュールは、ジョブを実行するための所定のスケジュールに関する情報（以降、「所定のスケジュール情報」と表す）である。所定のスケジュール情報は、ジョブを実行する日時（図３における「実行日」と「時刻」）と、ジョブ識別子（以降、「ＩＤ」と表す）と、ジョブを処理するのに必要なパラメタと、ジョブに関する制約条件と、ジョブを処理する実行先と、ジョブを実行する優先度等とを関連付けする。

背景技術にて説明した分散バッチ実行機能は、あるジョブ識別子を有するジョブを、ジョブスケジュールにおいて該ジョブ識別子と関連付けされた日時、実行先、制約条件、優先度等の諸条件を満たす場合に、該ジョブを実行する。例えば、図３において、分散バッチ実行機能は、「ｊｏｂ１」というジョブＩＤを有するジョブを、ＹＹＹＹ／ＭＭ／ＤＤという日の２２：００：０００という時刻に、パラメタをＡ，Ｂ、Ｃとして、Ｅｎｄｏｆｔｉｍｅという制約条件の下で、Ｎｏｒｍａｌという優先度において、ＪＪという実行先にて実行を開始する。

ジョブスケジュールは、上述した値を必ずしも全て含んでいる必要はなく、また、他の値を含んでいても良い。例えば、命令部２は、将来実行するジョブと、該ジョブに関連付けされたパラメタとを読み取ることにより、一部の参照データを読み取る。命令部２が参照データを得る方法は、上述した方法には限定されない。

命令部２は、例えば、図４Ａと図４Ｂとに示すジョブ実行状態表を読み取ることにより、ジョブの状態を判断できる。図４Ａと図４Ｂとを参照しながら、本発明の第１の実施形態における参照データを特定する元となるデータの一例となるジョブ実行状態表について説明する。図４Ａと図４Ｂとは、本発明の第１の実施形態における参照データを特定する元となるデータの一例を概念的に示す図である。

ジョブ実行状態表は、各ジョブの状態と、各ジョブにおける各ステップの状態との２つの状態について表す。図４Ａを参照すると、ジョブ実行状態表は、ジョブ識別子と、ジョブを実行する実行先と、ジョブの状態とを関連付けする。図４Ｂを参照すると、各ジョブにおける各ステップの状態は、ジョブＩＤと、ステップＩＤと、ジョブを実行する実行先と、ジョブの状態と、ジョブの実行先と、ジョブにおける処理済みの件数とを関連付けする。例えば、命令部２は、ジョブＩＤと関連付けされたジョブの状態を読み取ることにより、ジョブの状態を判断する。ジョブ実行状態表は、上述した値を必ずしも全て含んでいる必要はなく、また、他の値を含んでいても良い。

また、上述した説明において、命令部２は、ガベッジコレクタ３が回収したメモリ領域を参照することにより、処理を行うとしたが、ガベッジコレクタ３が、ＧＣを実施することについて通知する通知部（図１において不図示）を有していても良い。例えば、通知部が、ガベッジコレクションにおけるマークフェーズにて通知するとしても良い。その場合、命令部２が、ステップＳ３にてＮＯと判断する場合に、ＧＣを実施する命令を発し、ステップＳ３にてＹＥＳと判断する場合に、当該ＧＣを実施しないことによっても、上述した機能を実現することができる。通知部により、さらに、ディスクからメモリに読み込む処理を、減らすことができる。

上述した説明において、本発明の第１の実施形態に係る制御システム１の動作を、ガベッジコレクタ３を有する計算処理システム６の例を使って説明したが、例えば、制御システム１をオンメモリ型データストアに適用しても良い。その場合、命令部２は、分散バッチ実行基盤が処理しているジョブ、分散バッチ実行基盤が将来処理するジョブ、あるいは、その両者が、参照するデータと、オンメモリ型データストアにおいて、ディスク型データストアにパージされる領域における第１データとを比較する（ステップＳ３に相当）。

命令部２は、第１データと参照データとが一致すると判断する場合（ステップＳ３にてＹＥＳと判断することに相当）、該第１データをオンメモリ型データストアに読み込むことを命じる（ステップＳ４に相当）。命令部２は、第１データと参照データとが一致しないと判断する場合（ステップＳ３にてＮＯと判断することに相当）、オンメモリ型データストアに読み込む命令を行わない。

特許文献２、あるいは、特許文献３が開示するシステムは、ジョブの参照データに関係なく、実行しているジョブが参照していないメモリ領域を回収する。そのため、当該システムは、ジョブが後処理において参照するメモリ領域であっても、参照されていない場合に、該メモリ領域を回収する。その場合、当該システムは、ジョブを処理するために、ディスクなどの処理速度の低い記憶媒体から、再度、メモリ４にデータを読み込む。その結果、特許文献２あるいは特許文献３が開示するシステムによれば、ジョブの処理性能は劣化する。

一方、本発明における第１の実施形態に係る制御システム１は、ジョブの参照データを参照することにより、ジョブを処理するのに必要なデータを、あらかじめ、メモリ４に読み込む。その結果、本発明における第１の実施形態に係る制御システム１によれば、データをメモリ４に読むことに起因する、ジョブ処理性能の劣化を低減することができる。

即ち、本発明における第１の実施形態に係る制御システムによれば、処理性能の劣化を低減することができる。

＜第２の実施形態＞
次に、上述した第１の実施形態を基本とする第２の実施形態について説明する。

以下の説明においては、本実施形態に係る特徴的な部分を中心に説明すると共に、上述した第１の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明を省略する。

図５と図６とを参照しながら、本発明の第２の実施形態に係る制御システム７が有する構成と、制御システム７が行う処理とについて説明する。図５は、発明の第２の実施形態に係る制御システム７の構成を示すブロック図である。図６は、本発明の第２の実施形態に係る制御システム７における処理の流れを示すフローチャートである。

図５を参照すると、制御システム７は、命令部８と記憶部９とを有する。計算処理システム１０は、制御システム７を有する。記憶部９は、ジョブと、該ジョブが参照する参照データとを関連付けして記憶する。図７を参照しながら、記憶部９が関連付けして記憶するデータの一例について説明する。図７は、本発明の第２の実施形態に係る記憶部９におけるデータの一例を概念的に示す図である。図７を参照すると、記憶部９は、ジョブを一意に表すジョブ識別子（以降、「ジョブＩＤ」と表す）と、該ジョブＩＤと関連付いた参照データとを関連付けて記憶する。例えば、図７において、ジョブＩＤが「１」のジョブは、参照データＡと関連付けされているため、該ジョブは、参照データＡを参照する。

以降の説明において、ジョブは、計算処理システムが処理を行っているジョブ、あるいは、計算処理システムが処理を行う予定のジョブ、あるいは、その両者を表す。命令部８は、記憶部９から、ジョブと関連付いた特定の参照データを読み取る（ステップＳ２）。次に、命令部８は、本発明の第１の実施形態にて説明したような、ステップＳ３とステップＳ４との処理を行う。

上述した説明において、命令部８は、記憶部９から、図７に示すようなデータを読み取るとしたが、例えば、図８に示すような、ジョブを実行した履歴データ（以降、「ジョブ実行履歴」と表す）から読み取ることもできる。

図８を参照しながら、ジョブ実行履歴について説明する。図８は、本発明の第２の実施形態に係る記憶部におけるジョブ実行履歴の一例を概念的に示す図である。ジョブ実行履歴は、ジョブＩＤと、ステップＩＤと、該ジョブを実行するのに必要なパラメタと、ジョブを処理した実行先と、該ジョブを処理することにより得られる結果等とを関連付けする。ジョブ実行履歴は、該ジョブを開始した日時と、該ジョブの処理を終了した日時等、上述した項目以外の項目と関連付けされていても良い。

例えば、図８の２行目は、Ｎｏｄｅ−１というノードが、「１」のジョブのｓｔｅｐ１−１を、Ａを参照することにより処理し、該処理結果がＯＫであるという状況を表す。即ち、図８における例において、「１」のジョブは、Ａというデータと関連付けされている。

本発明の第２の実施形態は、本発明の第１の実施形態と同様の構成を有するため、本発明の第２の実施形態は、本発明の第１の実施形態と同様の効果を享受することができる。さらに、本発明の第２の実施形態によれば、記憶部９からジョブと関連付いた特定の参照データを読み取ることにより、外部のデータを参照する回数を減らすことができる。

即ち、本発明における第２の実施形態に係る制御システムによれば、処理性能の劣化を低減することができる。

＜第３の実施形態＞
次に、上述した第２の実施形態を基本とする第３の実施形態について説明する。

以下の説明においては、本実施形態に係る特徴的な部分を中心に説明すると共に、上述した第２の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明を省略する。

図９と図１０とを参照しながら、本発明の第３の実施形態に係る制御システム１１が有する構成と、制御システム１１が行う処理とについて説明する。図９は、発明の第３の実施形態に係る制御システム１１の構成を示すブロック図である。図１０は、本発明の第３の実施形態に係る制御システム１１における処理の流れを示すフローチャートである。

図９を参照すると、制御システム１１は、命令部１２と、記憶部１３と、解析部１４とを有する。計算処理システム１５は、制御システム１１と、ガベッジコレクタ３と、メモリ４と、メモリ管理部５とを有する。解析部１４は、回収されるメモリ領域（メモリ４における一部の領域）が記憶するデータを、所定の解析手順により解析することにより、第１データを特定する。

解析部１４は、回収されるメモリ領域が記憶するデータを、所定の解析手順により解析することにより、第１データを特定する（ステップＳ１）。次に、命令部１２は、記憶部１３から、ジョブと関連付いた特定の参照データを読み取る（ステップＳ２）。あるいは、解析部１４は、命令部１２が行うステップＳ２における処理の後に、ステップＳ１における処理を行っても良く、また、それらの処理を、並行して、あるいは、擬似的に並行して行っても良い。次に、命令部１２は、計算処理システム１５が処理しているジョブ、計算処理システム１５が将来処理するジョブ、あるいは、その両者が参照するデータ（以降、これらのデータを総称して「参照データ」と表す）と、ガベッジコレクタ３がパージすると決定したメモリ領域（上述の、「回収されるメモリ領域」）に存在する第１データとを比較する（ステップＳ３）。

所定の解析手順には、例えば、記憶するデータがＪａｖａオブジェクトであれば、解析部１４は、バイト配列を解析することにより、Ｊａｖａオブジェクトを取り出す方法がある。その場合、解析部１４は、取り出したＪａｖａオブジェクト解析することによって、データがメタデータであることを判別する。解析部１４は、該メタデータのオブジェクトを第１データとする。

本発明の第３の実施形態は、本発明の第２の実施形態と同様の構成を有するため、本発明の第３の実施形態は、本発明の第２の実施形態と同様の効果を享受することができる。さらに、本発明の第３の実施形態によれば、解析部１４は、回収されるメモリ領域が記憶するデータを、所定の解析手順により解析するため、一層、効果的に処理を行うことができる。

即ち、本発明における第３の実施形態に係る制御システムによれば、処理性能の劣化を低減することができる。

＜第４の実施形態＞
次に、上述した第２の実施形態を基本とする第４の実施形態について説明する。

以下の説明においては、本実施形態に係る特徴的な部分を中心に説明すると共に、上述した第２の実施形態と同様な構成については、同一の参照番号を付すことにより、重複する説明を省略する。

図１１と図１２とを参照しながら、本発明の第４の実施形態に係る制御システム１６が有する構成と、制御システム１６が行う処理とについて説明する。図１１は、本発明の第４の実施形態に係る制御システム１６の構成を示すブロック図である。図１２は、本発明の第４の実施形態に係る制御システム１６における処理の流れを示すフローチャートである。

図１１を参照すると、制御システム１６は、メモリ領域（メモリ４における一部の記憶領域）の割り当てを論理的に変更することにより、ＧＣにおいて回収されるメモリ領域を管理する管理部１７を更に有する。計算処理システム１８は、制御システム１６と、ガベッジコレクタ３と、メモリ４と、メモリ管理部５とを有する。

管理部１７は、ＧＣにおいて回収されるメモリ領域を参照することにより、該メモリ領域を解析する（ステップＳ５）。次に、管理部１７は、解析した結果を表すデータを作成する（ステップＳ６）。解析した結果を表すデータの一例として、バイト配列を挙げることができる。次に、管理部１７は、ＧＣにおいて回収されるメモリ領域への論理的な割り当てを変更することにより、当該メモリ領域を管理する（ステップＳ７）。

図１３を参照しながら、ステップＳ７における処理について説明する。図１３は、本発明の第４の実施形態に係る管理部１７における処理の概念図である。図１３における矢印は、メモリ空間における参照関係を表す。図１３を参照すると、例えば、ＧＣにより、あるプロセスが参照する物理的なメモリ領域（図１３における点線の矢印）は、回収される。該物理的なメモリ領域は、上述したような分散処理環境におけるデータストアにより実現されていても良い（以降、データストアを含めて、「物理的なメモリ領域」と表す）。管理部１７は、その物理的なメモリ領域への論理的な割り当てを変更する（図１３における実線の矢印）ことにより、当該物理的なメモリ領域を管理する。

上述した、管理部１７がＧＣにより物理的なメモリ領域を管理する場合であっても、物理的なメモリ領域におけるデータは変化しない。本発明の第４の実施形態に係る管理部１７によれば、データ通信を実施しないため、極めて低コストに、ＧＣ対象におけるメモリに存在するデータを参照することができる。

本発明の第４の実施形態は、本発明の第３の実施形態と同様の構成を有するため、本発明の第４の実施形態は、本発明の第３の実施形態と同様の効果を享受することができる。

即ち、本発明における第４の実施形態に係る制御システムによれば、処理性能の劣化を低減することができる。

（ハードウェア構成例）
上述した本発明の各実施形態における制御システムを、１つの計算処理装置（情報処理装置、コンピュータ）を用いて実現するハードウェア資源の構成例について説明する。但し、係る制御システムは、物理的または機能的に少なくとも２つの計算処理装置を用いて実現してもよい。また、係る制御システムは、専用の装置として実現してもよい。

図１４は、本発明の第１の実施形態乃至本発明の第４の実施形態に係る計算検索装置を実現可能な計算処理装置のハードウェア構成を概略的に示す図である。計算処理装置２０は、中央処理演算装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、以降「ＣＰＵ」と表す）２１、メモリ２２、ディスク２３、不揮発性記録媒体２４、入力装置２５、および、出力装置２６を有する
不揮発性記録媒体２４は、コンピュータが読み取り可能な、例えば、コンパクトディスク（Ｃｏｍｐａｃｔ Ｄｉｓｃ）、デジタルバーサタイルディスク（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ブルーレイディスク（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）、ユニバーサルシリアルバスメモリ（ＵＳＢメモリ）などを指しており、電源を供給しなくても係るプログラムを保持し、持ち運びを可能にする。不揮発性記録媒体２４は、上述した媒体に限定されない。また、不揮発性記録媒体２４の代わりに、通信ネットワークを介して係るプログラムを持ち運びしても良い。

即ち、ＣＰＵ２１は、ディスク２３が記憶するソフトウェア・プログラム（コンピュータ・プログラム：以下、単に「プログラム」と称する）を、実行する際にメモリ２２にコピーし、演算処理を実行する。ＣＰＵ２１は、プログラム実行に必要なデータをメモリ２２から読み込む。表示が必要な場合には、ＣＰＵ２１は、出力装置２６に出力結果を表示する。外部からプログラムを入力する場合、ＣＰＵ２１は、入力装置２５からプログラムを読み取る。ＣＰＵ２１は、メモリ２２にある制御プログラム（図２、図６、図１０、図１２）を解釈し実行する。ＣＰＵ２１は、上述した本発明の各実施形態において説明した処理を順次行う。

即ち、このような場合、本発明は、係る制御プログラムによっても成し得ると捉えることができる。更に、係る制御プログラムが記録されたコンピュータ読み取り可能な記録媒体によっても、本発明は成し得ると捉えることができる。

本発明の第１の実施形態に係る制御システムの構成を示すブロック図である。 本発明の第１の実施形態に係る制御システムにおける処理の流れを示すフローチャートである。 本発明の第１の実施形態における参照データを特定する元となるデータの一例を概念的に示す図である。 本発明の第１の実施形態における参照データを特定する元となるデータの一例を概念的に示す図である。 本発明の第１の実施形態における参照データを特定する元となるデータの一例を概念的に示す図である。 本発明の第２の実施形態に係る制御システムの構成を示すブロック図である。 本発明の第２の実施形態に係る制御システムにおける処理の流れを示すフローチャートである。 本発明の第２の実施形態に係る記憶部におけるデータの一例を概念的に示す図である。 本発明の第２の実施形態に係る記憶部におけるジョブ実行履歴の一例を概念的に示す図である。 本発明の第３の実施形態に係る制御システムの構成を示すブロック図である。 本発明の第３の実施形態に係る制御システムにおける処理の流れを示すフローチャートである。 本発明の第４の実施形態に係る制御システムの構成を示すブロック図である。 本発明の第４の実施形態に係る制御システムにおける処理の流れを示すフローチャートである。 本発明の第４の実施形態に係る管理部における処理の概念図である。 本発明の各実施形態に係る制御システムを実現可能な計算処理装置のハードウェア構成を、概略的に示すブロック図である。 本発明に関連する分散バッチ実行基盤におけるシステムの構成を示すブロック図である。 本発明に関連するデータ管理部が管理するメタデータの一例を概念的に表す図である。 本発明に関連する分散データストアが有するデータの一例を概念的に表す図である。 本発明に関連するジョブに関する定義の一例を概念的に表す図である。

１ 制御システム
２ 命令部
３ ガベッジコレクタ
４ メモリ
５ メモリ管理部
６ 計算処理システム
７ 制御システム
８ 命令部
９ 記憶部
１０ 計算処理システム
１１ 制御システム
１２ 命令部
１３ 記憶部
１４ 解析部
１５ 計算処理システム
１６ 制御システム
１７ 管理部
１８ 計算処理システム
２０ 計算処理装置
２１ ＣＰＵ
２２ メモリ
２３ ディスク
２４ 不揮発性記録媒体
２５ 入力装置
２６ 出力装置
３０ 分散バッチ実行基盤
３１ 分散データストア
３２ 分散並列システム
３３ アプリケーション管理部
３４ バッチ実行管理機構部
３５ ジョブ制御部
３６ 管理インターフェース
３７ アプリケーションリポジトリ
３８ ジョブリポジトリ
３９ データ管理部

Claims (10)

1. ジョブが参照する参照データと、記憶装置において回収される領域における第１データとが一致する場合に該第１データを前記記憶装置に読む第１命令を行い、一致しない場合には前記第１命令を行わないという実施判断を行う命令部を
   備える制御システム。
2. 前記ジョブと、前記ジョブが参照する参照データとを関連付けて記憶する記憶部を更に備え、
   前記命令部は、前記記憶部から、前記ジョブと関連付けされた特定の参照データ読み取ることにより、前記実施判断を行う
   請求項１に記載の制御システム。
3. 前記領域における第２データを所定の解析手順により解析することにより、前記第１データを特定する解析部を更に備える
   請求項１または請求項２に記載の制御システム。
4. 前記領域を管理する管理部を更に備え、
   前記解析部は、前記管理部が管理する前記領域を参照することにより、前記第２データを読み取る、
   請求項３に記載の制御システム。
5. 前記記憶装置は、オンメモリ型データストアである
   請求項１乃至請求項４のいずれか１項に記載の制御システム。
6. 前記解析部は、前記所定の解析手順において、バイト配列を解析することによりＪａｖａオブジェクトを取り出し、該Ｊａｖａオブジェクトにおけるメタデータを判別する、
   請求項３または請求項４に記載の制御システム。
7. ジョブが参照する参照データと、記憶装置において回収される領域における第１データとが一致する場合に該第１データを前記記憶装置に読む第１命令を行い、一致しない場合には前記第１命令を行わない制御方法。
8. ジョブが参照する参照データと、記憶装置において回収される領域における第１データとが一致する場合に該第１データを前記記憶装置に読む第１命令を行い、一致しない場合には前記第１命令を行わないという実施判断を行う命令機能を
   コンピュータに実現させる制御プログラム。
9. 前記命令機能は、前記ジョブと、前記ジョブが参照する参照データとを関連付けて記憶する記憶部から、前記ジョブと関連付けされた特定の参照データ読み取ることにより、前記実施判断を行う
   請求項８に記載の制御プログラム。
10. 前記領域における第２データを所定の解析手順により解析することにより、前記第１データを特定する解析機能を、
    さらにコンピュータに実現させる請求項８、または、請求項９に記載の制御プログラム。

Images