JP2011242890A - リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 - Google Patents
リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 Download PDFInfo
- Publication number
- JP2011242890A JP2011242890A JP2010112505A JP2010112505A JP2011242890A JP 2011242890 A JP2011242890 A JP 2011242890A JP 2010112505 A JP2010112505 A JP 2010112505A JP 2010112505 A JP2010112505 A JP 2010112505A JP 2011242890 A JP2011242890 A JP 2011242890A
- Authority
- JP
- Japan
- Prior art keywords
- request
- memory
- maximum
- amount
- memory amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Memory System (AREA)
Abstract
【課題】提供できる計算機資源の範囲内でリクエストを実行することで、計算機資源の不足を将来にわたって予防すること。
【解決手段】計算機３０のメモリ使用量制御部１０８が、現在実行中のリクエスト使用するメモリ量の増加分を第３メモリ量として計算し、最大サイズ管理テーブル１１８を参照して、新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、ユーザメモリ領域１１１内の現在の空き容量をＪａｖａＶＭから取得し、取得した現在の空き容量が、第３メモリ量と第４メモリ量との和よりも大きいときには、新たに受け付けたリクエストの実行を許可することを特徴とする。
【選択図】図１
【解決手段】計算機３０のメモリ使用量制御部１０８が、現在実行中のリクエスト使用するメモリ量の増加分を第３メモリ量として計算し、最大サイズ管理テーブル１１８を参照して、新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、ユーザメモリ領域１１１内の現在の空き容量をＪａｖａＶＭから取得し、取得した現在の空き容量が、第３メモリ量と第４メモリ量との和よりも大きいときには、新たに受け付けたリクエストの実行を許可することを特徴とする。
【選択図】図１
Description
本発明は、リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置の技術に関する。
クライアント装置からネットワークを介して接続されたシステムにおいて、クライアント装置から依頼されたリクエストが、システムが供給するメモリ量の枠内で実行できないときには、そのリクエストを拒否することにより、依頼されたリクエストがシステムに流入する流量を制御する技術が、特許文献１などに開示されている。このリクエスト流量制御システムにより、受け付けたリクエストを処理する計算機のメモリ不足を防止する。
リクエストを処理する計算機として、Ｊａｖａ（登録商標）のアプリケ−ションサーバを動作させる場合、主に性能向上の理由により、同一プロセス上で複数の処理が並行して実行される。よって、既に実行中のリクエストが存在している時点で、新たなリクエストの実行が要求されることもある。既に実行中のリクエストと、新たに要求されたリクエストが、同じメモリ資源のメモリ空間を分け合うときには、すべてのリクエストが使用するメモリ空間が、メモリ資源の最大容量以内に収まっている必要がある。
ここで、リクエストが使用するメモリ量は、時間経過によって変化（増加）することもある。例えば、所定時刻における空きメモリ量が、新たなリクエストの実行に要するメモリ量よりも大きくても、所定時刻以降に、既に実行中のリクエストが使用するメモリ量が増加することによって、新たなリクエストの実行に要するメモリ量が事後的に不足してしまう。
しかし、特許文献１などの従来のリクエスト流量制御システムでは、新たなリクエストの実行可否判断が、現在の（所定時刻の）メモリ量だけを参照し、その後の使用量の増加分を考慮しておらず、前記した事後的なメモリ不足を予防することができない。
そこで、本発明は、前記した問題を解決し、提供できる計算機資源の範囲内でリクエストを実行することで、計算機資源の不足を将来にわたって予防することを、主な目的とする。
前記課題を解決するために、本発明は、受け付けたリクエストを実行するリクエスト処理装置であって、
リクエスト処理装置が、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を動作させるＪａｖａアプリケーションサーバであり、
リクエスト処理装置が、ユーザメモリ領域とＪａｖａＶＭ管理領域とを記憶手段内に格納するとともに、メモリ使用量制御部を有しており、
前記ユーザメモリ領域には、リクエストを実行するためのプログラムを具現化したオブジェクトが格納されており、
前記ＪａｖａＶＭ管理領域には、前記ユーザメモリ領域に格納される前記オブジェクトの前記オブジェクトＩＤと、そのオブジェクトが使用するメモリ量と、そのオブジェクトを作成したリクエストのリクエストＩＤとが対応づけて前記オブジェクト管理用データとして格納されるとともに、リクエストＩＤごとにそのリクエストを実行するために使用する最大のメモリ量が対応づけて最大サイズ管理用データとして格納されており、
前記メモリ使用量制御部が、新たに受け付けたリクエストを実行するか否かを判定するときに、
前記最大サイズ管理用データを参照して、現在実行中のリクエストの最大のメモリ量を第１メモリ量として取得し、
前記オブジェクト管理用データを参照して、現在実行中のリクエストのリクエストＩＤに対応する前記オブジェクトが現在使用するメモリ量を第２メモリ量として取得し、前記第２メモリ量から前記第１メモリ量を減算した値を第３メモリ量として計算し、
前記最大サイズ管理用データを参照して、前記新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、
前記ユーザメモリ領域内の現在の空き容量を前記ＪａｖａＶＭから取得し、取得した現在の空き容量が、前記第３メモリ量と前記第４メモリ量との和よりも大きいときには、前記新たに受け付けたリクエストの実行を許可することを特徴とする。
その他の手段は、後記する。
リクエスト処理装置が、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を動作させるＪａｖａアプリケーションサーバであり、
リクエスト処理装置が、ユーザメモリ領域とＪａｖａＶＭ管理領域とを記憶手段内に格納するとともに、メモリ使用量制御部を有しており、
前記ユーザメモリ領域には、リクエストを実行するためのプログラムを具現化したオブジェクトが格納されており、
前記ＪａｖａＶＭ管理領域には、前記ユーザメモリ領域に格納される前記オブジェクトの前記オブジェクトＩＤと、そのオブジェクトが使用するメモリ量と、そのオブジェクトを作成したリクエストのリクエストＩＤとが対応づけて前記オブジェクト管理用データとして格納されるとともに、リクエストＩＤごとにそのリクエストを実行するために使用する最大のメモリ量が対応づけて最大サイズ管理用データとして格納されており、
前記メモリ使用量制御部が、新たに受け付けたリクエストを実行するか否かを判定するときに、
前記最大サイズ管理用データを参照して、現在実行中のリクエストの最大のメモリ量を第１メモリ量として取得し、
前記オブジェクト管理用データを参照して、現在実行中のリクエストのリクエストＩＤに対応する前記オブジェクトが現在使用するメモリ量を第２メモリ量として取得し、前記第２メモリ量から前記第１メモリ量を減算した値を第３メモリ量として計算し、
前記最大サイズ管理用データを参照して、前記新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、
前記ユーザメモリ領域内の現在の空き容量を前記ＪａｖａＶＭから取得し、取得した現在の空き容量が、前記第３メモリ量と前記第４メモリ量との和よりも大きいときには、前記新たに受け付けたリクエストの実行を許可することを特徴とする。
その他の手段は、後記する。
本発明によれば、提供できる計算機資源の範囲内でリクエストを実行することで、計算機資源の不足を将来にわたって予防することができる。
以下、本発明の一実施形態を、図面を参照して詳細に説明する。
図１は、リクエスト処理システムの装置構成の概要を示す説明図である。リクエスト処理システムは、端末１０と計算機３０がネットワーク２０を介して接続される。
端末１０は、計算機３０に指定された業務処理の実行を要求するリクエストを送信するクライアント装置である。
端末１０は、計算機３０に指定された業務処理の実行を要求するリクエストを送信するクライアント装置である。
計算機３０（Ｊａｖａアプリケーションサーバ）は、通信装置４０、ＣＰＵ５０、入力装置６０、出力装置７０、補助記憶装置８０および主記憶装置９５を備え、バス９０を介して互いに接続される。
通信装置４０は、端末１０に接続されるネットワーク２０に接続する。
ＣＰＵ５０は、主記憶装置９５に記憶された各種プログラムを実行することによって各種処理を実行する。
入力装置６０は、計算機３０に必要な情報および指示の入力に使用する。
出力装置７０は、計算機３０から出力される情報を表示する。
補助記憶装置８０は、プログラムおよびそのプログラムの実行に必要なデータを記憶手段に格納する記憶部として構成される。最大サイズ情報ファイル１２２（最大サイズ管理用データ）は、補助記憶装置８０に含まれる。なお、最大サイズ情報ファイル１２２は、例えば、手動で既に作成されたＣＳＶファイル１２２ｂからコピーされたものである。
通信装置４０は、端末１０に接続されるネットワーク２０に接続する。
ＣＰＵ５０は、主記憶装置９５に記憶された各種プログラムを実行することによって各種処理を実行する。
入力装置６０は、計算機３０に必要な情報および指示の入力に使用する。
出力装置７０は、計算機３０から出力される情報を表示する。
補助記憶装置８０は、プログラムおよびそのプログラムの実行に必要なデータを記憶手段に格納する記憶部として構成される。最大サイズ情報ファイル１２２（最大サイズ管理用データ）は、補助記憶装置８０に含まれる。なお、最大サイズ情報ファイル１２２は、例えば、手動で既に作成されたＣＳＶファイル１２２ｂからコピーされたものである。
主記憶装置９５は、コンテナ管理領域１０１、ユーザメモリ領域１１１、ＪａｖａＶＭ（Virtual Machine）管理領域１１３を含む。
コンテナ管理領域１０１は、リクエスト受付部１０２、リクエストＩＤ採番部１０３、リクエスト制御部１０４、プログラム処理部１０５、メモリ使用量制御部１０８、コマンド受付部１０９、コマンド実行部１１０を格納する。
ユーザメモリ領域１１１は、プログラム処理部１０５を構成するプログラムによって作成されたオブジェクト１１２を格納する。
ＪａｖａＶＭ管理領域１１３は、オブジェクト管理テーブル１１４（オブジェクト管理用データ）、オブジェクト管理部１１５、実行中リクエスト管理テーブル１１６、最大メモリ使用量計算部１１７、最大サイズ管理テーブル１１８、オブジェクトＩＤ採番部１１９、Ｊａｖａ ＡＰＩ（Application Program Interface）１２０、ＧＣ処理部１２１を含む。
コンテナ管理領域１０１は、リクエスト受付部１０２、リクエストＩＤ採番部１０３、リクエスト制御部１０４、プログラム処理部１０５、メモリ使用量制御部１０８、コマンド受付部１０９、コマンド実行部１１０を格納する。
ユーザメモリ領域１１１は、プログラム処理部１０５を構成するプログラムによって作成されたオブジェクト１１２を格納する。
ＪａｖａＶＭ管理領域１１３は、オブジェクト管理テーブル１１４（オブジェクト管理用データ）、オブジェクト管理部１１５、実行中リクエスト管理テーブル１１６、最大メモリ使用量計算部１１７、最大サイズ管理テーブル１１８、オブジェクトＩＤ採番部１１９、Ｊａｖａ ＡＰＩ（Application Program Interface）１２０、ＧＣ処理部１２１を含む。
リクエスト受付部１０２は、端末１０からのリクエストを受け付け、リクエストＩＤ採番部１０３で一意なリクエストＩＤを採番し、リクエスト制御部１０４にリクエストのＵＲＬとリクエストＩＤを通知する。
リクエスト制御部１０４は、リクエスト受付部１０２から通知されたリクエストＵＲＬとリクエストＩＤを受け取り、メモリ使用量制御部１０８にリクエストＵＲＬを通知して、リクエストが実行可能かどうかの判断を要求する。
メモリ使用量制御部１０８は、リクエスト制御部１０４から通知されたリクエストの実行可否判断要求に従い、受け付けたリクエストの実行可否を、以下の（１）〜（３）の順に判断する。
（１）図７で後記する判別式（１回目の判定）に従い、受け付けたリクエストの実行可否を判定する。ここで、リクエストの実行可であると判定されたときには、その旨をリクエスト制御部１０４に返答する。
（２）Ｊａｖａ ＡＰＩ１２０に対してＧＣの実施を要求して空きメモリを増加させる。そのＧＣの後に、図７で後記する判別式（２回目の判定）に従い、受け付けたリクエストの実行可否を判定する。ここで、リクエストの実行可であると判定されたときには、その旨をリクエスト制御部１０４に返答する。
（３）空きメモリ量の不足により、受け付けたリクエストが実行不可であると、リクエスト制御部１０４に返答する。
そして、（１）または（２）で返答を受けたリクエスト制御部１０４は、コンテナ処理部１０６を起動させて受け付けたリクエストを実行する。一方、（３）で返答を受けたリクエスト制御部１０４は、リクエスト受付部１０２に対してリクエストの実行が許可されなかった旨を通知する。
（１）図７で後記する判別式（１回目の判定）に従い、受け付けたリクエストの実行可否を判定する。ここで、リクエストの実行可であると判定されたときには、その旨をリクエスト制御部１０４に返答する。
（２）Ｊａｖａ ＡＰＩ１２０に対してＧＣの実施を要求して空きメモリを増加させる。そのＧＣの後に、図７で後記する判別式（２回目の判定）に従い、受け付けたリクエストの実行可否を判定する。ここで、リクエストの実行可であると判定されたときには、その旨をリクエスト制御部１０４に返答する。
（３）空きメモリ量の不足により、受け付けたリクエストが実行不可であると、リクエスト制御部１０４に返答する。
そして、（１）または（２）で返答を受けたリクエスト制御部１０４は、コンテナ処理部１０６を起動させて受け付けたリクエストを実行する。一方、（３）で返答を受けたリクエスト制御部１０４は、リクエスト受付部１０２に対してリクエストの実行が許可されなかった旨を通知する。
プログラム処理部１０５は、コンテナ処理部１０６とユーザ処理部１０７とによって構成される。
コンテナ処理部１０６は、リクエスト制御、トランザクション制御などを行う。コンテナ処理部１０６はリクエスト制御部から処理の要求を受けたときに実行中リクエスト管理テーブル１１６に対し、リクエストの情報を格納する。さらに、コンテナ処理部１０６はユーザ処理部１０７を実行する。ユーザ処理部１０７の処理の終了後、コンテナ処理部１０６は実行中リクエスト管理テーブル１１６からリクエストの情報を削除する
ユーザ処理部１０７は、業務処理を実行するためにユーザが作成したプログラムを実行する処理部である。また、ユーザ処理部１０７はオブジェクトを使用する場合には、オブジェクト管理部１１５にオブジェクト生成を依頼し、ユーザメモリ領域に生成されたオブジェクト１１２を使用する。
コンテナ処理部１０６は、リクエスト制御、トランザクション制御などを行う。コンテナ処理部１０６はリクエスト制御部から処理の要求を受けたときに実行中リクエスト管理テーブル１１６に対し、リクエストの情報を格納する。さらに、コンテナ処理部１０６はユーザ処理部１０７を実行する。ユーザ処理部１０７の処理の終了後、コンテナ処理部１０６は実行中リクエスト管理テーブル１１６からリクエストの情報を削除する
ユーザ処理部１０７は、業務処理を実行するためにユーザが作成したプログラムを実行する処理部である。また、ユーザ処理部１０７はオブジェクトを使用する場合には、オブジェクト管理部１１５にオブジェクト生成を依頼し、ユーザメモリ領域に生成されたオブジェクト１１２を使用する。
オブジェクト管理部１１５は、ユーザメモリ領域１１１のオブジェクト１１２を管理する処理部である。
オブジェクト管理部１１５は、ユーザ処理部１０７からの要求を受け付け、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを採番し、要求されたオブジェクト１１２を作成し、オブジェクト管理テーブル１１４にオブジェクトの情報を格納する。
また、オブジェクト管理部１１５は、メモリ使用量制御部１０８および最大メモリ使用量計算部１１７からリクエストＩＤを受けとり、リクエストが作成したオブジェクトのサイズの一覧を返却する。
さらに、オブジェクト管理部１１５は、ＧＣ処理部１２１の要求を受け付け、オブジェクト１１２の情報をオブジェクト管理テーブル１１４から削除し、オブジェクト１１２をユーザメモリ領域１１１から解放する。
オブジェクト管理部１１５は、ユーザ処理部１０７からの要求を受け付け、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを採番し、要求されたオブジェクト１１２を作成し、オブジェクト管理テーブル１１４にオブジェクトの情報を格納する。
また、オブジェクト管理部１１５は、メモリ使用量制御部１０８および最大メモリ使用量計算部１１７からリクエストＩＤを受けとり、リクエストが作成したオブジェクトのサイズの一覧を返却する。
さらに、オブジェクト管理部１１５は、ＧＣ処理部１２１の要求を受け付け、オブジェクト１１２の情報をオブジェクト管理テーブル１１４から削除し、オブジェクト１１２をユーザメモリ領域１１１から解放する。
Ｊａｖａ ＡＰＩ１２０は、Ｊａｖａが提供する既存のインタフェースである。Ｊａｖａ ＡＰＩ１２０は、メモリ使用量制御部１０８から現在の空きメモリ使用量を取得する要求およびＧＣの発行要求を受ける。
ＧＣ処理部１２１は、ユーザメモリ領域１１１の空きメモリ領域が少なくなった場合またはＪａｖａ ＡＰＩ１２０からＧＣ発行要求を受けた場合に、ユーザメモリ領域１１１に格納されているオブジェクト１１２のうち、破棄可能なオブジェクトを抽出し、オブジェクト管理部１１５にオブジェクトの解放を依頼する。このＧＣ処理は、Ｊａｖａに実装されている。
最大サイズ情報ファイル１２２は、各ＵＲＬが使用するメモリ使用量の最大サイズを格納する。具体的には、各ＵＲＬへのリクエストで使用するメモリ使用量の合計、および最もメモリを使用する瞬間のメモリ使用量を、処理の開始前にユーザが格納する。最大サイズ情報ファイル１２２は、メモリ使用量制御部１０８がリクエストを受け取るたびに読み込んでも、Ｊａｖａアプリケーションサーバ起動時にすべて読み込んで主記憶装置９５に格納してもよい。
最大サイズ情報ファイル１２２の作成処理は、以下に示す（１）または（２）の２つのモードのうちのいずれか１つにより実現される。
最大サイズ情報ファイル１２２の作成処理は、以下に示す（１）または（２）の２つのモードのうちのいずれか１つにより実現される。
（１）手動設定モードは、最大サイズ情報ファイル１２２のデータ内容を、管理者などによる手動設定により、明示的に指定を受けるモードである（詳細は、図７参照）。
そのため、コマンド受付部１０９は、管理者からのコマンドとして、「最大サイズ情報ファイル１２２のデータ内容を指定した作成要求」を受け付けると、コマンド実行部１１０に処理の制御を移す。
または、コマンド受付部１０９は、管理者からのコマンドとして、手動で既に作成された図１のＣＳＶファイル１２２ｂを受け付けると、コマンド実行部１１０に処理の制御を移す。
コマンド実行部１１０は、コマンド受付部１０９から要求を受け取り、コマンドで指定されたデータ内容またはＣＳＶファイル１２２ｂのデータ内容を、そのまま最大サイズ情報ファイル１２２として出力する。
そのため、コマンド受付部１０９は、管理者からのコマンドとして、「最大サイズ情報ファイル１２２のデータ内容を指定した作成要求」を受け付けると、コマンド実行部１１０に処理の制御を移す。
または、コマンド受付部１０９は、管理者からのコマンドとして、手動で既に作成された図１のＣＳＶファイル１２２ｂを受け付けると、コマンド実行部１１０に処理の制御を移す。
コマンド実行部１１０は、コマンド受付部１０９から要求を受け取り、コマンドで指定されたデータ内容またはＣＳＶファイル１２２ｂのデータ内容を、そのまま最大サイズ情報ファイル１２２として出力する。
（２）テストモードは、最大サイズ情報ファイル１２２のデータ内容を、実際にリクエストを動作させた結果の実測値を計測することにより、取得するモードである（詳細は、図８参照）。
そのため、テストモードでは、手動設定モードで必要な構成に加え、さらに、最大メモリ使用量計算部１１７と最大サイズ管理テーブル１１８とを用いる。
最大メモリ使用量計算部１１７は、オブジェクト１１２のメモリ使用量をリクエストＩＤごとに集計（合計）し、その結果を最大サイズ管理テーブル１１８に格納する。
そして、コマンド受付部１０９は、管理者からコマンドの要求を受け付け、コマンド実行部１１０に処理の制御を移す。コマンド実行部１１０は、コマンド受付部１０９から要求を受け取り、最大サイズ管理テーブル１１８に格納されている情報を参照し、参照した情報を整形し（表形式からＣＳＶ（Comma-Separated Values）形式へのエクスポート処理）、その結果を最大サイズ情報ファイル１２２に出力する。
そのため、テストモードでは、手動設定モードで必要な構成に加え、さらに、最大メモリ使用量計算部１１７と最大サイズ管理テーブル１１８とを用いる。
最大メモリ使用量計算部１１７は、オブジェクト１１２のメモリ使用量をリクエストＩＤごとに集計（合計）し、その結果を最大サイズ管理テーブル１１８に格納する。
そして、コマンド受付部１０９は、管理者からコマンドの要求を受け付け、コマンド実行部１１０に処理の制御を移す。コマンド実行部１１０は、コマンド受付部１０９から要求を受け取り、最大サイズ管理テーブル１１８に格納されている情報を参照し、参照した情報を整形し（表形式からＣＳＶ（Comma-Separated Values）形式へのエクスポート処理）、その結果を最大サイズ情報ファイル１２２に出力する。
なお、テストモードの動作期間は、長期間であるほど望ましい。テストモードを長期間動作させることで、メモリ使用量の最大値の更新頻度も上がるため、最大サイズ管理テーブル１１８に格納される最大メモリ使用量の精度も向上する。
さらに、テストモードを使用して作成した最大サイズ情報ファイル１２２の情報を、新規リクエストの実行可否判定だけでなく、メモリチューニングや、大量にメモリを消費するリクエストの特定などの別の用途に活用してもよい。
さらに、テストモードを使用して作成した最大サイズ情報ファイル１２２の情報を、新規リクエストの実行可否判定だけでなく、メモリチューニングや、大量にメモリを消費するリクエストの特定などの別の用途に活用してもよい。
図２は、実行中リクエスト管理テーブル１１６の一例を示す説明図である。
リクエスト管理テーブル１１６は、リクエストＩＤフィールド２０１およびＵＲＬフィールド２０２を含む。実行中リクエスト管理テーブル１１６のレコードはリクエストの受付時にコンテナ処理部１０６によって格納され、リクエストの終了時にコンテナ処理部１０６に削除される。このため、実行中リクエスト管理テーブル１１６を参照することで実行中リクエストの一覧を取得することができる。
リクエストＩＤフィールド２０１は、端末１０から受け付けたリクエストを一意に識別するリクエストＩＤを格納する。リクエストＩＤは、リクエスト受付時にリクエストＩＤ採番部１０３に生成される。
ＵＲＬフィールド２０２は、端末１０から受け付けたリクエストに含まれるＵＲＬを格納する。
リクエスト管理テーブル１１６は、リクエストＩＤフィールド２０１およびＵＲＬフィールド２０２を含む。実行中リクエスト管理テーブル１１６のレコードはリクエストの受付時にコンテナ処理部１０６によって格納され、リクエストの終了時にコンテナ処理部１０６に削除される。このため、実行中リクエスト管理テーブル１１６を参照することで実行中リクエストの一覧を取得することができる。
リクエストＩＤフィールド２０１は、端末１０から受け付けたリクエストを一意に識別するリクエストＩＤを格納する。リクエストＩＤは、リクエスト受付時にリクエストＩＤ採番部１０３に生成される。
ＵＲＬフィールド２０２は、端末１０から受け付けたリクエストに含まれるＵＲＬを格納する。
図３は、オブジェクト管理テーブル１１４の一例を示す説明図である。オブジェクト管理テーブル１１４は、オブジェクトＩＤフィールド３０１、リクエストＩＤフィールド３０２、および、オブジェクトサイズフィールド３０３を含む。
オブジェクト管理テーブル１１４のレコードはオブジェクト１１２の作成時にオブジェクト管理部１１５によって格納され、オブジェクト１１２の解放時にオブジェクト管理部１１５によって削除される。オブジェクト管理テーブル１１４は、リクエストごとのメモリ使用量を計算するためにオブジェクト管理部１１５から参照される。
オブジェクト管理テーブル１１４のレコードはオブジェクト１１２の作成時にオブジェクト管理部１１５によって格納され、オブジェクト１１２の解放時にオブジェクト管理部１１５によって削除される。オブジェクト管理テーブル１１４は、リクエストごとのメモリ使用量を計算するためにオブジェクト管理部１１５から参照される。
オブジェクトＩＤフィールド３０１は、オブジェクト管理部１１５がオブジェクトを一意に識別するオブジェクトＩＤを格納する。オブジェクトＩＤは、オブジェクト管理部１１５の要求を受けて、オブジェクトＩＤ採番部１１９が生成する。
リクエストＩＤフィールド３０２は、実行中リクエスト管理テーブル１１６のリクエストＩＤフィールド２０１と同じである。リクエストＩＤフィールド３０２には、オブジェクトを作成したリクエストのリクエストＩＤが格納される
オブジェクトサイズフィールド３０３は、オブジェクト１１２が使用しているメモリ量である。オブジェクト管理テーブル１１４は、オブジェクト１１２を作成する際に確保したメモリ量を、オブジェクトサイズフィールド３０３に格納する。
リクエストＩＤフィールド３０２は、実行中リクエスト管理テーブル１１６のリクエストＩＤフィールド２０１と同じである。リクエストＩＤフィールド３０２には、オブジェクトを作成したリクエストのリクエストＩＤが格納される
オブジェクトサイズフィールド３０３は、オブジェクト１１２が使用しているメモリ量である。オブジェクト管理テーブル１１４は、オブジェクト１１２を作成する際に確保したメモリ量を、オブジェクトサイズフィールド３０３に格納する。
図４は、最大サイズ管理テーブル１１８の一例を示す説明図である。最大サイズ管理テーブル１１８は、ＵＲＬフィールド４０１、ＧＣ前最大使用量フィールド４０２、ＧＣ後最大使用量フィールド４０３を含む。
ＵＲＬフィールド４０１は、実行中リクエスト管理テーブル１１６のＵＲＬフィールド２０２と同じである。
ＧＣ前最大使用量フィールド４０２、および、ＧＣ後最大使用量フィールド４０３は、それぞれ、リクエストの生存期間（開始時刻から終了時刻まで）において、そのリクエストが使用するメモリ使用量の最大値を格納する。
ＧＣ前最大使用量フィールド４０２は、ＧＣ処理部１２１によるＧＣ処理が行われる前における、メモリ使用量の最大値を格納する。
ＧＣ後最大使用量フィールド４０３は、ＧＣ処理部１２１によるＧＣ処理が行われた後における、メモリ使用量の最大値を格納する。
ＵＲＬフィールド４０１は、実行中リクエスト管理テーブル１１６のＵＲＬフィールド２０２と同じである。
ＧＣ前最大使用量フィールド４０２、および、ＧＣ後最大使用量フィールド４０３は、それぞれ、リクエストの生存期間（開始時刻から終了時刻まで）において、そのリクエストが使用するメモリ使用量の最大値を格納する。
ＧＣ前最大使用量フィールド４０２は、ＧＣ処理部１２１によるＧＣ処理が行われる前における、メモリ使用量の最大値を格納する。
ＧＣ後最大使用量フィールド４０３は、ＧＣ処理部１２１によるＧＣ処理が行われた後における、メモリ使用量の最大値を格納する。
最大メモリ使用量計算部１１７は、リクエストの生存期間に、そのリクエストのメモリ使用量を監視し、既に最大サイズ管理テーブル１１８に格納されているメモリ使用量の最大値よりも、現在のメモリ使用量が上回ったときには、その上回った現在のメモリ使用量を、メモリ使用量の最大値として、ＧＣ前最大使用量フィールド４０２（ＧＣ処理前の場合）、または、ＧＣ後最大使用量フィールド４０３（ＧＣ処理後の場合）に格納する（値を更新する）。
図５は、最大サイズ情報ファイル１２２の一例を示す説明図である。最大サイズ情報ファイル１２２は、ＵＲＬフィールド５０１、ＧＣ前最大使用量フィールド５０２、ＧＣ後最大使用量フィールド５０３を含む。最大サイズ情報ファイル１２２は、最大サイズ管理テーブル１１８のデータ内容をＣＳＶ形式にしたものである。
ＵＲＬフィールド５０１は、ＵＲＬフィールド４０１と同じ内容である。
ＧＣ前最大使用量フィールド５０２は、ＧＣ前最大使用量フィールド４０２と同じ内容である。
ＧＣ後最大使用量フィールド５０３は、ＧＣ後最大使用量フィールド４０３と同じ内容である。
ＵＲＬフィールド５０１は、ＵＲＬフィールド４０１と同じ内容である。
ＧＣ前最大使用量フィールド５０２は、ＧＣ前最大使用量フィールド４０２と同じ内容である。
ＧＣ後最大使用量フィールド５０３は、ＧＣ後最大使用量フィールド４０３と同じ内容である。
図６は、新規リクエストの実行可否判定のための判別式を示す説明図である。図６（ａ）および図６（ｂ）は、それぞれ特許文献１などの比較例における判別式での問題点を説明する図であり、図６（ｃ）は本実施形態での判別式が比較例の問題点を解決している旨を説明する図である。
図６（ａ）は、新規リクエストＲ３が到着した時点での、ユーザメモリ領域１１１内のメモリ使用状況を示す。
ユーザメモリ領域１１１内で、既存のリクエスト（Ｒ１，Ｒ２）が実行中であり、それぞれ現在使用量のメモリを使用している。しかし、ユーザメモリ領域１１１内の現在の空きメモリ量には、新規リクエストＲ３の現在の（実行開始時に必要な）メモリ使用量が収まる程度の充分な空きがある。
よって、比較例の以下の判別式を満たすことにより、新規リクエストＲ３は実行可と判定される。
（現在の空きメモリ量）＝（ユーザメモリ領域１１１のメモリ容量）−（Ｒ１の現在使用量）−（Ｒ２の現在使用量）とすると、判別式「（Ｒ３の現在使用量）＜（現在の空きメモリ量）」を満たす。
ユーザメモリ領域１１１内で、既存のリクエスト（Ｒ１，Ｒ２）が実行中であり、それぞれ現在使用量のメモリを使用している。しかし、ユーザメモリ領域１１１内の現在の空きメモリ量には、新規リクエストＲ３の現在の（実行開始時に必要な）メモリ使用量が収まる程度の充分な空きがある。
よって、比較例の以下の判別式を満たすことにより、新規リクエストＲ３は実行可と判定される。
（現在の空きメモリ量）＝（ユーザメモリ領域１１１のメモリ容量）−（Ｒ１の現在使用量）−（Ｒ２の現在使用量）とすると、判別式「（Ｒ３の現在使用量）＜（現在の空きメモリ量）」を満たす。
図６（ｂ）は、図６（ａ）の時点から、さらに時間経過したときのユーザメモリ領域１１１内のメモリ使用状況を示す。
既存のリクエスト（Ｒ１，Ｒ２）は、それぞれ図６（ａ）での現在使用量から、さらに増加分だけのメモリを追加的に使用した結果、最大使用量分のメモリを使用する。そのため、図６（ｂ）の時点では、図６（ａ）の時点よりも、メモリ使用量の増加分だけ現在の空きメモリ量が減少している。その結果、新規リクエストＲ３の使用可能なメモリ量が減少してしまい、図６（ａ）で実行可とされたにもかかわらず、事後的にメモリ不足に陥ってしまう。
既存のリクエスト（Ｒ１，Ｒ２）は、それぞれ図６（ａ）での現在使用量から、さらに増加分だけのメモリを追加的に使用した結果、最大使用量分のメモリを使用する。そのため、図６（ｂ）の時点では、図６（ａ）の時点よりも、メモリ使用量の増加分だけ現在の空きメモリ量が減少している。その結果、新規リクエストＲ３の使用可能なメモリ量が減少してしまい、図６（ａ）で実行可とされたにもかかわらず、事後的にメモリ不足に陥ってしまう。
図６（ｃ）は、図６（ａ）の時点での本実施形態の判別式の処理内容を示す。図６（ａ）では、既存のリクエスト（Ｒ１，Ｒ２）の現在使用量を参照していたが、図６（ｃ）では、現在使用量に加えて、既存のリクエスト（Ｒ１，Ｒ２）の最大使用量を、あらかじめ登録された値として記憶手段から読み取る。そして、以下の判別式を満たすか否かを判定する。
（Ｒ３の最大使用量）＜（今後も利用可能な空きメモリ量）
この判別式は、（今後も利用可能な空きメモリ量）＝（現在の空きメモリ量）−（Ｒ１の増加分）−（Ｒ２の増加分）であるため、以下の判別式と等価である。
（Ｒ１の増加分）＋（Ｒ２の増加分）＋（Ｒ３の最大使用量）＜（現在の空きメモリ量）
今回の例では、（Ｒ１の増加分）＋（Ｒ２の増加分）が大きいため、（今後も利用可能な空きメモリ量）が少ないので、この判別式を満たさないと判定される。つまり、図６（ｃ）の判別式は、図６（ａ）の判別式と異なり、現在のメモリ量（現在使用量、空きメモリ量）だけでなく、将来の（最大の）メモリ使用量をも参照することにより、事後的にメモリ不足に陥ってしまうことを抑制できる。
（Ｒ３の最大使用量）＜（今後も利用可能な空きメモリ量）
この判別式は、（今後も利用可能な空きメモリ量）＝（現在の空きメモリ量）−（Ｒ１の増加分）−（Ｒ２の増加分）であるため、以下の判別式と等価である。
（Ｒ１の増加分）＋（Ｒ２の増加分）＋（Ｒ３の最大使用量）＜（現在の空きメモリ量）
今回の例では、（Ｒ１の増加分）＋（Ｒ２の増加分）が大きいため、（今後も利用可能な空きメモリ量）が少ないので、この判別式を満たさないと判定される。つまり、図６（ｃ）の判別式は、図６（ａ）の判別式と異なり、現在のメモリ量（現在使用量、空きメモリ量）だけでなく、将来の（最大の）メモリ使用量をも参照することにより、事後的にメモリ不足に陥ってしまうことを抑制できる。
以上、図６で示した判別式は、以下に示すように、一般化できる。
図６（ａ）の判別式は、以下の通りである。
（ＤＲＣ）＋（ＤＮＣ）＜（ＲＳ）
ここで、ＤＲＣ（Demand Running Current）は、実行中（Running）のリクエストＲ１，Ｒ２の現在（Current）のメモリ使用量（Demand）の合計を示す。
ＤＮＣ（Demand New Current）は、新規の（New）リクエストＲ３の現在（Current）のメモリ使用量（Demand）を示す。
ＲＳ（Resource Supply）は、ユーザメモリ領域１１１が提供するメモリ資源（Resource）の供給量（Supply）を示す。
（ＤＲＣ）＋（ＤＮＣ）＜（ＲＳ）
ここで、ＤＲＣ（Demand Running Current）は、実行中（Running）のリクエストＲ１，Ｒ２の現在（Current）のメモリ使用量（Demand）の合計を示す。
ＤＮＣ（Demand New Current）は、新規の（New）リクエストＲ３の現在（Current）のメモリ使用量（Demand）を示す。
ＲＳ（Resource Supply）は、ユーザメモリ領域１１１が提供するメモリ資源（Resource）の供給量（Supply）を示す。
図６（ｂ）の状況は、以下の式で表現される。
（ＤＲＭ）＋（ＤＮＭ）＞（ＲＳ）
ここで、ＤＲＭ（Demand Running Maximum）は、実行中（Running）のリクエストＲ１，Ｒ２の最大（Maximum）のメモリ使用量（Demand）の合計を示す。
ＤＮＭ（Demand New Maximum）は、新規の（New）リクエストＲ３の最大（Maximum）のメモリ使用量（Demand）を示す。
（ＤＲＭ）＋（ＤＮＭ）＞（ＲＳ）
ここで、ＤＲＭ（Demand Running Maximum）は、実行中（Running）のリクエストＲ１，Ｒ２の最大（Maximum）のメモリ使用量（Demand）の合計を示す。
ＤＮＭ（Demand New Maximum）は、新規の（New）リクエストＲ３の最大（Maximum）のメモリ使用量（Demand）を示す。
図６（ｃ）の判別式は、以下の通りである。
（ＤＲＭ）＋（ＤＮＭ）＜（ＲＳ）
ここで、ＤＲＩ（Demand Running Increase）は、実行中（Running）のリクエストＲ１，Ｒ２の増加分（Increase）のメモリ使用量（Demand）の合計を示す。（ＤＲＭ）＝（ＤＲＣ＋ＤＲＩ）により、図６（ｃ）の判別式は、以下のように式変形できる。これらの式変形における各式は内容が等価であるので、式変形における各式のうちのどの式を判別式に用いてもよい。
（ＤＲＭ）＋（ＤＮＭ）＜（ＲＳ）
（ＤＲＣ＋ＤＲＩ）＋（ＤＮＭ）＜（ＲＳ）
（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳ）−（ＤＲＣ）
（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）
ここで、ＲＳＣ（Resource Supply Current）は、現在（Current）の空きメモリ量（Resource Supply）であり、「（ＲＳ）−（ＤＲＣ）」と等価である。
（ＤＲＭ）＋（ＤＮＭ）＜（ＲＳ）
ここで、ＤＲＩ（Demand Running Increase）は、実行中（Running）のリクエストＲ１，Ｒ２の増加分（Increase）のメモリ使用量（Demand）の合計を示す。（ＤＲＭ）＝（ＤＲＣ＋ＤＲＩ）により、図６（ｃ）の判別式は、以下のように式変形できる。これらの式変形における各式は内容が等価であるので、式変形における各式のうちのどの式を判別式に用いてもよい。
（ＤＲＭ）＋（ＤＮＭ）＜（ＲＳ）
（ＤＲＣ＋ＤＲＩ）＋（ＤＮＭ）＜（ＲＳ）
（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳ）−（ＤＲＣ）
（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）
ここで、ＲＳＣ（Resource Supply Current）は、現在（Current）の空きメモリ量（Resource Supply）であり、「（ＲＳ）−（ＤＲＣ）」と等価である。
さらに、以下に示すように、判別式に用いられる各パラメータを取得することができる。
ＤＲＣ（第１メモリ量）は、実行中のリクエストのリクエストＩＤをリクエストＩＤフィールド２０１から取得し、そのリクエストＩＤをリクエストＩＤフィールド３０２から検索し、検索されたレコードのオブジェクトサイズフィールド３０３をリクエストＩＤごとに合計することによって、計算できる。
ＤＲＭ（第２メモリ量）は、実行中のリクエストのＵＲＬをＵＲＬフィールド２０２から取得し、そのＵＲＬをＵＲＬフィールド４０１（＝ＵＲＬフィールド５０１）から検索し、検索されたレコードのＧＣ前最大使用量フィールド４０２（＝ＧＣ前最大使用量フィールド５０２）、および、ＧＣ後最大使用量フィールド４０３（＝ＧＣ後最大使用量フィールド５０３）の値として、取得できる。
ＤＲＩ（第３メモリ量）は、「ＤＲＭ−ＤＲＣ」で計算できる。
ＤＲＣ（第１メモリ量）は、実行中のリクエストのリクエストＩＤをリクエストＩＤフィールド２０１から取得し、そのリクエストＩＤをリクエストＩＤフィールド３０２から検索し、検索されたレコードのオブジェクトサイズフィールド３０３をリクエストＩＤごとに合計することによって、計算できる。
ＤＲＭ（第２メモリ量）は、実行中のリクエストのＵＲＬをＵＲＬフィールド２０２から取得し、そのＵＲＬをＵＲＬフィールド４０１（＝ＵＲＬフィールド５０１）から検索し、検索されたレコードのＧＣ前最大使用量フィールド４０２（＝ＧＣ前最大使用量フィールド５０２）、および、ＧＣ後最大使用量フィールド４０３（＝ＧＣ後最大使用量フィールド５０３）の値として、取得できる。
ＤＲＩ（第３メモリ量）は、「ＤＲＭ−ＤＲＣ」で計算できる。
ＤＮＭ（第４メモリ量）は、新規に到着したリクエストのＵＲＬをＵＲＬフィールド４０１（＝ＵＲＬフィールド５０１）から検索し、検索されたレコードのＧＣ前最大使用量フィールド４０２（＝ＧＣ前最大使用量フィールド５０２）、および、ＧＣ後最大使用量フィールド４０３（＝ＧＣ後最大使用量フィールド５０３）の値として、取得できる。
ＲＳは、ユーザメモリ領域１１１として利用可能なメモリ容量の最大値であり、例えば、Ｊａｖａ ＡＰＩ１２０を介して取得される。なお、ユーザメモリ領域１１１は、Ｊａｖａでそのメモリ容量の上限を設定可能であり、例えば、ＯＳ（Operating System）上で利用可能な４ＧＢのメモリの内の０．５ＧＢが、上限として設定される。そのときは、オブジェクト１１２のデータ量の総和が０．５ＧＢ以内の範囲内で、オブジェクト１１２をユーザメモリ領域１１１に配置することができる。一方、ＯＳ上の利用可能なメモリ容量と、ユーザメモリ領域１１１の利用可能なメモリ容量とが同じときには、ＯＳのシステムコールを介して取得したＯＳ上の利用可能なメモリ容量を、ユーザメモリ領域１１１の利用可能なメモリ容量としてもよい。
ＲＳＣは、ＲＳのうちの現在の空きメモリであり、Ｊａｖａ ＡＰＩ１２０を介して、取得される。
ＲＳは、ユーザメモリ領域１１１として利用可能なメモリ容量の最大値であり、例えば、Ｊａｖａ ＡＰＩ１２０を介して取得される。なお、ユーザメモリ領域１１１は、Ｊａｖａでそのメモリ容量の上限を設定可能であり、例えば、ＯＳ（Operating System）上で利用可能な４ＧＢのメモリの内の０．５ＧＢが、上限として設定される。そのときは、オブジェクト１１２のデータ量の総和が０．５ＧＢ以内の範囲内で、オブジェクト１１２をユーザメモリ領域１１１に配置することができる。一方、ＯＳ上の利用可能なメモリ容量と、ユーザメモリ領域１１１の利用可能なメモリ容量とが同じときには、ＯＳのシステムコールを介して取得したＯＳ上の利用可能なメモリ容量を、ユーザメモリ領域１１１の利用可能なメモリ容量としてもよい。
ＲＳＣは、ＲＳのうちの現在の空きメモリであり、Ｊａｖａ ＡＰＩ１２０を介して、取得される。
図７は、手動設定モードにおける構成要素間のメッセージの流れを示す説明図である。
ｍ１において、リクエスト受付部１０２は、端末１０からの新規リクエストを受け付ける。
ｍ２において、リクエスト受付部１０２は、リクエストＩＤ採番部１０３に対して、ｍ１で受けた新規リクエストを一意に識別するリクエストＩＤの生成を要求する。リクエストＩＤ採番部１０３は、一意に識別するＩＤを生成して、リクエスト受付部１０２に生成した値を返却する。
ｍ３において、リクエスト受付部１０２は、ｍ１で受けた新規リクエストについての、リクエストＩＤとリクエストのＵＲＬとを、リクエスト制御部１０４に通知する。
ｍ２において、リクエスト受付部１０２は、リクエストＩＤ採番部１０３に対して、ｍ１で受けた新規リクエストを一意に識別するリクエストＩＤの生成を要求する。リクエストＩＤ採番部１０３は、一意に識別するＩＤを生成して、リクエスト受付部１０２に生成した値を返却する。
ｍ３において、リクエスト受付部１０２は、ｍ１で受けた新規リクエストについての、リクエストＩＤとリクエストのＵＲＬとを、リクエスト制御部１０４に通知する。
ｍ４において、リクエスト制御部１０４は、ｍ３で受信したリクエストのＵＲＬを、メモリ使用量制御部１０８に通知する。
ｍ５において、メモリ使用量制御部１０８は、実行中リクエスト管理テーブル１１６を参照して、現在実行されているリクエストの一覧をリクエストＩＤのリストとして取得する。例えば、図２でいうと、「１」、「２」、「３」、「４」というリクエストＩＤと、それぞれのＵＲＬが取得される。
ｍ６において、メモリ使用量制御部１０８は、ｍ５で取得したリクエストＩＤをオブジェクト管理部１１５に通知する。
ｍ５において、メモリ使用量制御部１０８は、実行中リクエスト管理テーブル１１６を参照して、現在実行されているリクエストの一覧をリクエストＩＤのリストとして取得する。例えば、図２でいうと、「１」、「２」、「３」、「４」というリクエストＩＤと、それぞれのＵＲＬが取得される。
ｍ６において、メモリ使用量制御部１０８は、ｍ５で取得したリクエストＩＤをオブジェクト管理部１１５に通知する。
ｍ７において、オブジェクト管理部１１５は、ｍ６で受信したリクエストＩＤそれぞれについて、そのリクエストＩＤが作成したオブジェクトの一覧を、オブジェクト管理テーブル１１４を参照して取得する。そして、オブジェクト管理部１１５は、リクエストＩＤごとに取得したすべてのオブジェクトのメモリ使用量の合計を算出し、その合計をメモリ使用量制御部１０８に返却する。メモリ使用量制御部１０８は、現在実行中のすべてのリクエストのメモリ使用量（オブジェクト管理部１１５から返却されたメモリ使用量）を合計することで、ＤＲＣを算出する。
例えば、オブジェクト管理部１１５は、リクエストＩＤ「１」を受け取った場合、オブジェクト管理テーブル１１４のリクエストＩＤフィールド３０２の値が「１」になっているレコード３１１とレコード３１２とを取得し、その各レコードのオブジェクトサイズ３０３の和（9034+883=9917（bytes））を、リクエストＩＤ「１」のＤＲＣ成分としてメモリ使用量制御部１０８に返却する。同様に、オブジェクト管理部１１５は、リクエストＩＤ「２」のＤＲＣ成分「129（bytes）」と、リクエストＩＤ「４」のＤＲＣ成分「2009（bytes）」とを求め、メモリ使用量制御部１０８に返却する。メモリ使用量制御部１０８は、これらのＤＲＣ成分の和（9917＋129＋2009＝12055（bytes））を、ＤＲＣとして算出する。
ｍ８において、メモリ使用量制御部１０８は、ｍ５で取得した現在実行されているリクエストについて、最大サイズ情報ファイル１２２のＧＣ前最大使用量フィールド５０２、または、ＧＣ後最大使用量フィールド５０３を参照することにより、参照した最大使用量をＤＲＭとして取得する。これにより、ＤＲＩ＝ＤＲＭ−ＤＲＣが計算できる。
例えば、現在実行されているリクエスト「１」のＵＲＬフィールド２０２「/example/index.jsp」と一致するＵＲＬフィールド５０１のレコード５１１を求め、そのレコード５１１のＧＣ前最大使用量５０２「20034(byte)」と、ＧＣ後最大使用量５０３「10028(byte)」とを、リクエスト「１」のＤＲＭ成分として取得する。
同様に、他のリクエスト「２，３，４」についても、ＵＲＬフィールド２０２からＵＲＬフィールド５０１を検索することにより、対応するＧＣ前最大使用量５０２とＧＣ後最大使用量５０３とを、リクエストごとのＤＲＭ成分として取得する。
同様に、他のリクエスト「２，３，４」についても、ＵＲＬフィールド２０２からＵＲＬフィールド５０１を検索することにより、対応するＧＣ前最大使用量５０２とＧＣ後最大使用量５０３とを、リクエストごとのＤＲＭ成分として取得する。
さらに、ＤＲＭは、各リクエストのＤＲＭ成分の和によって、計算される。
ＧＣ前のＤＲＭは、リクエスト「１」のＤＲＭ成分（20034）＋リクエスト「２」のＤＲＭ成分（8099012）＋リクエスト「３」のＤＲＭ成分（20034）＋リクエスト「４」のＤＲＭ成分（4098）＝8143178(byte)である。
ＧＣ後のＤＲＭは、リクエスト「１」のＤＲＭ成分（10028）＋リクエスト「２」のＤＲＭ成分（51582）＋リクエスト「３」のＤＲＭ成分（10028）＋リクエスト「４」のＤＲＭ成分（3100）＝74738(byte)である。
ＧＣ前のＤＲＭは、リクエスト「１」のＤＲＭ成分（20034）＋リクエスト「２」のＤＲＭ成分（8099012）＋リクエスト「３」のＤＲＭ成分（20034）＋リクエスト「４」のＤＲＭ成分（4098）＝8143178(byte)である。
ＧＣ後のＤＲＭは、リクエスト「１」のＤＲＭ成分（10028）＋リクエスト「２」のＤＲＭ成分（51582）＋リクエスト「３」のＤＲＭ成分（10028）＋リクエスト「４」のＤＲＭ成分（3100）＝74738(byte)である。
さらに、メモリ使用量制御部１０８は、ｍ４で通知された新規リクエストのＵＲＬをもとに、最大サイズ情報ファイル１２２のＧＣ前最大使用量フィールド５０２、または、ＧＣ後最大使用量フィールド５０３を参照することにより、参照した最大使用量をＤＮＭとして取得する。
ｍ９において、メモリ使用量制御部１０８は、Ｊａｖａ ＡＰＩ１２０を使用して、現在の空きメモリ量をＲＳＣとして取得する。そして、メモリ使用量制御部１０８は、図６（ｃ）の説明で示した判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」をもとに、新規リクエストが実行可能かどうか判断する。この判別式の１回目の判定処理では、判別式のＤＮＭとして、ＧＣ前最大使用量フィールド５０２を使用する。
メモリ使用量制御部１０８は、リクエスト実行可能と判断した場合、リクエスト制御部１０４にリクエストを実行するよう通知する。
メモリ使用量制御部１０８は、リクエスト実行可能と判断した場合、リクエスト制御部１０４にリクエストを実行するよう通知する。
一方、メモリ使用量制御部１０８は、リクエスト実行可能と判断した場合、ＧＣ処理によって、ＲＳＣを増加させることで、判別式の２回目の判定処理を行う。
ｍ１０ａにおいて、メモリ使用量制御部１０８は、空きメモリを増やすために、Ｊａｖａ ＡＰＩ１２０にＧＣの発行を要求する。
ｍ１０ｂにおいて、メモリ使用量制御部１０８は、オブジェクト管理部１１５を介して、オブジェクト管理テーブル１１４から、ＧＣ発行後で更新されたＤＲＣを取得する。これにより、ＤＲＩ＝ＤＲＭ−ＤＲＣを更新する。
ｍ１０ｃにおいて、メモリ使用量制御部１０８は、Ｊａｖａ ＡＰＩ１２０を使用して、ＧＣ発行後で更新されたＲＳＣを取得する。
そして、メモリ使用量制御部１０８は、判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」をもとに、新規リクエストが実行可能かどうか判断する。この判別式の２回目の判定処理では、判別式のＤＮＭとして、ＧＣ後最大使用量フィールド５０３を使用するとともに、ｍ１０ａで更新されたＤＲＩと、ｍ１０ｃで更新されたＲＳＣとを使用する。
メモリ使用量制御部１０８は、リクエスト実行可能と判断した場合、リクエスト制御部１０４にリクエストを実行するよう通知する。２回目の判定処理も満たさなかったときには、リクエスト制御部１０４は、メモリ使用量制御部１０８からリクエスト実行不可能という通知が返却され、リクエスト受付部１０２を介して端末１０にリソース不足によるエラーを通知する。
ｍ１０ａにおいて、メモリ使用量制御部１０８は、空きメモリを増やすために、Ｊａｖａ ＡＰＩ１２０にＧＣの発行を要求する。
ｍ１０ｂにおいて、メモリ使用量制御部１０８は、オブジェクト管理部１１５を介して、オブジェクト管理テーブル１１４から、ＧＣ発行後で更新されたＤＲＣを取得する。これにより、ＤＲＩ＝ＤＲＭ−ＤＲＣを更新する。
ｍ１０ｃにおいて、メモリ使用量制御部１０８は、Ｊａｖａ ＡＰＩ１２０を使用して、ＧＣ発行後で更新されたＲＳＣを取得する。
そして、メモリ使用量制御部１０８は、判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」をもとに、新規リクエストが実行可能かどうか判断する。この判別式の２回目の判定処理では、判別式のＤＮＭとして、ＧＣ後最大使用量フィールド５０３を使用するとともに、ｍ１０ａで更新されたＤＲＩと、ｍ１０ｃで更新されたＲＳＣとを使用する。
メモリ使用量制御部１０８は、リクエスト実行可能と判断した場合、リクエスト制御部１０４にリクエストを実行するよう通知する。２回目の判定処理も満たさなかったときには、リクエスト制御部１０４は、メモリ使用量制御部１０８からリクエスト実行不可能という通知が返却され、リクエスト受付部１０２を介して端末１０にリソース不足によるエラーを通知する。
ｍ１１において、１回目または２回目の判定処理のいずれかを満たすときには、リクエスト制御部１０４は、新規リクエストのリクエストＩＤとリクエストＵＲＬとをプログラム処理部１０５に通知し、コンテナ処理部１０６に制御を移す。
ｍ１２において、コンテナ処理部１０６は、ｍ１１で受け取ったリクエストＩＤとリクエストＵＲＬとを、実行中リクエスト管理テーブル１１６に格納する。例えば、ｍ１において、リクエスト受付部１０２が受け付けたリクエストのＵＲＬが「/example/index.jsp」、ｍ２で生成されたリクエストＩＤを「１」とすると、図２のレコード２１１のように格納する。そして、コンテナ処理部１０６は、ユーザ処理部１０７に制御を移す。
ｍ１２において、コンテナ処理部１０６は、ｍ１１で受け取ったリクエストＩＤとリクエストＵＲＬとを、実行中リクエスト管理テーブル１１６に格納する。例えば、ｍ１において、リクエスト受付部１０２が受け付けたリクエストのＵＲＬが「/example/index.jsp」、ｍ２で生成されたリクエストＩＤを「１」とすると、図２のレコード２１１のように格納する。そして、コンテナ処理部１０６は、ユーザ処理部１０７に制御を移す。
ｍ１３において、ユーザ処理部１０７は、オブジェクトを生成する場合、オブジェクト管理部１１５に対して、新規リクエストのリクエストＩＤと、そのリクエストが使用するオブジェクトの作成要求を通知する。
ｍ１４において、オブジェクト管理部１１５は、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを、ｍ１３で受信した作成要求のオブジェクト用に採番する。
ｍ１５において、オブジェクト管理部１１５は、ユーザメモリ領域１１１内に、オブジェクト１１２を作成する。
ｍ１６において、オブジェクト管理部１１５は、ｍ１５のオブジェクトＩＤのメモリ使用量と、ｍ１３のリクエストＩＤとを対応づけて、オブジェクト管理テーブル１１４に格納する。例えば、オブジェクト管理部１１５は、ｍ１３のリクエストＩＤ「１」と、ｍ１５のオブジェクトＩＤ「２」、そのオブジェクトＩＤ「２」のメモリ使用量「883（bytes）」とを対応づけて、レコード３１２として格納する。
ｍ１７において、オブジェクト管理部１１５は、作成したオブジェクト１１２への参照をユーザ処理部１０７に返却し、ユーザ処理部１０７がオブジェクト１１２を使用する。
ｍ１４において、オブジェクト管理部１１５は、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを、ｍ１３で受信した作成要求のオブジェクト用に採番する。
ｍ１５において、オブジェクト管理部１１５は、ユーザメモリ領域１１１内に、オブジェクト１１２を作成する。
ｍ１６において、オブジェクト管理部１１５は、ｍ１５のオブジェクトＩＤのメモリ使用量と、ｍ１３のリクエストＩＤとを対応づけて、オブジェクト管理テーブル１１４に格納する。例えば、オブジェクト管理部１１５は、ｍ１３のリクエストＩＤ「１」と、ｍ１５のオブジェクトＩＤ「２」、そのオブジェクトＩＤ「２」のメモリ使用量「883（bytes）」とを対応づけて、レコード３１２として格納する。
ｍ１７において、オブジェクト管理部１１５は、作成したオブジェクト１１２への参照をユーザ処理部１０７に返却し、ユーザ処理部１０７がオブジェクト１１２を使用する。
ｍ１８において、ユーザ処理部１０７によるリクエストの処理が終了したら、コンテナ処理部１０６は、実行中リクエスト管理テーブル１１６から終了したリクエストについての情報を削除する。例えば、ｍ１２で登録したリクエストＩＤが「１」である図２のレコード２１１を、削除する。そして、コンテナ処理部１０６は、リクエスト受付部１０２を介して端末１０にレスポンスを返却する。
さらに、以下に示す処理により、終了したリクエストが使用していたオブジェクトをＧＣ処理により解放することで、新規リクエストを受け付けやすくする。
ｍ１９において、オブジェクト管理部１１５は、ＧＣ処理部１２１からオブジェクト解放要求を受け付ける。
ｍ２０において、オブジェクト管理部１１５は、オブジェクト１１２をユーザメモリ領域１１１から解放（削除）する。
ｍ２１において、オブジェクト管理部１１５は、オブジェクト管理テーブル１１４からｍ２０のオブジェクト１１２の情報を削除する。
ｍ１９において、オブジェクト管理部１１５は、ＧＣ処理部１２１からオブジェクト解放要求を受け付ける。
ｍ２０において、オブジェクト管理部１１５は、オブジェクト１１２をユーザメモリ領域１１１から解放（削除）する。
ｍ２１において、オブジェクト管理部１１５は、オブジェクト管理テーブル１１４からｍ２０のオブジェクト１１２の情報を削除する。
図８は、テストモードにおける構成要素間のメッセージの流れを示す説明図である。
ｎ１において、リクエスト受付部１０２は、端末１０からのリクエストを受け付ける。
ｎ２において、リクエスト受付部１０２は、ｎ１で受け付けたリクエストを一意に識別するリクエストＩＤをリクエストＩＤ採番部１０３に生成させる。
ｎ３において、リクエスト受付部１０２は、ｎ１で受け付けたリクエストのリクエストＩＤとＵＲＬとを引数にして、コンテナ処理部１０６を呼び出す。ここで、ｎ１で受け付けたリクエストは、テストモードにおける実測用のリクエスト（ベンチマーク）であるため、確実に実行される。つまり、図７のメモリ使用量制御部１０８が実行していたような、判別式によるリクエストの実行可否判定は、省略される。
ｎ２において、リクエスト受付部１０２は、ｎ１で受け付けたリクエストを一意に識別するリクエストＩＤをリクエストＩＤ採番部１０３に生成させる。
ｎ３において、リクエスト受付部１０２は、ｎ１で受け付けたリクエストのリクエストＩＤとＵＲＬとを引数にして、コンテナ処理部１０６を呼び出す。ここで、ｎ１で受け付けたリクエストは、テストモードにおける実測用のリクエスト（ベンチマーク）であるため、確実に実行される。つまり、図７のメモリ使用量制御部１０８が実行していたような、判別式によるリクエストの実行可否判定は、省略される。
ｎ４において、コンテナ処理部１０６は、ｎ３で受信したリクエストＩＤとＵＲＬとを実行中リクエスト管理テーブル１１６に格納し、ユーザ処理部１０７を呼び出す。
以下、図８のｎ５〜ｎ１０の各処理は、図７のｍ１３〜ｍ１８の各処理と同じである。例えば、ｎ５の処理は、ｍ１３の処理と同じである。
以下、図８のｎ５〜ｎ１０の各処理は、図７のｍ１３〜ｍ１８の各処理と同じである。例えば、ｎ５の処理は、ｍ１３の処理と同じである。
以下、テストモードにおける最大サイズ管理テーブル１１８（ＧＣ前最大使用量フィールド４０２）の更新処理を説明する。
ｎ１１において、ＧＣ処理部１２１は、最大メモリ使用量計算部１１７に対して現在のメモリ使用量の取得を要求する。
ｎ１２において、最大メモリ使用量計算部１１７は、実行中リクエスト管理テーブル１１６を参照して実行中のリクエストの一覧（例えば、レコード２１１、レコード２１２、レコード２１３、レコード２１４）を取得する。
ｎ１３において、最大メモリ使用量計算部１１７は、取得したすべてのリクエストについてオブジェクト管理部１１５にリクエストＩＤを通知し、各リクエストが使用しているメモリ使用量の取得を行う。
ｎ１４において、最大メモリ使用量計算部１１７は、最大サイズ管理テーブル１１８を参照してＧＣ前最大使用量フィールド４０２の情報を取得し、取得した値（リクエストＩＤ「１」では、20034bytes）が現在のリクエストのメモリ使用量（リクエストＩＤ「１」では、9034+883=9917bytes）よりも小さければ、ＧＣ前最大使用量フィールド４０２の値を、現在のリクエストのメモリ使用量で更新する（リクエストＩＤ「１」では、更新せず）。
ｎ１１において、ＧＣ処理部１２１は、最大メモリ使用量計算部１１７に対して現在のメモリ使用量の取得を要求する。
ｎ１２において、最大メモリ使用量計算部１１７は、実行中リクエスト管理テーブル１１６を参照して実行中のリクエストの一覧（例えば、レコード２１１、レコード２１２、レコード２１３、レコード２１４）を取得する。
ｎ１３において、最大メモリ使用量計算部１１７は、取得したすべてのリクエストについてオブジェクト管理部１１５にリクエストＩＤを通知し、各リクエストが使用しているメモリ使用量の取得を行う。
ｎ１４において、最大メモリ使用量計算部１１７は、最大サイズ管理テーブル１１８を参照してＧＣ前最大使用量フィールド４０２の情報を取得し、取得した値（リクエストＩＤ「１」では、20034bytes）が現在のリクエストのメモリ使用量（リクエストＩＤ「１」では、9034+883=9917bytes）よりも小さければ、ＧＣ前最大使用量フィールド４０２の値を、現在のリクエストのメモリ使用量で更新する（リクエストＩＤ「１」では、更新せず）。
以下、テストモードにおけるＧＣ処理後の最大サイズ管理テーブル１１８（ＧＣ後最大使用量フィールド４０３）の更新処理を説明する。
ｎ１５において、ＧＣ処理部１２１は、既存のＧＣ処理と同様にオブジェクト管理部１１５に対して不要なオブジェクト１１２の削除を要求する。
ｎ１６において、オブジェクト管理部１１５では、ｎ１５で要求されたオブジェクト１１２をユーザメモリ領域１１１から削除する。例えば、オブジェクトＩＤが「２」のオブジェクトを削除する場合は、図３のレコード３１２を削除されることになる。
ｎ１７において、ｎ１６で削除されたオブジェクト１１２について、オブジェクト管理テーブル１１４からその情報を削除し、ＧＣ処理部１２１に制御を戻す。そして、ＧＣ処理部１２１は、ＧＣ処理（ｎ１５〜ｎ１７）により不要なオブジェクトを解放したので、ふたたび最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）を行う。
そして、最大メモリ使用量計算部１１７は、最大サイズ管理テーブル１１８を参照してＧＣ後最大使用量フィールド４０３の情報を取得し、ＧＣ後最大使用量フィールド４０３のメモリ使用量（リクエストＩＤ「１」では、10028bytes）が、最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）によって取得したメモリ使用量（リクエストＩＤ「１」では、9034+883=9917bytes）よりも小さければ、ＧＣ後最大使用量フィールド４０３の値を、最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）によって取得したメモリ使用量で更新する（リクエストＩＤ「１」では、更新せず）。
ｎ１５において、ＧＣ処理部１２１は、既存のＧＣ処理と同様にオブジェクト管理部１１５に対して不要なオブジェクト１１２の削除を要求する。
ｎ１６において、オブジェクト管理部１１５では、ｎ１５で要求されたオブジェクト１１２をユーザメモリ領域１１１から削除する。例えば、オブジェクトＩＤが「２」のオブジェクトを削除する場合は、図３のレコード３１２を削除されることになる。
ｎ１７において、ｎ１６で削除されたオブジェクト１１２について、オブジェクト管理テーブル１１４からその情報を削除し、ＧＣ処理部１２１に制御を戻す。そして、ＧＣ処理部１２１は、ＧＣ処理（ｎ１５〜ｎ１７）により不要なオブジェクトを解放したので、ふたたび最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）を行う。
そして、最大メモリ使用量計算部１１７は、最大サイズ管理テーブル１１８を参照してＧＣ後最大使用量フィールド４０３の情報を取得し、ＧＣ後最大使用量フィールド４０３のメモリ使用量（リクエストＩＤ「１」では、10028bytes）が、最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）によって取得したメモリ使用量（リクエストＩＤ「１」では、9034+883=9917bytes）よりも小さければ、ＧＣ後最大使用量フィールド４０３の値を、最大メモリ使用量の取得処理（ｎ１１〜ｎ１３）によって取得したメモリ使用量で更新する（リクエストＩＤ「１」では、更新せず）。
そして、以下に、更新された最大サイズ管理テーブル１１８を、最大サイズ情報ファイル１２２としてエクスポートする処理を示す。
ｎ１８において、コマンド受付部１０９は、管理者からファイル出力コマンドを受け付けると、コマンド実行部１１０にファイル出力処理を要求する。
ｎ１９において、コマンド実行部１１０は、最大サイズ管理テーブル１１８を参照して全リクエストのＵＲＬ、ＧＣ前最大使用量、ＧＣ後最大使用量の情報を取得する。
ｎ２０において、コマンド実行部１１０は、ｎ１９で取得したデータ内容の形式変換（ＣＳＶ変換）を行った結果を、最大サイズ情報ファイル１２２として出力する。
ｎ１８において、コマンド受付部１０９は、管理者からファイル出力コマンドを受け付けると、コマンド実行部１１０にファイル出力処理を要求する。
ｎ１９において、コマンド実行部１１０は、最大サイズ管理テーブル１１８を参照して全リクエストのＵＲＬ、ＧＣ前最大使用量、ＧＣ後最大使用量の情報を取得する。
ｎ２０において、コマンド実行部１１０は、ｎ１９で取得したデータ内容の形式変換（ＣＳＶ変換）を行った結果を、最大サイズ情報ファイル１２２として出力する。
図９は、手動設定モードにおけるリクエスト処理の概要を示すフローチャートである。
Ｓ１００１として、リクエスト受付部１０２は、端末１０からリクエストを受け付ける。
Ｓ１００２として、リクエストＩＤ採番部１０３は、リクエスト毎に一意なリクエストＩＤを採番し、リクエスト制御部１０４にリクエストＵＲＬとリクエストＩＤとを通知する。
Ｓ１００３として、リクエスト制御部１０４は、リクエスト受付部１０２からリクエストＩＤとリクエストのＵＲＬを受け取り、リクエストが実行可能かどうかを判断するために、メモリ使用量制御部１０８にリクエストＵＲＬを通知して制御を移す。
Ｓ１００４として、メモリ使用量制御部１０８は、メモリ使用量制御処理として、新規リクエストの実行可否判定処理（詳細は図１０）を行う。
Ｓ１００５として、リクエスト制御部１０４は、Ｓ１００４の判定結果をメモリ使用量制御部１０８から受信し、その判定結果がリクエスト実行可能なら（Ｓ１００５，Ｙｅｓ）Ｓ１００６へ進み、リクエスト実行不可能なら（Ｓ１００５，Ｎｏ）Ｓ１００９へ進む。
Ｓ１００２として、リクエストＩＤ採番部１０３は、リクエスト毎に一意なリクエストＩＤを採番し、リクエスト制御部１０４にリクエストＵＲＬとリクエストＩＤとを通知する。
Ｓ１００３として、リクエスト制御部１０４は、リクエスト受付部１０２からリクエストＩＤとリクエストのＵＲＬを受け取り、リクエストが実行可能かどうかを判断するために、メモリ使用量制御部１０８にリクエストＵＲＬを通知して制御を移す。
Ｓ１００４として、メモリ使用量制御部１０８は、メモリ使用量制御処理として、新規リクエストの実行可否判定処理（詳細は図１０）を行う。
Ｓ１００５として、リクエスト制御部１０４は、Ｓ１００４の判定結果をメモリ使用量制御部１０８から受信し、その判定結果がリクエスト実行可能なら（Ｓ１００５，Ｙｅｓ）Ｓ１００６へ進み、リクエスト実行不可能なら（Ｓ１００５，Ｎｏ）Ｓ１００９へ進む。
Ｓ１００６として、コンテナ処理部１０６は、リクエストＩＤとリクエストＵＲＬの文字列とをリクエスト制御部１０４から受信し、それらの情報を実行中リクエスト管理テーブル１１６に格納する。
Ｓ１００７として、コンテナ処理部１０６は、ユーザ処理部１０７に対して、Ｓ１００１で受け付けたリクエストの実行を指示する（詳細は図１３）。
Ｓ１００８として、コンテナ処理部１０６は、Ｓ１００７の処理を終えた後、実行中リクエスト管理テーブル１１６からＳ１００７で実行したリクエストの情報を削除する。これにより、実行中リクエスト管理テーブル１１６には、現在実行しているリクエストの情報だけが格納される。
Ｓ１００９として、リクエスト受付部１０２は、端末１０に対して、Ｓ１００１のリクエストに対するレスポンス（応答）を返却する。このレスポンスは、Ｓ１００５でＹｅｓに分岐したときには、コンテナ処理部１０６から報告を受けたリクエストの正常実行の通知とし、Ｓ１００５でＮｏに分岐したときには、エラーとする。
Ｓ１００７として、コンテナ処理部１０６は、ユーザ処理部１０７に対して、Ｓ１００１で受け付けたリクエストの実行を指示する（詳細は図１３）。
Ｓ１００８として、コンテナ処理部１０６は、Ｓ１００７の処理を終えた後、実行中リクエスト管理テーブル１１６からＳ１００７で実行したリクエストの情報を削除する。これにより、実行中リクエスト管理テーブル１１６には、現在実行しているリクエストの情報だけが格納される。
Ｓ１００９として、リクエスト受付部１０２は、端末１０に対して、Ｓ１００１のリクエストに対するレスポンス（応答）を返却する。このレスポンスは、Ｓ１００５でＹｅｓに分岐したときには、コンテナ処理部１０６から報告を受けたリクエストの正常実行の通知とし、Ｓ１００５でＮｏに分岐したときには、エラーとする。
図１０は、Ｓ１００４から呼び出される処理であり、メモリ使用量制御処理の詳細を示すフローチャートである。以下の説明では、図１０の各処理の動作の主体は、メモリ使用量制御部１０８である。
Ｓ１１０１として、リクエスト制御部１０４から、実行しようとしているリクエストのＵＲＬ情報を受け取る。
Ｓ１１０２として、実行中リクエスト管理テーブル１１６を参照し、実行中リクエストＩＤの一覧を取得する。
Ｓ１１０３として、実行中の全てのリクエストの現時点でのメモリ使用量（ＤＲＣ）を計算するため、実行中のリクエストＩＤ一覧を引数として、図１１の処理を呼び出す。
Ｓ１１０４として、最大サイズ情報ファイル１２２を参照し、Ｓ１１０３で計算した実行中リクエストのＵＲＬ情報に対応するＧＣ前最大使用量およびＧＣ後最大使用量をＤＲＭとして取得するとともに、Ｓ１１０１で受け取ったリクエストのＵＲＬ情報に対応するＧＣ前最大使用量およびＧＣ後最大使用量をＤＮＭとして取得する。
Ｓ１１０５として、Ｊａｖａ ＡＰＩ１２０を実行して、現在空きメモリ量（ＲＳＣ）を取得する。
Ｓ１１０２として、実行中リクエスト管理テーブル１１６を参照し、実行中リクエストＩＤの一覧を取得する。
Ｓ１１０３として、実行中の全てのリクエストの現時点でのメモリ使用量（ＤＲＣ）を計算するため、実行中のリクエストＩＤ一覧を引数として、図１１の処理を呼び出す。
Ｓ１１０４として、最大サイズ情報ファイル１２２を参照し、Ｓ１１０３で計算した実行中リクエストのＵＲＬ情報に対応するＧＣ前最大使用量およびＧＣ後最大使用量をＤＲＭとして取得するとともに、Ｓ１１０１で受け取ったリクエストのＵＲＬ情報に対応するＧＣ前最大使用量およびＧＣ後最大使用量をＤＮＭとして取得する。
Ｓ１１０５として、Ｊａｖａ ＡＰＩ１２０を実行して、現在空きメモリ量（ＲＳＣ）を取得する。
Ｓ１１０６として、１回目の判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」を満たすか否かを判定する。なお、判別式左辺のＤＲＩは、Ｓ１１０４で取得したＤＲＭとしてのＧＣ前最大使用量から、Ｓ１１０３で取得したＤＲＣを減算した結果である。また、判別式左辺のＤＮＭとして、Ｓ１１０４で取得したＤＮＭとしてのＧＣ前最大使用量を使用する。この判別式を満たすときにはＳ１１１１へ進み、判別式を満たさないときにはＳ１１０７へ進む。
Ｓ１１０７として、空きメモリを増やすために、Ｊａｖａ ＡＰＩ１２０にＦｕｌｌＧＣの実行を要求する。
Ｓ１１０８として、ＦｕｌｌＧＣ実行後に、再びＳ１１０３の処理を実行する。
Ｓ１１０９として、再びＳ１１０５の処理を実行する。
Ｓ１１１０として、２回目の判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」を満たすか否かを判定する。なお、判別式左辺のＤＲＩは、Ｓ１１０４で取得したＤＲＭとしてのＧＣ後最大使用量から、Ｓ１１０８で取得したＤＲＣを減算した結果である。また、判別式左辺のＤＮＭとして、Ｓ１１０４で取得したＤＮＭとしてのＧＣ後最大使用量を使用する。この判別式を満たすときにはＳ１１１１へ進み、判別式を満たさないときにはＳ１１１２へ進む。
Ｓ１１０８として、ＦｕｌｌＧＣ実行後に、再びＳ１１０３の処理を実行する。
Ｓ１１０９として、再びＳ１１０５の処理を実行する。
Ｓ１１１０として、２回目の判別式「（ＤＲＩ）＋（ＤＮＭ）＜（ＲＳＣ）」を満たすか否かを判定する。なお、判別式左辺のＤＲＩは、Ｓ１１０４で取得したＤＲＭとしてのＧＣ後最大使用量から、Ｓ１１０８で取得したＤＲＣを減算した結果である。また、判別式左辺のＤＮＭとして、Ｓ１１０４で取得したＤＮＭとしてのＧＣ後最大使用量を使用する。この判別式を満たすときにはＳ１１１１へ進み、判別式を満たさないときにはＳ１１１２へ進む。
Ｓ１１１１として、Ｓ１１０１で受け取ったリクエストを実行可能と判断し、リクエスト制御部１０４にその判断結果を通知する。
Ｓ１１１２として、Ｓ１１０１で受け取ったリクエストをメモリ不足により実行不可能と判断し、リクエスト制御部１０４にその判断結果を通知する。
Ｓ１１１２として、Ｓ１１０１で受け取ったリクエストをメモリ不足により実行不可能と判断し、リクエスト制御部１０４にその判断結果を通知する。
図１１は、Ｓ１１０３およびＳ１１０８から実行中の全リクエストのリクエストＩＤを引数として呼び出される処理であり、実行中全リクエストのメモリ使用量を計算する処理の詳細を示すフローチャートである。以下の説明では、図１１の各処理の動作の主体は、メモリ使用量制御部１０８である。
Ｓ１２０１として、メモリ使用量制御部１０８では、引数として受け取った実行中のリクエストＩＤを順に一つずつ選択するループを開始する。
Ｓ１２０２として、選択されたリクエストＩＤを引数として図１２の処理を呼び出し、そのリクエストＩＤのメモリ使用量の計算を行う。
Ｓ１２０３として、Ｓ１２０１のループを終了する。
Ｓ１２０４として、Ｓ１２０２でそれぞれ計算したメモリ使用量を合計し、その合計値を実行中全リクエストのメモリ使用量として呼び出し元に返却する。
Ｓ１２０１として、メモリ使用量制御部１０８では、引数として受け取った実行中のリクエストＩＤを順に一つずつ選択するループを開始する。
Ｓ１２０２として、選択されたリクエストＩＤを引数として図１２の処理を呼び出し、そのリクエストＩＤのメモリ使用量の計算を行う。
Ｓ１２０３として、Ｓ１２０１のループを終了する。
Ｓ１２０４として、Ｓ１２０２でそれぞれ計算したメモリ使用量を合計し、その合計値を実行中全リクエストのメモリ使用量として呼び出し元に返却する。
図１２は、Ｓ１２０２から実行中のリクエストのリクエストＩＤを引数として呼び出される処理であり、そのリクエストのメモリ使用量を計算する処理の詳細を示すフローチャートである。以下の説明では、図１２の各処理の動作の主体は、オブジェクト管理部１１５である。
Ｓ１３０１として、引数のリクエストＩＤをメモリ使用量制御部１０８から受け取る。
Ｓ１３０２として、オブジェクト管理テーブル１１４を参照して、Ｓ１３０１のリクエストＩＤに対応するオブジェクトの一覧を取得する。
Ｓ１３０３として、Ｓ１３０２に取得したすべてのオブジェクトについて、そのオブジェクトのメモリ使用量の合計を算出し、算出結果を要求元に返却する。
Ｓ１３０１として、引数のリクエストＩＤをメモリ使用量制御部１０８から受け取る。
Ｓ１３０２として、オブジェクト管理テーブル１１４を参照して、Ｓ１３０１のリクエストＩＤに対応するオブジェクトの一覧を取得する。
Ｓ１３０３として、Ｓ１３０２に取得したすべてのオブジェクトについて、そのオブジェクトのメモリ使用量の合計を算出し、算出結果を要求元に返却する。
図１３は、Ｓ１００７からリクエストＩＤを引数として呼び出される処理であり、そのリクエストの実行処理の詳細を示すフローチャートである。以下の説明では、図１３の各処理の動作の主体は、Ｓ１４０４以外は、ユーザ処理部１０７である。
Ｓ１４０１として、引数のリクエストに従って、ユーザの作成したＪａｖａプログラムの処理を順に実行するループを開始する。
Ｓ１４０２として、ループで選択されたプログラムの処理を実行する。
Ｓ１４０３として、Ｓ１４０２の処理がオブジェクトを生成する処理であるか否かを判定する。Ｓ１４０３でＹｅｓならＳ１４０４へ進み、Ｓ１４０３でＮｏならＳ１４０５へ進む。
Ｓ１４０４として、ユーザ処理部１０７は、オブジェクト管理部１１５に対してリクエストＩＤを通知してオブジェクト１１２の作成を要求する。要求を受けたオブジェクト管理部１１５は、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを採番してそのオブジェクトＩＤで示されるオブジェクト１１２を生成する。さらに、オブジェクト管理部１１５は、採番したオブジェクトＩＤと、通知されたリクエストＩＤと、生成したオブジェクト１１２のメモリ使用量とを対応づけて、オブジェクト管理テーブル１１４に格納する。
Ｓ１４０５として、Ｓ１４０１のループを終了する。
Ｓ１４０１として、引数のリクエストに従って、ユーザの作成したＪａｖａプログラムの処理を順に実行するループを開始する。
Ｓ１４０２として、ループで選択されたプログラムの処理を実行する。
Ｓ１４０３として、Ｓ１４０２の処理がオブジェクトを生成する処理であるか否かを判定する。Ｓ１４０３でＹｅｓならＳ１４０４へ進み、Ｓ１４０３でＮｏならＳ１４０５へ進む。
Ｓ１４０４として、ユーザ処理部１０７は、オブジェクト管理部１１５に対してリクエストＩＤを通知してオブジェクト１１２の作成を要求する。要求を受けたオブジェクト管理部１１５は、オブジェクトＩＤ採番部１１９で一意なオブジェクトＩＤを採番してそのオブジェクトＩＤで示されるオブジェクト１１２を生成する。さらに、オブジェクト管理部１１５は、採番したオブジェクトＩＤと、通知されたリクエストＩＤと、生成したオブジェクト１１２のメモリ使用量とを対応づけて、オブジェクト管理テーブル１１４に格納する。
Ｓ１４０５として、Ｓ１４０１のループを終了する。
図１４は、テストモードにおけるリクエスト処理の概要を示すフローチャートである。図９の手動設定モードにおける処理と比較すると、メモリ使用量制御部１０８に関する処理（Ｓ１００３〜Ｓ１００５）が不要になる。
図１５は、ＧＣ処理部１２１が実行するＧＣ処理を示すフローチャートである。このＧＣ処理が実行される契機は、例えば、Ｊａｖａがメモリ不足状態を検知したときである。
Ｓ２００１として、不要になったオブジェクトを解放するオブジェクトとして決定する。
Ｓ２００２として、最大サイズ管理テーブル１１８内のＧＣ前最大使用量の更新処理（図１６）を呼び出す。
Ｓ２００３として、ＧＣ処理として、Ｓ２００１で解放対象とされたオブジェクト１１２の解放処理を行う。この解放処理に伴い、解放したオブジェクト１１２の情報を、オブジェクト管理テーブル１１４から削除する。
Ｓ２００４として、最大サイズ管理テーブル１１８内のＧＣ後最大使用量の更新処理（図１７）を呼び出す。
Ｓ２００１として、不要になったオブジェクトを解放するオブジェクトとして決定する。
Ｓ２００２として、最大サイズ管理テーブル１１８内のＧＣ前最大使用量の更新処理（図１６）を呼び出す。
Ｓ２００３として、ＧＣ処理として、Ｓ２００１で解放対象とされたオブジェクト１１２の解放処理を行う。この解放処理に伴い、解放したオブジェクト１１２の情報を、オブジェクト管理テーブル１１４から削除する。
Ｓ２００４として、最大サイズ管理テーブル１１８内のＧＣ後最大使用量の更新処理（図１７）を呼び出す。
図１６は、Ｓ２００２から呼び出されるＧＣ前最大使用量の更新処理の詳細を示すフローチャートである。以下の説明では、図１６の各処理の動作の主体は、最大メモリ使用量計算部１１７である。
Ｓ２１０１として、実行中リクエスト管理テーブル１１６を参照し、実行中のリクエストの一覧を取得する。
Ｓ２１０２として、Ｓ２１０１で取得した実行中リクエストを一つずつ選択するループを開始する。
Ｓ１２０２として、図１２で説明した現在のメモリ使用量の取得処理を呼び出す。
Ｓ２１０３として、Ｓ２１０２で選択した実行中リクエストのＵＲＬが最大サイズ管理テーブル１１８に登録済みであるか否かを判定する。Ｓ２１０３でＹｅｓならＳ２１０４へ進み、Ｓ２１０３でＮｏならＳ２１０５へ進む。
Ｓ２１０４として、最大サイズ管理テーブル１１８からＧＣ前最大使用量フィールド４０２の値を取得し、取得した値がＳ１２０２で計算したメモリ使用量よりも小さいか否かを判定する。Ｓ２１０４でＹｅｓならＳ２１０５へ進み、Ｓ２１０４でＮｏならＳ２１０６へ進む。
Ｓ２１０５として、最大サイズ管理テーブル１１８のＧＣ前最大使用量フィールド４０２に、Ｓ１２０２で計算したメモリ使用量を登録（上書き更新）する。
Ｓ２１０６として、Ｓ２１０２からのループを終了する。
Ｓ２１０１として、実行中リクエスト管理テーブル１１６を参照し、実行中のリクエストの一覧を取得する。
Ｓ２１０２として、Ｓ２１０１で取得した実行中リクエストを一つずつ選択するループを開始する。
Ｓ１２０２として、図１２で説明した現在のメモリ使用量の取得処理を呼び出す。
Ｓ２１０３として、Ｓ２１０２で選択した実行中リクエストのＵＲＬが最大サイズ管理テーブル１１８に登録済みであるか否かを判定する。Ｓ２１０３でＹｅｓならＳ２１０４へ進み、Ｓ２１０３でＮｏならＳ２１０５へ進む。
Ｓ２１０４として、最大サイズ管理テーブル１１８からＧＣ前最大使用量フィールド４０２の値を取得し、取得した値がＳ１２０２で計算したメモリ使用量よりも小さいか否かを判定する。Ｓ２１０４でＹｅｓならＳ２１０５へ進み、Ｓ２１０４でＮｏならＳ２１０６へ進む。
Ｓ２１０５として、最大サイズ管理テーブル１１８のＧＣ前最大使用量フィールド４０２に、Ｓ１２０２で計算したメモリ使用量を登録（上書き更新）する。
Ｓ２１０６として、Ｓ２１０２からのループを終了する。
図１７は、Ｓ２００４から呼び出されるＧＣ後最大使用量の更新処理の詳細を示すフローチャートである。以下の説明では、図１７の各処理の動作の主体は、最大メモリ使用量計算部１１７である。図１７の処理は、図１６の処理と類似するが、図１６のＳ２１０３〜Ｓ２１０５の処理が、図１７のＳ２２０１〜Ｓ２２０２の処理に置き換わっている。
Ｓ２２０１として、最大サイズ管理テーブル１１８に格納されているＧＣ後最大使用量フィールド４０３の値が、Ｓ１２０２で計算したメモリ使用量よりも小さいか否かを判定する。Ｓ２２０１でＹｅｓならＳ２２０２へ進み、Ｓ２２０１でＮｏならＳ２１０６へ進む。
Ｓ２２０２として、最大サイズ管理テーブル１１８のＧＣ後最大使用量フィールド４０３に、Ｓ１２０２で計算したメモリ使用量を登録（上書き更新）する。
Ｓ２２０１として、最大サイズ管理テーブル１１８に格納されているＧＣ後最大使用量フィールド４０３の値が、Ｓ１２０２で計算したメモリ使用量よりも小さいか否かを判定する。Ｓ２２０１でＹｅｓならＳ２２０２へ進み、Ｓ２２０１でＮｏならＳ２１０６へ進む。
Ｓ２２０２として、最大サイズ管理テーブル１１８のＧＣ後最大使用量フィールド４０３に、Ｓ１２０２で計算したメモリ使用量を登録（上書き更新）する。
以上説明した本実施形態では、メモリ使用量制御部１０８が図６（ｃ）に示す判別式において、現在実行中のリクエストのメモリ使用量の増加分（ＤＲＩ）を用いて、新たなリクエストの実行可否を判定することにより、図６（ｂ）に示すような事後的なメモリ不足を防止することができる。
さらに、テストモードにより、ＤＲＩを実測値として計測することにより、判別式での判定精度を手動設定モードよりも向上させることができる。
さらに、テストモードにより、ＤＲＩを実測値として計測することにより、判別式での判定精度を手動設定モードよりも向上させることができる。
１０ 端末
２０ ネットワーク
３０ 計算機
４０ 通信装置
５０ ＣＰＵ
６０ 入力装置
７０ 出力装置
８０ 補助記憶装置
９０ バス
９５ 主記憶装置
１０１ コンテナ管理領域
１０２ リクエスト受付部
１０３ リクエストＩＤ採番部
１０４ リクエスト制御部
１０５ プログラム処理部
１０６ コンテナ処理部
１０７ ユーザ処理部
１０８ メモリ使用量制御部
１０９ コマンド受付部
１１０ コマンド実行部
１１１ ユーザメモリ領域
１１２ オブジェクト
１１３ ＪａｖａＶＭ管理領域
１１４ オブジェクト管理テーブル
１１５ オブジェクト管理部
１１６ 実行中リクエスト管理テーブル
１１７ 最大メモリ使用量計算部
１１８ 最大サイズ管理テーブル
１１９ オブジェクトＩＤ採番部
１２０ Ｊａｖａ ＡＰＩ
１２１ ＧＣ処理部
１２２ 最大サイズ情報ファイル
２０ ネットワーク
３０ 計算機
４０ 通信装置
５０ ＣＰＵ
６０ 入力装置
７０ 出力装置
８０ 補助記憶装置
９０ バス
９５ 主記憶装置
１０１ コンテナ管理領域
１０２ リクエスト受付部
１０３ リクエストＩＤ採番部
１０４ リクエスト制御部
１０５ プログラム処理部
１０６ コンテナ処理部
１０７ ユーザ処理部
１０８ メモリ使用量制御部
１０９ コマンド受付部
１１０ コマンド実行部
１１１ ユーザメモリ領域
１１２ オブジェクト
１１３ ＪａｖａＶＭ管理領域
１１４ オブジェクト管理テーブル
１１５ オブジェクト管理部
１１６ 実行中リクエスト管理テーブル
１１７ 最大メモリ使用量計算部
１１８ 最大サイズ管理テーブル
１１９ オブジェクトＩＤ採番部
１２０ Ｊａｖａ ＡＰＩ
１２１ ＧＣ処理部
１２２ 最大サイズ情報ファイル
Claims (6)
- 受け付けたリクエストを実行するリクエスト処理装置によるリクエスト処理方法であって、
リクエスト処理装置は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を動作させるＪａｖａアプリケーションサーバであり、
リクエスト処理装置は、ユーザメモリ領域とＪａｖａＶＭ管理領域とを記憶手段内に格納する記憶部と、メモリ使用量制御部とを有しており、
前記ユーザメモリ領域には、リクエストを実行するためのプログラムを具現化したオブジェクトが格納されており、
前記ＪａｖａＶＭ管理領域には、前記ユーザメモリ領域に格納される前記オブジェクトの前記オブジェクトＩＤと、そのオブジェクトが使用するメモリ量と、そのオブジェクトを作成したリクエストのリクエストＩＤとが対応づけて前記オブジェクト管理用データとして格納されるとともに、リクエストＩＤごとにそのリクエストを実行するために使用する最大のメモリ量が対応づけて最大サイズ管理用データとして格納されており、
前記メモリ使用量制御部は、新たに受け付けたリクエストを実行するか否かを判定するときに、
前記最大サイズ管理用データを参照して、現在実行中のリクエストの最大のメモリ量を第１メモリ量として取得し、
前記オブジェクト管理用データを参照して、現在実行中のリクエストのリクエストＩＤに対応する前記オブジェクトが現在使用するメモリ量を第２メモリ量として取得し、前記第２メモリ量から前記第１メモリ量を減算した値を第３メモリ量として計算し、
前記最大サイズ管理用データを参照して、前記新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、
前記ユーザメモリ領域内の現在の空き容量を前記ＪａｖａＶＭから取得し、取得した現在の空き容量が、前記第３メモリ量と前記第４メモリ量との和よりも大きいときには、前記新たに受け付けたリクエストの実行を許可して、そのリクエストの実行を指示することを特徴とする
リクエスト処理方法。 - 前記メモリ使用量制御部は、前記新たに受け付けたリクエストの実行が不許可であると判定されたときには、前記ＪａｖａＶＭにＧＣ（Garbage Collection）を実行させて現在の空き容量を増加させた後、再度、現在の空き容量が、前記第３メモリ量と前記第４メモリ量との和よりも大きいか否かを判定し、大きいと判定されたときには、前記新たに受け付けたリクエストの実行を許可して、そのリクエストの実行を指示することを特徴とする
請求項１に記載のリクエスト処理方法。 - 前記リクエスト処理装置は、前記オブジェクト管理用データを参照して、リクエストＩＤに対応する前記第２メモリ量を取得し、その第２メモリ量の最大値をリクエストＩＤごとに集計し、その集計結果を前記第１メモリ量として前記最大サイズ管理用データに格納することを特徴とする
請求項１または請求項２に記載のリクエスト処理方法。 - 前記リクエスト処理装置は、前記記憶手段に現在実行中のリクエストのリストを記憶し、前記新たに受け付けたリクエストの実行が許可されたときにはそのリクエストをリストに追加し、リクエストの実行が完了したときには、そのリクエストをリストから削除することを特徴とする
請求項１ないし請求項３のいずれか１項に記載のリクエスト処理方法。 - 請求項１ないし請求項４のいずれか１項に記載のリクエスト処理方法を、コンピュータである前記リクエスト処理装置に実行させるためのリクエスト処理プログラム。
- 受け付けたリクエストを実行するリクエスト処理装置であって、
リクエスト処理装置は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を動作させるＪａｖａアプリケーションサーバであり、
リクエスト処理装置は、ユーザメモリ領域とＪａｖａＶＭ管理領域とを記憶手段内に格納する記憶部と、メモリ使用量制御部とを有しており、
前記ユーザメモリ領域には、リクエストを実行するためのプログラムを具現化したオブジェクトが格納されており、
前記ＪａｖａＶＭ管理領域には、前記ユーザメモリ領域に格納される前記オブジェクトの前記オブジェクトＩＤと、そのオブジェクトが使用するメモリ量と、そのオブジェクトを作成したリクエストのリクエストＩＤとが対応づけて前記オブジェクト管理用データとして格納されるとともに、リクエストＩＤごとにそのリクエストを実行するために使用する最大のメモリ量が対応づけて最大サイズ管理用データとして格納されており、
前記メモリ使用量制御部は、新たに受け付けたリクエストを実行するか否かを判定するときに、
前記最大サイズ管理用データを参照して、現在実行中のリクエストの最大のメモリ量を第１メモリ量として取得し、
前記オブジェクト管理用データを参照して、現在実行中のリクエストのリクエストＩＤに対応する前記オブジェクトが現在使用するメモリ量を第２メモリ量として取得し、前記第２メモリ量から前記第１メモリ量を減算した値を第３メモリ量として計算し、
前記最大サイズ管理用データを参照して、前記新たに受け付けたリクエストの最大のメモリ量を第４メモリ量として取得し、
前記ユーザメモリ領域内の現在の空き容量を前記ＪａｖａＶＭから取得し、取得した現在の空き容量が、前記第３メモリ量と前記第４メモリ量との和よりも大きいときには、前記新たに受け付けたリクエストの実行を許可して、そのリクエストの実行を指示することを特徴とする
リクエスト処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010112505A JP2011242890A (ja) | 2010-05-14 | 2010-05-14 | リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010112505A JP2011242890A (ja) | 2010-05-14 | 2010-05-14 | リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2011242890A true JP2011242890A (ja) | 2011-12-01 |
Family
ID=45409493
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010112505A Pending JP2011242890A (ja) | 2010-05-14 | 2010-05-14 | リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2011242890A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014171002A1 (ja) * | 2013-04-19 | 2014-10-23 | 株式会社日立製作所 | メモリ管理方法、計算機及び記録媒体 |
| JP2014239302A (ja) * | 2013-06-06 | 2014-12-18 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
| JP2019204477A (ja) * | 2018-05-17 | 2019-11-28 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
-
2010
- 2010-05-14 JP JP2010112505A patent/JP2011242890A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014171002A1 (ja) * | 2013-04-19 | 2014-10-23 | 株式会社日立製作所 | メモリ管理方法、計算機及び記録媒体 |
| JP2014239302A (ja) * | 2013-06-06 | 2014-12-18 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
| JP2019204477A (ja) * | 2018-05-17 | 2019-11-28 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
| JP7186541B2 (ja) | 2018-05-17 | 2022-12-09 | キヤノン株式会社 | 画像処理装置、その制御方法、及びプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5334226B2 (ja) | スケジュール管理方法及びスケジュール管理サーバ | |
| US6078955A (en) | Method for controlling a computer system including a plurality of computers and a network processed as a user resource | |
| EP2146280A2 (en) | Resource migration system and resource migration method | |
| US8189222B2 (en) | Device system, source device, and transmission method | |
| JP2011118587A (ja) | 複数サーバによる連携サービス実行システム | |
| US11256541B2 (en) | Rescheduling of virtual machine migrations with less impact on an existing migration schedule | |
| JP2012118922A (ja) | 印刷システム、送信制御装置及びプログラム | |
| JP2011242890A (ja) | リクエスト処理方法、リクエスト処理プログラム、および、リクエスト処理装置 | |
| JP6501694B2 (ja) | 計算機システム及び計算機システムのタスク実行方法 | |
| US10845997B2 (en) | Job manager for deploying a bundled application | |
| KR101661789B1 (ko) | 양방향 동기 중에 자기 참조 필드의 동기 | |
| WO2016127577A1 (zh) | 一种处理事件的方法及装置 | |
| JP2008112311A (ja) | ビジネスプロセス実行方法、ビジネスプロセス実行システムおよびプログラム | |
| EP2325791A1 (en) | Business flow distributed processing system and method | |
| JP2002049637A (ja) | データベース管理方法及び装置並びに記録媒体 | |
| JP4249605B2 (ja) | クライアントサーバシステムおよびキャッシュ制御方法ならびにコンピュータプログラム | |
| CN112905541B (zh) | 镜像仓库垃圾清理方法和装置 | |
| JP7162556B2 (ja) | 一つ又は複数のアプリケーションサービスを含んだサービスシステムの運用のための設定を支援するシステム及び方法 | |
| JP2023005205A (ja) | 情報処理装置、端末装置、情報処理システム、情報処理方法、及びプログラム | |
| JP5509164B2 (ja) | 計算機、管理方法及びプログラム | |
| US20150371294A1 (en) | Discrete client billing | |
| JP2005092544A (ja) | ワークフロー世代管理処理方法，ワークフロー処理システムおよびワークフロー制御プログラム | |
| JPH1049504A (ja) | 負荷分散バッチシステム | |
| US9678815B2 (en) | Information processing system, information processing apparatus, and method of controlling them | |
| JP7010632B2 (ja) | 中間データ管理システムおよび中間データ管理方法 |