JP2007226399A - 計算機制御方法、計算機、計算機制御プログラム及び計算機システム - Google Patents

Abstract

【課題】計算機システムの実行環境におけるガーベジコレクション処理の異常の予測を可能にする計算機システムを提供する。
【解決手段】端末と通信可能に接続され、端末から送信される処理要求に応じた処理をする処理プログラムを実行する実行環境を備える計算機のメモリ制御方法であって、処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、ガーベジコレクションが実行された時刻を計測し、計測の結果から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出し、算出された間隔と所定の閾値との比較の結果、異常の発生を通知するか否かを決定する。
【選択図】図１Ａ

Description

本発明は、計算機システムに関し、特に、計算機システムの実行環境におけるガーベジコレクション処理の異常の予測を可能とする計算機制御技術に関する。

計算機システムにおいて、計算機システムで実行されるプログラムの処理効率が、稼動時間の経過に従って低下することがある。この現象は、プログラムが確保した記憶領域を解放する処理が記述されていないなどのプログラミングエラーに起因することが知られており、ソフトウェアエージング（プログラムエージングとも言う）と呼ばれている。このソフトウェアエージングに対して、所定時間毎にアプリケーションやシステムのリセットを行うことで、元の処理効率を回復させる方法が知られている（例えば特許文献１参照）。

また、プログラムによって参照されていた記憶領域を解放するための処理として、ガーベジコレクション処理（ＧＣ処理）が知られている。
特開２００１−１８８６８４号公報

前述のように、ＧＣ処理を実行することによってソフトウェアエージングを解消することができる。しかしながら、ＧＣ処理を実行すると、計算機システムで実行されている業務アプリケーションを全て停止する必要がある。そのため、業務アプリケーションの性能、すなわち、レスポンスタイムや処理量に大きな影響が発生する。

特に、業務アプリケーションによるリクエスト量やメモリ使用量が急増すると、一回のＧＣ処理時間が長時間化したり、ＧＣ処理実行の頻度が高くなる等の異常なＧＣ処理が発生する。この異常ＧＣ処理の発生によって、業務アプリケーションの実行性能に著しく影響を与えることがある。また、使用が終了しているのにＧＣ処理により開放できないメモリ量が増加する。つまり、ＧＣ処理により開放できるメモリ量が減少する。

これに対して、異常ＧＣ処理の発生を予め予測し、対処したいという要求がある。しかしながら、単にリクエスト量やメモリ使用量を閾値によって監視するだけでは、ＧＣ処理の発生を予測することは困難である。

本発明の目的はこのような課題に鑑みてなされたものであり、異常ＧＣ処理の発生の予兆を事前に検知することにより、計算機システムの性能低下の少なくすることを可能とする計算機システムを提供することにある。

本発明による実施の形態の一例は、端末（クライアント）と通信可能に接続され、端末から送信される処理要求に応じた処理をする処理プログラムを実行する実行環境を備える計算機のメモリ制御方法であって、処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、ガーベジコレクションが実行された時刻を計測し、計測の結果から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出し、算出された間隔と所定の閾値との比較の結果、異常の発生を通知するか否かを決定することを特徴とする。

本発明によると、異常ＧＣ処理の発生を予兆してアラートを発生させ、正常状態に早期に回復することでシステム性能の低下を少なくすることができる。

以下に、本発明の実施の形態を図面に基づいて説明する。

図１Ａ及び図１Ｂは、本発明の実施の形態の仮想計算機システムの動作の概要を示す説明図である。

図１Ａに示すように、仮想計算機システムにおいて、業務アプリケーション２０３が、実行環境プログラム２１０上で動作している。

業務アプリケーション２０３は、送信されたリクエスト１１１をキュー１１０から受け取り、受け取ったリクエスト１１１を処理して、処理結果を送信元に返す。

業務アプリケーション２０３は、このリクエスト１１１の処理のために必要なメモリをヒープから確保する。

ＧＣ処理実行部２０４は、業務アプリケーション２０３によるメモリの確保量が増え、ヒープの残量が予め設定した閾値を下回ったきに、ヒープに対してガーベジコレクション処理（以下、「ＧＣ処理」と表記する）を実行する。このＧＣ処理の実行によって、ヒープの空き容量を増やす。

ヒープサイズ監視部２０６は、ヒープメモリの容量を監視する。そして、ＧＣ処理が実行されたときに、業務アプリケーションによって利用可能な空きのヒープメモリ（ヒープ残サイズ）が予め設定した閾値を下回って減少した場合、又は、ヒープ残サイズが予め設定した閾値を上回って単位時間内に急激に減少した場合を検知したときに、運用管理装置５０にアラートを通知する。

ＧＣ実行時間監視部２０７は、ＧＣ処理の実行時間及び実行時間間隔を監視する。そして、ＧＣ処理が実行されたときに、一回のＧＣ処理実行時間、前回ＧＣ処理実行からの時間間隔、前回のＧＣ処理時間と今回のＧＣ処理時間との差分、及び、前回ＧＣ処理実行からの時間間隔と今回ＧＣ処理実行からの時間間隔を算出する。そして、算出された値が予め設定した閾値を上回った場合に、運用管理端末１０９にアラートを通知する。

管理者は運用管理端装置５０へのアラートの通知を受けて、運用中の業務に対する操作を実行する。すなわち、運用管理装置５０へのアラートは、異常ＧＣ処理の発生を予測するものであるので、これ備えて、仮想計算機４０の再起動を実行したり、業務アプリケーション２０３へのリクエスト量を減少させることによって、ＧＣ処理によるヒープサイズ確保の処理時間を短縮する。

図１Ｂは、ＧＣ処理とヒープ使用サイズとの関係を示す説明図である。

ＧＣ処理にはＣｏｐｙ ＧＣ処理とＦｕｌｌ ＧＣ処理との二つの処理がある。

Ｃｏｐｙ ＧＣ処理は、業務アプリケーション２０３によって参照されている領域を検索し、検索された領域をヒープの他の空き領域にコピーすることによって実行される。既に参照されなくなった領域はヒープの空き領域として解放される。

一方、Ｆｕｌｌ ＧＣは、ヒープの全ての領域に対し、アプリケーションによって参照されている領域と参照されていない領域とを検索し、参照されている領域のみを一つずつ移動することによって、参照されなかった領域を解放する。

Ｃｏｐｙ ＧＣ処理とＦｕｌｌ ＧＣ処理とは、何れもアプリケーションによる処理を一旦停止して実行する。Ｆｕｌｌ ＧＣ処理は、Ｃｏｐｙ ＧＣ処理と比較して領域を解放する効果は高いが、参照される領域のアドレスの張り替え等が発生し、処理時間や処理負荷等のコストが大きい。

そこで、一般的に、まずＣｏｐｙ ＧＣ処理を実行し、ＣｏｐｙＧＣ処理の実行によっても領域が充分に解放されない場合にのみＦｕｌｌ ＧＣ処理を実行する。しかしながら、ＧＣ処理実行時に毎回Ｆｕｌｌ ＧＣ処理が実行されると、ＧＣ処理時間が長期化し、業務アプリケーション２０３による処理が実行できなくなってしまう。これは、アプリケーションによるメモリの使用に関して、不適切なヒープのチューニングによって発生する。

表１０１は、縦軸にヒープ使用サイズ、横軸に時間を取ったグラフである。業務アプリケーション２０３が処理を実行すると、業務アプリケーション２０３によって参照されるメモリ容量が増加し、ヒープ使用サイズが増加する。すなわち、ヒープの空き容量であるヒープ残サイズが減少する。そして、ヒープ使用サイズが予め設定した閾値を上回ったときに、ＧＣ処理実行部２０４はまずＣｏｐｙＧＣ処理を開始する。このＣｏｐｙＧＣ処理によって、ヒープ使用サイズが減少する。これを繰り返すうちにＣｏｐｙＧＣでは解放しきれない領域が発生する。この影響を受けた状態でヒープ使用サイズが予め設定した閾値を超えると今度はＦｕｌｌＧＣが発生する。表１０１中の矢印で示した箇所が該当する。これによりヒープ使用サイズが大きく減少する。すなわち、ヒープ残サイズが大きく増加する。

このような処理を繰り返しながら、業務アプリケーション２０３による処理を実行する。

表１０２は、異常ＧＣ処理の発生を示す。

業務アプリケーション２０３の処理が実行されるに従って、業務アプリケーション２０３によって参照されるメモリ容量が増加し、ヒープ残サイズが減少する。そして、ヒープ残サイズが予め設定した閾値を下回ったときに、ＧＣ処理実行部２０４はＧＣ処理を開始する。

このとき、ＧＣ処理を実行したにもかかわらずヒープ残サイズがあまり回復しない場合は、短時間で次のＧＣ処理を開始する。ＧＣ処理を実行すると、業務アプリケーション２０３を一旦停止しなければならないので、ＧＣ処理を頻発に実行すると、ＧＣ処理のために業務アプリケーション２０３による処理が遅滞する。

Ｆｕｌｌ ＧＣ処理が毎回実行されるようになり、その処理間隔がさらに小さくなると、業務アプリケーション２０３はもはや実行不可能となる。このように毎回Ｆｕｌｌ ＧＣ処理が頻繁に実行されるような状態を異常ＧＣ処理と呼ぶ。

そこで、ＧＣ実行時間監視部２０７及びヒープサイズ監視部２０６は、この異常ＧＣ処理の発生を防ぐために、ＧＣ処理の間隔や実行時間、ＧＣ処理後のヒープ残サイズ等を監視し、これらが予め設定した閾値を超えたときに、異常ＧＣが発生することを予見して、運用管理装置５０にアラートを通知する。アラートが通知された場合は、運用管理装置５０は、仮想計算機を再起動するなどの処理によって異常ＧＣを回避する。

なお、業務アプリケーション２０３の処理能力を超えたリクエストが入力される場合は、運用管理装置５０が負荷分散装置２０にリクエスト量を減少させるよう指示してもよい。

これによって、ヒープの空き容量が回復し、表１０３に示すように、正常なＧＣ処理のみ実行されるようになる。

図２は、本発明の実施の形態の計算機３０を中心とした構成ブロック図である。

計算機３０は、負荷分散装置２０に接続されている。負荷分散装置２０は、計算機３０に設定されている各仮想計算機４０に送信すべきリクエストを分配する。

この計算機３０は、ＣＰＵ２０１とメモリ２０２とを備える。

メモリ２０２はオペレーティングシステム５０を備えている。ＣＰＵ２０１が、このオペレーションシステム５０を実行することによって、複数の仮想計算機４０（４０Ａ、４０Ｂ及び４０Ｃ）が構成される。仮想計算機４０は、それぞれが独立した一つの計算機然として機能する。

仮想計算機４０Ａ、４０Ｂ及び４０Ｃは、それぞれ、実行環境プログラム２１０（２１０Ａ、２１０Ｂ及び２１０Ｃ）と、業務アプリケーション２０３（２０３Ａ、２０３Ｂ及び２０３Ｃ）とを含む。

なお、以降は、特に区別する場合を除き、仮想計算機４０、実行環境プログラム２１０及び業務アプリケーション２０３とのみ表記する。

実行環境プログラム２０１は、仮想計算機４０が実行する処理に必要な機能を提供する。この実行環境プログラム２０１は、ＧＣ実行処理部２０４、アプリケーション実行部２０５、ヒープサイズ監視部２０６、ＧＣ実行時間監視部２０７及び閾値監視テーブル５４０を含む。

ＧＣ実行処理部２０４は、業務アプリケーション２０３によって参照されたメモリを解放するためのＧＣ処理を実行する。

アプリケーション実行部２０５は、業務アプリケーション２０３を実行する。

ヒープサイズ監視部２０６は、業務アプリケーション２０３によって取得されるヒープのサイズを監視する。

具体的には、ヒープサイズ監視部２０６は、ＧＣ処理実行部２０４によってＧＣ処理が実行されたときに、ヒープの容量を取得して、ヒープ残サイズ、すなわち、業務アプリケーションによって使用可能な空きのヒープメモリの残サイズを算出する。また、ヒープサイズ監視部２０６は、算出したヒープ残サイズと前回のＧＣ処理のときに算出したヒープ残サイズとから、その差分値であるヒープ残サイズ増減を算出する。そして、これらの値を、ヒープサイズ監視テーブル５３０に格納する。

ＧＣ実行時間監視部２０７は、ＧＣ処理実行部２０４によって実行されるＧＣ処理の処理時間や処理間隔を監視する。

具体的には、ＧＣ実行時間監視部２０７は、ＧＣ処理実行部２０４によってＧＣ処理が実行されたときに、当該ＧＣ処理の時刻と前回のＧＣ処理の時刻とから、その差分値であるＧＣ実行間隔を算出する。またＧＣ実行時間監視部は、算出したＧＣ実行間隔と前回のＧＣ処理のときに算出したＧＣ実行間隔との差分値であるＧＣ実行時間間隔増減を算出する。そして、これらの値を、ＧＣ実行時間間隔監視テーブル５１０に格納する。

同様に、ＧＣ実行時間監視部２０７は、ＧＣ処理実行部２０４によってＧＣ処理が完了したときに、当該ＧＣ処理に要した時間であるＧＣ実行時間を算出する。また、当該ＧＣ実行時間と前回のＧＣ処理のときに算出したＧＣ実行時間とから、その差分値であるＧＣ実行時間増減を算出する。そして、これらの値を、ＧＣ実行時間監視テーブル５１０に格納する。

閾値監視テーブル５４０は、ヒープサイズ監視部２０６及びＧＣ実行時間監視部２０７によって参照される各種閾値を格納する。この閾値は予め管理者等によって設定される。ヒープサイズ監視部２０６及びＧＣ実行時間監視部２０７は、この閾値監視テーブル２０８に格納されている閾値と、算出した各値との比較の結果、アラートを出力するか否かを決定する。

図３は、本発明の実施の形態の計算機システムの構成ブロック図である。

この計算機システムは、端末１０、負荷分散装置２０、計算機３０、運用管理装置５０及び運用端末を備える。

計算機３０は、前述のように、複数の仮想計算機４０Ａ、４０Ｂ及び４０Ｃが設定されている。

運用管理装置５０は計算機監視部５１、アラート受付部５２、負荷分散装置操作部５３、計算機状態管理テーブル５５０、負荷分散振り分け管理テーブル５６０を備える。

端末１０と負荷分散装置２０とは、ネットワーク回線を経由して接続されている。このネットワーク回線は、ＬＡＮであってもよいしインターネット等の広帯域網によって構成されていてもよい。

端末１０は、計算機３０にリクエストを送信する。

負荷分散装置２０は、端末１０から送信されたリクエストを受け取り、これをキューに保存する。そして、負荷や機能を考慮しながら各仮想計算機４０にリクエストを割り振る。

運用管理装置５０の計算機監視部５１は、計算機３０や計算機３０に構築された各仮想計算機４０を管理する。また、運用管理装置５０のアラート受付部５２は仮想計算機４０から通知されたアラートを受信すると、このアラートの内容を運用端末７０に表示して管理者からの指示を仰ぐ。

なお、前述のように、運用管理装置５０のアラート受付部５２が、仮想計算機４０からアラートを受信したときに、運用管理装置５０の計算機監視部５１経由で自動的に当該仮想計算機４０を再起動させ、ヒープの内容を初期化して業務アプリケーション２０３の処理を正常に実行できるようにしてもよい。また、運用管理装置５０のアラート受付部５２が、仮想計算機４０からアラートを受信したときに、運用管理装置５０の負荷分散装置操作部５３経由で自動的に負荷分散装置２０に当該仮想計算機４０へのリクエストの送信量を減らすように指示してもよい。これによって、ヒープの空き容量が回復する。

計算機状態管理テーブル５５０は、各仮想計算機４０の稼動中、停止中、再起動中といった稼働状態を格納する。

負荷分散振り分け管理テーブル５６０は、負荷分散装置２０から各仮想計算機４０への振り分けを操作する際の状態を格納する。

運用端末７０は、運用管理装置５０に接続され、運用管理装置５０の設定情報を表示したり、管理者による設定情報の入力を受け付ける。

図４は、ＧＣ実行時間間隔監視テーブル５１０の一例の説明図である。

ＧＣ実行時間間隔監視テーブル５１０は、ＧＣ実行時間監視部２０７によって管理される。

ＧＣ実行時間間隔監視テーブル５１０は、時刻フィールド５１１、ＧＣ実行時間間隔フィールド５１２及びＧＣ実行時間間隔増減フィールド５１３を含む。

時刻フィールド５１１は、ＧＣ処理を実行した時刻を格納する。

ＧＣ実行時間間隔フィールド５１２は、今回のＧＣ処理の時刻と前回のＧＣ処理の時刻との差分であるＧＣ実行間隔の値を格納する。

ＧＣ実行時間間隔増減フィールド５１３は、今回算出したＧＣ実行間隔と前回算出したＧＣ実行間隔との差分であるＧＣ実行時間間隔増減の値を格納する。

図５は、ＧＣ実行時間監視テーブル５２０の一例の説明図である。

ＧＣ実行時間監視テーブル５２０は、ＧＣ実行時間監視部２０７によって管理される。

ＧＣ実行時間監視テーブル５２０は、時刻フィールド５２１、ＧＣ実行時間フィールド５２２及びＧＣ実行時間増減フィールド５２３を含む。

時刻フィールド５２１は、ＧＣ処理を実行した時刻を格納する。

ＧＣ実行時間フィールド５２２は、当該ＧＣ処理に要した時間であるＧＣ実行時間の値を格納する。

ＧＣ実行時間増減フィールド５２３は、算出したＧＣ実行時間と前回のＧＣ処理のときに算出したＧＣ実行時間との差分であるＧＣ実行時間増減の値を格納する。

図６は、ヒープサイズ監視テーブル５３０の一例の説明図である。

ヒープサイズ監視テーブル５３０は、ヒープサイズ監視部２６０によって管理される。

ヒープサイズ監視テーブル５３０は、時刻フィールド５３１、ヒープ残サイズフィールド５３２及びヒープ残サイズ増減フィールド５３３を含む。

時刻フォールド５３１は、ＧＣ処理を実行した時刻を格納する。

ヒープ残サイズフィールド５３２は、業務アプリケーションによって使用可能なメモリの残サイズであるヒープ残サイズの値を格納する。

ヒープ残サイズ増減フィールド５３３は、算出したヒープ残サイズと前回のＧＣ処理のときに算出したヒープ残サイズとの差分であるヒープ残サイズ増減の値を格納する。

なお、これら図４乃至６のテーブルは、一つのテーブルであってもよい。

図７は、閾値設定テーブル５４０の一例の説明図である。

閾値設定テーブル５４０は、ヒープサイズ監視部２０６及びＧＣ実行時間監視部２０７によって参照される各種の閾値を格納する。

閾値管理テーブル５４０は、閾値種別フィールド５４１と閾値フィールド５４２とを含む。閾値種別フィールド５４１は、設定される閾値の種別を格納する。閾値フィールド５４２は、その閾値を格納する。

管理者は、運用端末７０を用いて、閾値の種別とその閾値とを運用管理装置５０に設定する。運用管理装置５０は、これらの値を、各仮想計算機４０に送信する。仮想計算機４０は、受け取った値を、閾値設定テーブル５４０に格納する。

次に、以上のように構成された仮想計算機システムの動作を説明する。

まず、仮想計算機４０における、業務アプリケーション２０３実行時の処理を説明する。

図８は、業務アプリケーション実行時の処理のフローチャートである。

端末１０から送信されたリクエストは、負荷分散装置２０を介して、仮想計算機４０が受信する。

仮想計算機４０において、業務アプリケーション２０３がリクエストを受信する。業務アプリケーション２０３は、受信したリクエストの処理を開始するときに、この図８の処理を実行する。

まず、業務アプリケーション２０３は、受信したリクエストの処理のために必要なメモリの容量を算出して、ヒープから算出した容量のメモリを確保することをアプリケーション実行部２０５に要求する（Ｓ６０１）。

アプリケーション実行部２０５は、この要求を受けて、現在のヒープの容量を取得し、要求されたメモリを確保するために必要なヒープの空きがあるか否かを判定する（Ｓ６０２）。ヒープの空きが充分にあれば、ステップＳ６０６に移行する。ヒープの空きが要求された容量に満たない場合は、ステップＳ６０３に移行する。

ステップＳ６０６では、アプリケーション実行部２０５は、要求された容量のメモリをヒープから確保し、業務アプリケーション２０３に渡す。業務アプリケーション２０３は、これを受けて、リクエストの処理を実行し、本フローチャートの処理を終了する。

一方、ヒープの空きが要求された容量に満たない場合は、アプリケーション実行部２０５は、ヒープの空きを増やすために、ＧＣ処理実行部２０４にＧＣ処理の実行を要求する（Ｓ６０３）。

ＧＣ処理が実行された後、アプリケーション実行部２０５は、再び現在のヒープの容量を取得し、要求されたメモリを確保するために必要なヒープの空きがあるか否かを判定する（Ｓ６０４）。ヒープの空きが充分にあれば、ステップＳ６０６に移行する。ヒープの空きが要求された容量に満たない場合は、ステップＳ６０５に移行する。

ＧＣ処理を実行したにもかかわらずヒープの空きが要求された容量に満たない場合は、アプリケーション実行部２０５は、受信したリクエストの実行に必要なメモリが不足していると判断し、メモリ不足エラーを運用管理装置５０に通知して（Ｓ６０５）、本フローチャートの処理を終了する。

図９は、図８のステップＳ６０３で実行されるＧＣ処理のフローチャートである。

ＧＣ処理実行部２０４、ＧＣ実行時間監視部２０５、及びヒープサイズ監視部２０６は、アプリケーション実行部２０５からのＧＣ処理実行要求を受けて、本フローチャートの処理を実行する。

まず、ＧＣ実行時間監視部２０５は、現在のＧＣ実行間隔と閾値設定テーブルの閾値とを比較してアラートを発するか否かを判定するＧＣ実行時間間隔監視処理を実行する（Ｓ７０１）。この処理は図１０で詳述する。

次に、ＧＣ処理実行部２０４は、ＧＣ処理を実行する（Ｓ７０２）。このＧＣ処理は、前述のように、まず、Ｃｏｐｙ ＧＣ処理を実行し、Ｃｏｐｙ ＧＣ処理の実行によってもなお必要なヒープ残サイズが確保できない場合はＦｕｌｌ ＧＣ処理を実行する。

なお、このＧＣ処理完了後に、ＧＣ実行監視部２０５は、ＧＣ処理に要した時間であるＧＣ処理時間と、今回のＧＣ処理時間と前回のＧＣ処理時間との差分値であるＧＣ実行時間増減の値とを、ＧＣ実行時間監視テーブル５２０に格納する。

同様に、ヒープサイズ監視部２０６は、ＧＣ処理後のヒープ残サイズと、今回のＧＣ処理後のヒープ残サイズと前回のＧＣ処理後のヒープ残サイズとの差分値であるヒープ残サイズ増減値とを、ヒープサイズ監視テーブル５３０に格納する。

次に、ヒープサイズ監視部２０６は、現在のヒープサイズと閾値設定テーブルの閾値とを比較してアラートを発するか否かを判定するヒープサイズ監視処理を実行する（Ｓ７０３）。この処理は図１１で詳述する。

次に、ＧＣ実行時間監視部２０４は、現在のＧＣ実行時間と閾値設定テーブルの閾値とを比較してアラートを発するか否かを判定するＧＣ実行時間監視処理を実行する（Ｓ７０４）。この処理は図１２で詳述する。

図１０は、図９のステップＳ７０１で実行されるＧＣ実行時間間隔監視処理のフローチャートである。

ＧＣ実行時間監視部２０５は、ＧＣ処理要求を受けると、まず本フローチャートによる処理を実行する（Ｓ７０１）。

本フローチャートにおいて、はじめに、ＧＣ実行時間監視部２０５は、ＧＣ処理間隔の監視処理を実行する。

まず、ＧＣ実行時間監視部２０５は、閾値設定テーブル５４０を参照して、ＧＣ間隔閾値の値を取得する。そして、取得した値を変数ｘに代入する（Ｓ８０１）。

次に、ＧＣ実行時間監視部２０５は、ＧＣ実行時間間隔監視テーブル５１０を参照して、前回のＧＣ処理を実行した時刻の値を取得する。そして、取得した値を変数ａに代入する（Ｓ８０２）。

次に、ＧＣ実行時間監視部２０５は、現在時刻、すなわちＧＣ処理を実行した時刻を取得し、取得した値を変数ｂに代入する（Ｓ８０３）。

次に、ＧＣ実行時間監視部２０５は、各変数ｘ、ａ及びｂから、次に示す数式（１）を満たすか否かを判定する（Ｓ８０４）。

ｂ − ａ ＜ ｘ ・・・ （１）
すなわち、ＧＣ処理を開始した時刻ａと前回のＧＣ処理の時刻ｂとの差分であるＧＣ実行間隔を算出する。そして、ＧＣ実行時間監視部２０５は、算出したＧＣ実行間隔がＧＣ間隔閾値よりも小さいか否かを判定する。

ＧＣ実行間隔がＧＣ間隔閾値よりも小さいということは、前回のＧＣ処理と今回のＧＣ処理とが非常に小さな間隔で実行されたことを示す。非常に小さな間隔でＧＣ処理が続けて実行されると、業務アプリケーション２０３による処理が滞ってしまうため好ましくない。さらにこのような状態が続くと、ＧＣ処理が頻発し、業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ＧＣ実行間隔が予め設定した閾値よりも小さくなった場合、すなわち、予め設定した閾値よりも小さな間隔でＧＣ処理が実行された場合は、ＧＣ実行時間監視部２０５は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、ＧＣ実行間隔が予め設定した閾値以上である場合は、次に、ＧＣ実行時間間隔増減値の監視処理を実行する。

まず、ＧＣ実行時間監視部２０５は、閾値設定テーブルを参照して、ＧＣ間隔短縮度閾値の値を取得する。そして、取得した値を変数ｙに代入する（Ｓ８０５）。

次に、ＧＣ実行時間監視部２０５は、ＧＣ実行時間間隔監視テーブル５１０を参照して、前回のＧＣ処理を実行した時刻のＧＣ実行時間間隔増減値を取得する。そして、取得した値を変数ｃに代入する（Ｓ８０６）。

次に、ＧＣ実行時間監視部２０５は、現在時刻におけるＧＣ実行時間間隔を算出する。具体的には、ＧＣ実行時間監視２０５は、ステップＳ８０２において取得した前回のＧＣ処理を実行した時刻の値ａと、ステップＳ８０３において取得したＧＣ処理を実行した現在時刻の値ｂと、の差分値を算出する。そして、算出した値を、変数ｄに代入する（Ｓ８０７）。

次に、ＧＣ実行時間監視部２０５は、各変数ｙ、ｃ及びｄから、次に示す数式（２）を満たすか否かを判定する（Ｓ８０８）。

ｄ − ｃ ＜ ｙ ・・・ （２）
すなわち、前回のＧＣ処理時のＧＣ実行時間間隔ｃと、今回のＧＣ処理時のＧＣ実行時間間隔時刻ｄとの差分であるＧＣ実行時間間隔増減値を算出する。そして、ＧＣ実行時間監視部２０５は、算出したＧＣ実行時間間隔増減値がＧＣ間隔短縮度閾値よりも小さいか否かを判定する。

ＧＣ実行間隔増減値がＧＣ間隔短縮度閾値よりも小さいということは、前々回のＧＣ処理と前回のＧＣ処理との間隔と比較して、前回のＧＣ処理と今回のＧＣ処理がより短期間で実行されたことを示す。すなわち、ＧＣ処理の実行間隔が、短縮していることを示す。このような状態が続くと、ＧＣ処理が頻発し、業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ＧＣ実行時間間隔増減値が予め設定した閾値よりも小さくなった場合は、ＧＣ実行時間監視部２０５は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、算出したＧＣ実行時間間隔増減値がＧＣ間隔短縮度閾値以上であると判定した場合は、ＧＣ実行時間監視部２０７は、本フローチャートの処理を終了して、図９の処理に戻る。

以上の処理のように、ＧＣ実行時間監視部は、ＧＣ処理の実行の間隔と、予め設定した閾値とを比較して、アラートを通知するか否かを判断する。

図１１は、図９のステップＳ７０３で実行されるヒープサイズ監視処理のフローチャートである。

ヒープサイズ監視部２０６は、ＧＣ処理実行部によるＧＣ処理の実行が完了すると、本フローチャートによる処理を実行する。

本フローチャートにおいて、はじめに、ヒープサイズ監視部２０６は、ヒープ残サイズの監視処理を実行する。

まず、ヒープサイズ監視部２０６は、閾値設定テーブル５４０を参照して、ヒープサイズ残量減少閾値の値を取得する。そして、取得した値を変数ｚに代入する（Ｓ８１０）。

次に、ヒープサイズ監視部２０６は、ヒープサイズ監視テーブル５３０を参照して、今回ＧＣ処理を実行した時刻のヒープ残サイズ増減値を取得する。そして、取得した値を変数ｅに代入する（Ｓ８１１）。

次に、ヒープサイズ監視部２０６は、各変数ｚ及びｅから、次に示す数式（３）を満たすか否かを判定する（Ｓ８１２）。

ｅ ＜ ｚ ・・・ （３）
すなわち、ヒープサイズ監視部２０６は、今回のＧＣ処理完了時のヒープ残サイズと前回のＧＣ処理完了時のヒープ残サイズとの差分値であるヒープ残サイズ増減値ｅが、ヒープ残サイズ減少閾値よりも小さいか否かを判定する。

ヒープ残サイズ増減値がヒープ残サイズ減少閾値よりも大きいということは、前回のＧＣ処理によって回復したヒープ残サイズよりも今回のＧＣ処理によって回復したヒープ残サイズが予め設定した閾値よりも小さくなっていることを示す。すなわち、ＧＣ処理にもかかわらずヒープ残サイズの回復が見込めない場合である。さらにこのような状態が続くと、ヒープ残サイズが次第に減少し、ＧＣ処理が頻発して、業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ヒープ残サイズ増減値ｅがヒープ残サイズ減少閾値よりも大きい場合は、ヒープサイズ監視部２０６は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、ヒープ残サイズ増減値がヒープ残サイズ減少閾値以上である場合は、次に、ヒープサイズ残量減少幅の監視処理を実行する。

まず、ヒープサイズ監視部２０６は、閾値設定テーブル５４０を参照して、ヒープサイズ残量減少幅閾値の値を取得する。そして、取得した値を変数ｗに代入する（Ｓ８１３）。

次に、ヒープサイズ監視部２０６は、ヒープサイズ監視テーブル５３０を参照して、前回ＧＣ処理を実行した時刻のヒープ残サイズ増減値を取得する。そして、取得した値を変数ｆに代入する（Ｓ８１４）。

次に、ヒープサイズ監視部２０６は、ヒープサイズ監視テーブル５３０を参照して、今回ＧＣ処理を実行した時刻のヒープ残サイズ増減値を取得する。そして、取得した値を変数ｇに代入する（Ｓ８１５）。

次に、ヒープサイズ監視部２０６は、各変数ｗ、ｆ及びｇから、次に示す数式（４）を満たすか否かを判定する（Ｓ８１６）。

ｇ − ｆ ＜ ｗ ・・・ （４）
すなわち、前回のＧＣ処理時のヒープ残サイズ増減値ｆと今回のＧＣ処理時のヒープ残サイズ増減値ｇとの差分値であるヒープ残サイズ増減幅値を算出する。そして、算出したヒープ残サイズ増減幅が、ヒープ残サイズ減少幅閾値よりも小さい否かを判定する。

ヒープ残サイズ増減幅値がヒープ残サイズ減少幅閾値よりも大きいということは、前々回のＧＣ処理によって回復したヒープ残サイズと前回のＧＣ処理によって回復したヒープ残サイズとの差分値よりも、前回のＧＣ処理によって回復したヒープ残サイズと今回のＧＣ処理によって回復したヒープ残サイズとの差分値がより小さくなったことを示す。すなわち、ＧＣ処理を重ねたにもかかわらず、回復したヒープ残サイズが徐々に小さくなっている。さらにこのような状態が続くと、ＧＣ処理によってもヒープ残サイズが回復せず、ＧＣ処理が頻発して、業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ヒープ残サイズ増減幅がヒープ残サイズ減少幅閾値よりも小さい場合は、ヒープサイズ監視部２０６は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、ヒープ残サイズ増減幅がヒープ残サイズ減少幅閾値以上であると判定した場合は、ヒープサイズ監視部２０６は、本フローチャートの処理を終了して、図９の処理に戻る。

以上の処理のように、ヒープサイズ監視部２０６は、ＧＣ処理によって回復したヒープ残サイズと、予め設定した閾値とを比較して、アラートを通知するか否かを判断する。

図１２は、図９のステップＳ７０４で実行されるＧＣ実行時間監視処理のフローチャートである。

ＧＣ実行時間監視部２０５は、ヒープサイズ監視処理が完了すると、本フローチャートによる処理を実行する。

本フローチャートにおいて、はじめに、ＧＣ実行時間監視部２０５は、ＧＣ処理時間の監視処理を実行する。

まず、ＧＣ実行時間監視部２０５は、閾値設定テーブル５４０を参照して、ＧＣ実行時間閾値の値を取得する。そして、取得した値を変数ｖに代入する（Ｓ８２０）。

次に、ＧＣ実行時間監視部２０５は、ＧＣ実行時間監視テーブル５２０を参照して、今回のＧＣ処理のＧＣ実行時間の値を取得する。そして、取得した値を変数ｈに代入する（Ｓ８２１）。

次に、ＧＣ実行時間監視部２０５は、各変数ｖ及びｈから、次に示す数式（５）を満たすか否かを判定する（Ｓ８２２）。

ｈ ＞ ｖ ・・・ （５）
すなわち、今回のＧＣ処理の実行時間がＧＣ処理時間閾値よりも大きいか否かを判定する。

ＧＣ実行時間がＧＣ処理時間閾値よりも小さいということは、ＧＣ処理に要した時間が所定の閾値を超えて実行されたことを示す。ＧＣ処理時間が長期化すると、業務アプリケーション２０３による処理が滞ってしまうため好ましくない。さらにこのような状態が続くと、ＧＣ処理のために、業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ＧＣ実行時間がＧＣ実行時間閾値よりも大きくなった場合は、ＧＣ実行時間監視部２０５は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、ＧＣ実行時間がＧＣ実行時間閾値以上である場合は、次に、ＧＣ実行時間増減値の監視処理を実行する。

まず、ＧＣ実行時間監視部２０５は、閾値設定テーブルを参照して、ＧＣ実行時間増加閾値の値を取得する。そして、取得した値を変数ｕに代入する（Ｓ８２３）。

次に、ＧＣ実行時間監視部２０５は、ＧＣ実行時間監視テーブル５２０を参照して、前回のＧＣ処理を実行した時刻のＧＣ実行時間増減値を取得する。そして、取得した値を変数ｉに代入する（Ｓ８２４）。

次に、ＧＣ実行時間監視部２０５は、ＧＣ実行時間監視テーブル５２０を参照して、今回のＧＣ処理を実行した時刻のＧＣ実行時間増減値を取得する。そして、取得した値を変数ｊに代入する（Ｓ８２５）。

次に、ＧＣ実行時間監視部２０５は、各変数ｕ、ｉ及びｊから、次に示す数式（６）を満たすか否かを判定する（Ｓ８０８）。

ｉ − ｊ ＞ ｕ ・・・ （６）
すなわち、前回のＧＣ処理時のＧＣ実行時間増減値ｉと、今回のＧＣ処理時のＧＣ実行時間増減値ｊとの差分値であるＧＣ実行時間増減値を算出する。そして、ＧＣ実行時間監視部２０５は、算出したＧＣ実行時間増減値がＧＣ実行時間増加閾値よりも大きいか否かを判定する。

ＧＣ実行時間増減値がＧＣ実行時間増加閾値よりも大きいということは、前々回のＧＣ処理の実行時間と前回のＧＣ処理の実行時間との差分値と比較して、前回のＧＣ処理の実行時間と今回のＧＣ処理の実行時間との差分値がより大きくなったことを示す。すなわち、ＧＣ処理を実行するたびにＧＣ処理の実行時間が増加していることを示す。このような状態が続くと、ＧＣ処理によって業務アプリケーション２０３による処理が実行できなくなる異常ＧＣ処理状態となってしまう。

そこで、ＧＣ実行時間増減値がＧＣ実行時間増加閾値よりも大きくなった場合は、ＧＣ実行時間監視部２０５は、異常ＧＣ処理の前兆と判断し、アラートを通知する（Ｓ８００）。その後、図９の処理に戻る。

一方、ＧＣ実行時間増減値がＧＣ実行時間増加閾値以下である判定した場合は、ＧＣ実行時間監視部２０７は、本フローチャートの処理を終了して、図９の処理に戻る。

以上の処理のように、ＧＣ実行時間監視部は、ＧＣ処理時間と、予め設定した閾値とを比較して、アラートを通知するか否かを判断する。

以上のように、本発明の実施の形態の仮想計算機システムでは、仮想計算機４０においてＧＣ処理を実行するときに、そのＧＣ処理の実行時間、実行間隔、ＧＣ処理によって回復したヒープ残サイズ等から、異常ＧＣ処理の発生を予測し、異常ＧＣ処理の発生を予測した場合に、アラートを通知する。管理者はこのアラートを受けて必要な処理を実行し、正常状態への早期回復を図る。このようにすることで、異常ＧＣ処理の発生によるシステムの性能劣化を防ぎ、業務アプリケーションのサービスの品質を保つことができる。

なお、本発明の実施の形態では、ＧＣ実行時間間隔増減値、ＧＣ実行時間増減値及びヒープ残サイズ増減値に差分値を用いたが、これらは所定時間あたりの増減の速度との値としてもよい。単位時間当たりの増減の速度は、それぞれの値の微分値によって求めてもよい。

図１３は、本発明の実施の形態の計算機３０を中心とした構成ブロック図であり、異常ＧＣ処理が発生したときの動作の説明図である。

前述のように、仮想計算機４０Ａにおいて、ヒープサイズ監視部２０６又はＧＣ実行時間監視部２０７は、異常ＧＣ処理の発生の予兆を検知した場合はアラートを運用管理装置５０に通知する。

運用管理装置５０は、仮想計算機４０Ａからのアラートを受信したときに、自動的に負荷分散装置２０に対する運用操作を実行する。具体的には、仮想計算機４０Ａにリクエストを送信しないように負荷分散装置２０に指示を送る。

これを受けて、負荷分散装置２９は、仮想計算機４０Ａにおいて実行されるべきリクエストを、仮想計算機４０Ａに代わって仮想計算機４０Ｂ又は仮想計算機４０Ｃが実行するように設定する。すなわち、リクエストを仮想計算機４０Ｂ及び／又は４０Ｃに振り分ける。この結果、振り分けられた仮想計算機４０Ｂ又は４０Ｃが業務アプリケーション２０３を実行する。このようにすることによって、仮想計算機４０Ａへのリクエスト量を減少することができる。そこで、負荷分散装置５０は、仮想計算機４０ＡにＦｕｌｌＧＣを実行させたり、仮想計算機４０Ａを再起動させることによって、ヒープの空き容量を回復させ、異常ＧＣの発生を解決することができる。

すなわち、運用管理装置５０は、アラートを受信したときに、自動的に負荷分散装置２０を操作して、仮想計算機４０Ａにリクエストが送信されないように制御した上で、アラートを発生させた仮想計算機４０Ａに自動的にＦｕｌｌＧＣを実行させたり、再起動させることによって、異常ＧＣ処理の回復を図ることができる。

このＦｕｌｌＧＣを実行するタイミングを、前述のように異常ＧＣ処理の発生の予兆を検知したタイミングとすることによって、仮想計算機システムにおける仮想計算機４０に異常ＧＣ処理が発生することを防ぐことが可能となる。結果として、仮想計算機システム全体の性能劣化を防ぐことが可能になる。

また、前述の仮想計算機４０Ａへの処理と同様に、仮想計算機４０Ｂ又は仮想計算機４０Ｃは、異常ＧＣ処理の発生の予兆を検知した場合はアラートを運用管理装置５０に通知する。運用管理装置５０は、アラートを受信した場合は、自動的に負荷分散装置２０を操作して、当該仮想計算機にリクエストが送信されないように制御した上で、当該仮想計算機４０に自動的にＦｕｌｌＧＣを実行させたり、再起動させることによって、ヒープの空き容量を回復させる。

つまり、異常ＧＣ処理の発生の予兆を検知したタイミングを、ヒープの空き容量の回復処理を実行するトリガ（起動条件）とすることができる。

このように、異常ＧＣ処理の発生を予兆してアラートを発生させ、正常状態に早期に回復することによって、システムの性能劣化を防ぎ、サービス品質を保つことができる。

図１４は、計算機状態管理テーブル５５０の一例の説明図である。

運用管理装置５０は、この計算機情報管理テーブル５５０を用いて各仮想計算機の稼動中、停止中、再起動中といった稼働状態を管理する。計算機状態管理テーブル５５０は、計算機名フィールド５５１、計算機ＩＤフィールド５５２、状態フィールド５５３を含む。状態フィールド５５３には、仮想計算機４０の状態として、稼働／停止／再起動中等が設定される。

図１５は負荷分散振り分け管理テーブル５６０の一例の説明図である。

運用管理装置５０は、この負荷分散振り分け管理テーブル５６０を用いて負荷分散装置２０から各仮想計算機への振り分けを操作する際の状態を管理する。負荷分散振り分け管理テーブル５６０は、計算機名フィールド５６１、状態フィールド５６２を含む。状態フィールド５６２には、各計算機への負荷分散装置からのリクエストの振分状態を設定する。状態フィールド５６２には、アクティブ／スタンバイが設定される。

図１６は運用管理装置５０における、異常ＧＣの予兆を検知したタイミングで実施する回復処理のフローである。

運用管理装置５０のアラート受付部５１が、異常ＧＣ処理の予兆を検知したアラートを受信する（Ｓ９０１）。次に、運用管理装置５０の負荷分散装置操作部５３は、アラートを通知した回復対象の仮想計算機４０にリクエストが送信されないように負荷分散装置２０に振り分け変更指示を送信する（Ｓ９０２）。その後、負荷分散装置２０から振分完了通知を受信する（Ｓ９０３）。次に、負荷分散装置操作部５３は、負荷分散振り分け管理テーブル５６０の回復対象の仮想計算機の状態フィールド５６２の内容を「スタンバイ」に変更する（Ｓ９０４）。

次に、計算機監視部５１が、アラートを通知した回復対象の仮想計算機４０に再起動指示を送信する（Ｓ９０５）。

このとき計算機監視部５１は、計算機状態管理テーブル５５０の状態を「再起動中」に変更する（Ｓ９０６）。その後、回復対象の仮想計算機４０が再起動処理を完了する（Ｓ９０７）。計算機監視部はこの再起動完了を検知して、計算機状態管理テーブル５５０の回復対象の仮想計算機４０の状態を「稼働」に変更する（Ｓ９０８）。

次に、負荷分散装置操作部５３はリクエストの振り分けを元に戻すため負荷分散装置２０に振り分け変更指示を送信する（Ｓ９０９）。その後、負荷分散装置２０から振り分け変更完了通知を受信する（Ｓ９１０）。負荷分散装置操作部５３は負荷分散振り分け管理テーブルの回復対象の仮想計算機４０の状態を「アクティブ」に変更する（Ｓ９１１）。

以上のような処理によって、アラートを発生した仮想計算機４０のヒープの空き容量を回復させ、異常ＧＣ処理の回復を図ることができる。

本発明の実施の形態の仮想計算機システムの動作の概要を示す説明図である。 本発明の実施の形態の仮想計算機システムの動作の概要を示す説明図である。 本発明の実施の形態の計算機を中心とした構成ブロック図である。 本発明の実施の形態の計算機システムの構成ブロック図である。 本発明の実施の形態のＧＣ実行時間間隔監視テーブルの一例の説明図である。 本発明の実施の形態のＧＣ実行時間監視テーブルの一例の説明図である。 本発明の実施の形態のヒープサイズ監視テーブルの一例の説明図である。 本発明の実施の形態の閾値設定テーブルの一例の説明図である。 本発明の実施の形態の業務アプリケーション実行時の処理のフローチャートである。 本発明の実施の形態のＧＣ処理のフローチャートである。 本発明の実施の形態のＧＣ実行時間間隔監視処理のフローチャートである。 本発明の実施の形態のヒープサイズ監視処理のフローチャートである。 本発明の実施の形態のＧＣ実行時間監視処理のフローチャートである。 本発明の実施の形態の仮想計算機システムに異常ＧＣの予兆を検知したときの回復処理の動作の説明図である。 本発明の実施の形態の計算機状態管理テーブルの一例の説明図である。 本発明の実施の形態の負荷分散振り分けテーブルの一例の説明図である。 本発明の実施の形態の仮想計算機システムに異常ＧＣの予兆を検知したときの回復処理のフローチャートである。

符号の説明

１０ 端末
２０ 負荷分散装置
３０ 計算機
４０ 仮想計算機
５０ 運用管理装置
５１ 計算機監視部
５２ アラート受付部
５３ 負荷分散装置操作部
６０ 運用端末
２０１ ＣＰＵ
２０２ メモリ
２０３ 業務アプリケーション
２０４ ＧＣ実行処理部
２０５ アプリケーション実行部
２０６ ヒープサイズ監視部
２０７ ＧＣ実行時間監視部

Claims (8)

1. 端末と通信可能に接続され、前記端末から送信される処理要求に応じた処理をする処理プログラムを実行する一以上の実行環境を備える計算機の制御方法であって、
   前記処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、
   前記ガーベジコレクションが実行された時刻を計測し、
   前記計測の結果から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出し、
   前記算出された間隔と所定の閾値との比較の結果、異常の発生を通知するか否かを決定することを特徴とする制御方法。
2. 前記ガーベジコレクションによって回復したメモリの使用可能容量を計測し、
   前記計測の結果から、前回実行されたガーベジコレクション処理によって回復したメモリの使用可能容量と今回実行されたガーベジコレクション処理によって回復したメモリの使用可能容量との差分値を算出し、
   前記算出された差分値と所定の閾値との比較の結果、異常の発生を通知するか否かを決定することを特徴とする請求項１に記載の制御方法。
3. 前記計算機は、前記端末から送信される処理要求を前記実行環境の負荷に応じて送信する負荷分散装置と、前記計算機及び前記負荷分散装置を管理する管理装置とに接続されており、
   前記異常の発生を前記管理装置に送信し、
   前記管理装置からの指示によって、前記負荷分散装置が、前記異常が発生した実行環境に対する処理要求を他の実行環境で実行されるように設定し、
   前記管理装置からの操作要求によって、前記異常が発生した実行環境を再起動することによって、当該実行環境の異常を回復させ、
   さらに、
   前記管理装置からの指示によって、前記負荷分散装置が、前記異常が回復した実行環境以外の実行環境に対する処理要求を他の実行環境で実行されるように設定し、
   前記管理装置からの操作要求によって、前記異常が回復した実行環境以外の実行環境を再起動させることを特徴とする請求項１に記載の制御方法。
4. 端末と通信可能に接続され、前記端末から送信される処理要求に応じた処理をする処理プログラムを実行する実行環境を備える計算機の制御方法であって、
   前記処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、
   前記ガーベジコレクションによって回復したメモリの使用可能容量を計測し、
   前記計測の結果から、前回実行されたガーベジコレクション処理によって回復したメモリの使用可能容量と今回実行されたガーベジコレクション処理によって回復したメモリの使用可能容量との差分値を算出し、
   前記算出された差分値と所定の閾値との比較の結果、異常の発生を通知するか否かを決定することを特徴とする制御方法。
5. 端末と通信可能に接続され、前記端末から送信される処理要求に応じた処理する処理プログラムを実行する実行環境を備える計算機の制御方法であって、
   前記処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、
   前記ガーベジコレクションの実行時間を計測し、
   前記計測の結果から、前回実行されたガーベジコレクション処理の実行時間と、今回実行されたガーベジコレクション処理の実行時間との差分値を算出し、
   前記算出された差分値と所定の閾値との比較の結果、異常の発生を通知するか否かを決定することを特徴とする制御方法。
6. 端末と通信可能に接続され、前記端末から送信される処理要求に応じた処理をする処理プログラムを実行する一以上の実行環境を備える計算機の制御を実行する制御プログラムであって、
   前記処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行し、
   前記ガーベジコレクションが実行された時刻を計測する手順と、
   前記計測の結果から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出する手順と、
   前記算出された間隔と所定の閾値との比較の結果、異常の発生を通知するか否かを決定する手順と、
   を前記計算機で実行させることを特徴とする制御プログラム。
7. 端末と通信可能に接続され、前記端末から送信される処理要求に応じた処理をする処理プログラムを実行する一以上の実行環境を備える計算機と、
   前記端末から送信される処理要求を、前記実行環境の負荷に応じて送信する負荷分散装置と、
   前記計算機及び前記負荷分散装置を管理する管理装置と、を備える計算機システムであって、
   前記計算機は、
   前記処理プログラムの処理によって参照されたメモリのガーベジコレクションを実行するガーベジコレクション実行部と、
   前記ガーベジコレクションが実行された時刻を計測し、前記計測された値から、前回実行されたガーベジコレクション処理と今回実行されたガーベジコレクション処理との間隔を算出し、前記算出された間隔と所定の閾値との比較の結果、前記管理装置に異常の発生を通知するか否かを決定するガーベジコレクション時間監視部と、
   を備えることを特徴とする計算機システム。
8. 前記管理装置は、
   前記異常の発生の通知を受信したときに、前記負荷分散装置に、前記異常が発生した実行環境に対する処理要求を、他の実行環境が実行するように指示し、
   前記異常が発生した実行環境を再起動させることによって、当該実行環境の異常を回復させ、
   さらに、
   前記負荷分散装置に、前記異常が回復した実行環境以外の実行環境に対する処理要求を他の実行環境で実行されるように指示し、
   前記異常が回復した実行環境以外の実行環境を再起動させることを特徴とする請求項７に記載の計算機システム。

Images