(57)【要約】  ソフトウェアモジュール１４３が使用するリソース量を個別に制限し、各ソフトウェアモジュールの最大リソース使用量の総和がシステム全体リソース量より小さくなるシステムにおけるリソース管理方法であって、新たにソフトウェアモジュールをインストールまたは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりソフトウェアモジュールが安定動作していると判断するステップ４０６と、実行履歴から実リソース使用最大値を総和に含めて、インストールまたは実行可否を判断するステップ４０７とを有する。
2010050335.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアモジュールが使用するリソース量を個別に制限し、各ソフトウェアモジュールの最大リソース使用量の総和がシステム全体リソース量より小さくなるシステムにおけるリソース管理方法であって、
新たにソフトウェアモジュールをインストールまたは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりソフトウェアモジュールが安定動作していると判断するステップと、実行履歴から実リソース使用最大値を総和に含めて、インストールまたは実行可否を判断するステップとを有することを特徴としたリソース管理方法。
【請求項２】
請求項１記載のリソース管理方法において、
ソフトウェアモジュールのインストール期間または実行期間が一定時間より長いことによりソフトウェアモジュールが安定動作していると判断するステップを有することを特徴とするリソース管理方法。
【請求項３】
請求項１記載のリソース管理方法において、
インストールするソフトウェアモジュールとインストール済みのソフトウェアモジュールとの依存関係がある場合、安定動作していると判断できるソフトウェアモジュールであっても、リソース使用量制限値を総和に含めるステップを有することを特徴としたリソース管理方法。
【請求項４】
請求項１記載のリソース管理方法において、
前記リソースが、メモリ、ＣＰＵ、ファイルオープン、ソケット生成、ファイル容量、ネットワーク帯域、表示画面、およびその他計算機上で上限値が決まっているもののいずれか１以上であることを特徴とするリソース管理方法。
【請求項５】
請求項１記載にリソース管理方法において、
対象リソースがメモリであり、ソフトウェアモジュールにより動的に確保されたメモリ領域が、メモリコンパクションまたはガベージコレクションにより移動するシステムの場合、メモリ領域の移動が少なくなったことによりソフトウェアモジュールが安定動作していると判断することを特徴とするリソース管理方法。
【請求項６】
ソフトウェアモジュールが使用するリソース量を個別に制限し、各ソフトウェアモジュールの最大リソース使用量の総和がシステム全体リソース量より小さくなる組込み機器であって、
新たにソフトウェアモジュールをインストールまたは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりソフトウェアモジュールが安定動作していると判断する手段と、実行履歴から実リソース使用最大値を総和に含めて、インストールまたは実行可否を判断する手段とを有することを特徴とした組込み機器。
【請求項７】
請求項６記載の組込み機器において、
ソフトウェアモジュールのインストール期間または実行期間が一定時間より長いことによりソフトウェアモジュールが安定動作していると判断する手段を有することを特徴とする組込み機器。
【請求項８】
請求項６記載の組込み機器において、
インストールするソフトウェアモジュールとインストール済みのソフトウェアモジュールとの依存関係がある場合、安定動作していると判断できるソフトウェアモジュールであっても、リソース使用量制限値を総和に含める手段を有することを特徴とした組込み機器。
【請求項９】
請求項６記載の組込み機器において、
前記リソースが、メモリ、ＣＰＵ、ファイルオープン、ソケット生成、ファイル容量、ネットワーク帯域、表示画面、およびその他計算機上で上限値が決まっているもののいずれか１以上であることを特徴とする組込み機器。
【請求項１０】
請求項６記載に組込み機器において、
対象リソースがメモリであり、ソフトウェアモジュールにより動的に確保されたメモリ領域が、メモリコンパクションまたはガベージコレクションにより移動するシステムの場合、メモリ領域の移動が少なくなったことによりソフトウェアモジュールが安定動作していると判断することを特徴とする組込み機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システムにおけるリソースの管理方法と組込み機器に関し、特に組込み機器と呼ばれるようなリソースの少ない計算機システム向けのリソース管理方法に関する。
【背景技術】
【０００２】
近年、情報家電や携帯電話などの、いわゆる組込み機器と呼ばれる情報処理機器の機能が加速度的に増大している。ユーザ要求の高度化、メーカー間の競争、ネットワークへの対応などの要因が、機能増大が進む原因となっている。これらの機能増大に対応するために、組込み機器に搭載されるソフトウェアも複雑化しており、合わせてソフトウェアの動作に用いられるリソースの管理も複雑化している。
例えば、各機能要素を実現するソフトウェアモジュール（以下モジュールと呼称する）を複数組み合わせて全体機能を実現する組込み機器では、モジュールが相互にリソースを奪い合い、リソースが枯渇し、動作停止などの障害に結び付くケースが生じうる。このようなリソース障害は、開発作業を慎重に進めることで回避されるが、開発に必要な時間と経費の増加につながり、大きな問題となっている。
また、組込み機器のネットワーク接続の進展により、組込み機器がモジュールを受信し、受信したモジュールを実行するシステム事例が増加している。例えばネットワークなどを介してソフトウェア部品をやりとりすることで様々な機器の機能を容易に変更することを目指したプラットフォーム技術であるＯＳＧｉ（登録商標）は、各家庭に設置されたホームゲートウェイにモジュールを配信するための規格を定めている。一般に、このようなシステムにより配信されるモジュールは多様であり、モジュールのリソース使用量も様々である。このため、リソースを大量に使うモジュールが配信されて実行されると、組込み機器の持つリソースが枯渇する可能性がある。
上記のような問題に対処する方法として、モジュール単位の使用リソース量を監視および制御する方法が多数知られている。代表的な方法として、モジュール単位のリソース量制限値を設けて一定量以上のリソースの使用を許さない方法がある。
例えば特許文献１では、システム全体およびモジュールが使用するリソース量を制限することでリソース枯渇による動作停止などの障害を避けるリソース管理方法を示している。
また、非特許文献１では、メモリ領域を分割し、分割領域とモジュールを対応づけることで、各モジュールが使用するメモリ量を制限する方法を示している。詳しくは、共有されるメモリ専用の分割領域を一つ設け、共有するメモリの量を制限する方法を示している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2006-209735号公報
【非特許文献】
【０００４】
【非特許文献１】Godmar  Back,  Wilson  C.  Hsiegh,  Jay  Lepreau.  Processes  in  KaffeOS:  Isolation,  Resource  Management,  and  Sharing  in  Java.  USENIX  Symposium  OSDI  2000,  Oct.  23-25,  2000.
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、モジュールが必ずしも制限値までリソースを消費するとは限らない。ユーザの利用方法や、システム上で実行中のモジュールの構成によって実際にモジュールが使用するリソース量は変化するため、各モジュールに設定する制限値にある程度余裕を持たせる必要がある。そのため、それぞれのモジュールの制限値の総和よりシステム全体のリソース絶対量より少なくなるように制限してモジュールを実行すると、システム全体のリソース量に余裕があるにも関らず実行できるモジュール数が限られるという課題がある。
例えば、非特許文献１の示す従来技術は、モジュール数の増加に伴って、メモリ空間を細かく分割しなければならないため、各分割領域に空き領域を発生させ、メモリの使用効率が下がるという課題がある。【０００６】
本発明の目的は、上記課題を解決し、複数のモジュールを組み合わせて動作させる組込みシステムにおいて、リソース枯渇による障害発生の確率を下げつつ、リソース使用効率の向上するリソース管理方法及び組込み機器を提供することにある。
【課題を解決するための手段】
【０００７】
本発明は、新たにモジュールをインストールもしくは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりモジュールが安定動作していると判断出来るものに関しては各モジュールに設定されているリソース使用量制限値ではなく、実行履歴から実際に使用したリソース量の最大値を総和に含めて、インストールもしくは実行可否を判断することを最も主要な特徴とする。【０００８】
すなわち、本発明は、ソフトウェアモジュールが使用するリソース量を個別に制限し、各ソフトウェアモジュールの最大リソース使用量の総和がシステム全体リソース量より小さくなるシステムにおけるリソース管理方法であって、新たにソフトウェアモジュールをインストールまたは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりソフトウェアモジュールが安定動作していると判断するステップと、実行履歴から実リソース使用最大値を総和に含めて、インストールまたは実行可否を判断するステップとを有するリソース管理方法である。【０００９】
また、本発明は、ソフトウェアモジュールが使用するリソース量を個別に制限し、各ソフトウェアモジュールの最大リソース使用量の総和がシステム全体リソース量より小さくなる組込み機器であって、新たにソフトウェアモジュールをインストールまたは実行する際に、既にインストール済みまたは実行中のソフトウェアモジュール群の実行履歴によりソフトウェアモジュールが安定動作していると判断する手段と、実行履歴から実リソース使用最大値を総和に含めて、インストールまたは実行可否を判断する手段とを有する組込み機器である。
【発明の効果】
【００１０】
本発明によれば、特にリソースが限られた組込みシステム上で、各モジュールのリソース使用量が制限された環境で、リソース枯渇による障害発生の確率を下げつつ、リソース使用を効率化する効果がある。
【図面の簡単な説明】
【００１１】
【図１】図１は実施例１のシステム構成図である。
【図２】図２はソフトウェアモジュールの詳細を示した図である。
【図３】図３はリソース情報テーブルのデータ構造を示した図である。
【図４】図４はソフトウェアモジュールのインストールまたは実行可否を判断する処理を示したフローチャートである。
【図５】図５はメモリ移動に関する一例を示した図である。
【発明を実施するための最良の形態】
【００１２】
本発明を実施するための最良の形態を説明する。
本発明のリソース管理方法及び組込み装置の実施例について、説明する。
【実施例１】
【００１３】
図１は、本発明の１実施例のシステム構成図である。リモート保守サーバ装置１１０は、障害情報収集部１１１と障害情報データ１１２を有しており、情報家電端末装置で発生したソフトウェアモジュールの障害情報をインターネット経由で収集している。ソフトウェアモジュール配布サーバ装置１２０は、ソフトウェアモジュール登録部１２１と配布ソフトウェアモジュール格納部１２２とソフトウェアモジュール配布部１２３を有しており、情報家電端末装置１４０へ新しいソフトウェアモジュールを配布している。情報家電端末装置１４０は、ソフトウェアモジュール受信部１４１とモジュール管理部１４２とモジュールソフトウェアモジュール１４３と障害情報送信部１４４とリソース使用監視部１４５とリソース情報テーブル１４６を有している。ソフトウェアモジュール受信部１４１はソフトウェアモジュール配布サーバ装置１２０からソフトウェアモジュールを受信する。モジュール管理部１４２は、リソース情報テーブル１４６のデータに基づき、モジュールのインストールまた実行可否を判断する。ソフトウェアモジュール１４３は、ソフトウェアモジュール配布サーバ装置１２０から受信したソフトウェアモジュールや予め情報家電端末装置１４０にインストールされたソフトウェアモジュール等、複数個存在する。障害情報送信部１４４は、ソフトウェアモジュール１４３で発生した障害情報をリモート保守サーバ装置１１０に送信する。特にソフトウェアモジュール１４３に設定されたリソース制限値を越えない範囲で、リソース枯渇により障害が発生した場合は、その障害情報を送信する。障害情報は、ログ、メモリダンプ、スレッドダンプ、リソース使用状況等、ソフトウェアモジュール１４３で発生した障害の原因特定に利用する情報である。リモート保守サーバ装置１１０は、その情報を基に必要な保守、例えば情報家電端末装置１１０上で動作するソフトウェアモジュール１４３の停止、アンインストール、更新等を行う。リソース使用監視部１４５は、ソフトウェアモジュール１４３が使用するリソースを監視し、リソース使用量の最大値をリソース情報テーブル１４６に格納する。【００１４】
図２は、図１のソフトウェアモジュール１４３の詳細を示している。ソフトウェアモジュール１４３は、配布ソフトウェアモジュール格納部１２２に格納されており、情報家電端末装置１４０上で実行される。ソフトウェアモジュール１４３は、メタデータ２１０とプログラムコード２２０とデータリソース２３０からなる。メタデータ２１０は、ソフトウェアモジュール１４３のインストールおよび実行に必要な情報が記述されており、ソフトウェアモジュール１４３の実行に必要である依存ソフトウェアモジュール２１１の情報やメモリ制限値２１２が記述されている。依存ソフトウェアモジュール２１１は０個以上指定されている。プログラムコード２２０は、情報家電端末装置１４０上で実行されるコードである。データリソース２３０は、プログラムコード２２０が利用する画像等のデータである。【００１５】
図３は、図１のリソース情報テーブル１４６のデータ構造を示している。モジュール管理部１４２は、リソース情報テーブル１４６を参照して、ソフトウェアモジュールのインストールまたは実行可否を決定する。３０１はソフトウェアモジュールを一意に特定する識別子である。実行時間３０２はソフトウェアモジュールがインストールされてからの総実行時間である。メモリ移動最終時刻３０３は、ガベージコレクションによりソフトウェアモジュールが使用するメモリ領域の移動が行われた最後の時刻である。メモリ使用量最大値３０４は、ソフトウェアモジュールがインストールされてから最大に使用したメモリ量である。メモリ制限値３０５は、ソフトウェアモジュールに設定された使用できるメモリ量の制限値である。メモリ制限値３０５は予め情報家電端末装置１４０出荷時に設定されている場合や、リモート保守サーバ装置１１０により設定を更新する場合や、受信するソフトウェアモジュールにメモリ制限値が含まれている場合がある。行要素３０７は出荷時に設定される場合と、ソフトウェアモジュールのインストール時に追加される場合、リモート保守サーバ装置１１０により追加される場合がある。【００１６】
図４は、ソフトウェアモジュール受信部１４１が受信したソフトウェアモジュール１４３についてモジュール管理部１４２がリソース情報テーブル１４６に格納させているメモリ関連のデータのみに基づき、モジュールのインストールまた実行可否を判断するフローチャートを示している。処理フローを以下に説明する。
処理４０１：ソフトウェアモジュール受信部１４１がソフトウェアモジュール１４３を受信する。
処理４０２：モジュール管理部１４２は、受信したソフトウェアモジュール１４３のメタデータ２０１から、依存ソフトウェアモジュール２１１とメモリ制限値２１２を取得する。
処理４０３：最大メモリ使用量総和を格納する変数を０に設定する。
処理４０４：リソース情報テーブル１４６から次の行要素３０７を取得する。
処理４０５：受信ソフトウェアモジュールから取得した依存ソフトウェアモジュール２１１にモジュール識別子３０１が含まっている場合は、新たなソフトウェアモジュールのインストールおよび実行により、メモリ使用量最大値が増加する可能性があるため処理４０８に進む。その他は、処理４０６に進む。
処理４０６：実行時間３０２が予め設定された閾値を超える場合は、処理４０９に進む。その他は、処理４０７に進む。
処理４０７：現在時刻とメモリ移動最終時刻３０３の差分から経過時間を算出し、経過時間が予め設定された閾値を超える場合は、処理４０９に進む。その他は、処理４０８に進む。
処理４０８：最大メモリ使用量総和を格納する変数にメモリ制限値３０５を加算する。
処理４０９：最大メモリ使用量総和を格納する変数にメモリ使用量最大値３０４を加算する。
処理４１０：リソース情報テーブル１４６の最後の行要素３０７である場合は、処理４１１に進む。その他は、処理４０４に進む。
処理４１１：最大メモリ使用量総和を格納する変数に受信ソフトウェアモジュールのメモリ制限値２１２を加算する。
処理４１２：最大メモリ使用量総和を格納する変数の値とシステム全体で使用可能なメモリの絶対量を比較し、最大メモリ使用量総和を格納する変数の値が小さい場合は、処理４１３に進む。その他は、受信ソフトウェアモジュールのインストールは行わず処理４０１に進む。
処理４１３：受信ソフトウェアモジュールのインストールと起動を行う。
メモリ以外のリソースの制限値により受信ソフトウェアモジュールのインストールまたは実行可否の判断を行う場合、上記フローのメモリをその他のリソースに置き換えて実行する。ただし、処理４０７はメモリ特有の処理のため省略する。【００１７】
図５は、図１のリソース情報テーブル１４６のメモリ移動最終時刻３０３を記録するタイミングの一例を示す図である。ソフトウェアモジュールが使用するメモリ領域５０１を効率的にガベージコレクトする方法として、世代別ガベージコレクション方式が広く知られている。世代別ガベージコレクション方式では、ソフトウェアモジュールが使用するメモリ領域５０１を新世代領域５１０と旧世代領域５２０に分ける。ソフトウェアモジュールが使用するメモリ領域を新たに確保する時は、最初に新世代領域５１０に領域５１１を割り当てる。一定回数ガベージコレクションが実行された後でも、ソフトウェアモジュールが新世代領域５１０に領域を割り当てたメモリ領域を使用している場合は、メモリ領域を旧世代領域５２０に移動（コピー）する。ソフトウェアモジュールのメモリ使用量が安定してくると、一定回数内のガベージコレクション実行によって、新世代領域５１０に割り当てたメモリ領域５１２が解放されるという特徴がある。リソース使用監視部１４５は、ソフトウェアモジュールに割り当てたメモリ領域５１１が新世代領域５１０から旧世代領域５２０に移動した場合、リソース情報テーブル１４６のメモリ移動最終時刻３０３に現在時刻を記録する。モジュール管理部１４２は、メモリ移動最終時刻３０３からの経過時間が長い場合、安定動作していると判断する。【００１８】
以上、実施例で説明したように、本発明は、組込みシステムに限らず、任意にソフトウェアをインストールし、かつリソース枯渇による障害発生時にユーザが直ぐに復旧させることが難しい監視装置や、データセンタ機器等の情報システムに適用できる。
【符号の説明】
【００１９】
１１０    リモート保守サーバ装置
１１１    障害情報収集部
１１２    障害情報データ
１２０    ソフトウェアモジュール配布サーバ装置
１２１    ソフトウェアモジュール登録部
１２２    配布ソフトウェアモジュール格納部
１２３    ソフトウェアモジュール配布部
１３０    ネットワーク
１４０    情報家電端末装置
１４１    ソフトウェアモジュール受信部
１４２    モジュール管理部
１４３    ソフトウェアモジュール
１４４    障害情報送信部
１４５    リソース使用監視部
１４６    リソース情報テーブル
２１０    メタデータ
２１１    依存ソフトウェアモジュール
２１２    メモリ制限値
２２０    プログラムコード
２３０    データリソース
３０１    モジュール識別子
３０２    実行時間
３０３    メモリ移動最終時刻
３０４    メモリ使用量最大値
３０５    メモリ制限値
３０７    行要素
５０１    ソフトウェアモジュール使用可能メモリ領域
５１０    新世代領域
５１１    ソフトウェアモジュール割当メモリ領域
５１２    ソフトウェアモジュール割当メモリ領域
５２０    旧世代領域
【図１】
2010050335.tif 000003
【図２】
2010050335.tif 000004
【図３】
2010050335.tif 000005
【図４】
2010050335.tif 000006
【図５】
2010050335.tif 000007
【国際調査報告】
2010050335.tif 000008
2010050335.tif 000009
2010050335.tif 000010
2010050335.tif 000011