JP4479284B2 - 計算機システムのモニタリングを設定する管理計算機及びシステム - Google Patents

Description

本発明は、計算機システム並びにそのモニタリング及びチューニング方法に関するものであり、特に計算機システムで実行されるデータベース管理システム及び計算機システムに含まれる記憶装置サブシステムについてのモニタリング及びチューニング方法に関する。

従来、計算機システムの処理性能や可用性を維持あるいは向上するため、管理対象となる計算機システムを他の装置で監視（以下「モニタリング」または「システムモニタリング」）し、その監視結果に応じて他の装置を介して管理者等が計算機システムの設定を変更（以下「チューニング」）することが行われる。計算機システムにおけるシステムモニタリングに関する従来技術の一つとして、特許文献１に示す方法が開示されている。この文献には、モニタリングされる計算機システム全体の負荷（ワークロード）の総量が増加する場合には、モニタリング用の装置が計算機システムにおけるモニタリング間隔を長くしてモニタリングにより発生する負荷を計算機システムに与えないようにし、ワークロード総量が減少する場合にはモニタリング間隔を短くする技術が開示されている。

また、モニタリングとチューニングに関する他の従来技術として、非特許文献１に示す方法がある。この文献には、計算機システムの問題を発見した際、モニタリングをする装置が、現在モニタリングしている情報でその問題に対処できるかどうか判断する。そして、モニタリングしている情報が不十分な場合、モニタリングをする装置が、必要な情報を得るためのモニタリングツールを自動起動し、計算機システムから必要な情報を得る方法が開示されている。

特開２００２−１０８８１７号公報 ＤＢ２ ＵＤＢ Ｖ８技術セミナー資料 ＳＭＡＲＴ拡張機能−２ ヘルス・モニタリングツール ｈｔｔｐ：／／ｗｗｗ−６．ｉｂｍ．ｃｏｍ／ｊｐ／ｓｏｆｔｗａｒｅ／ｄａｔａ／ｄｂ２ｕｎｉｖ／ｄａｔａ／ｓｍａｒｔｕｄｂｖ８＿６＿２．ｐｄｆ（ｐ．１４）。

計算機システムのチューニングを適切に行うためには、チューニングにより計算機システム内の各構成要素（以下「リソース」）に掛かる負荷がどのように変化するかをもモニタリングする必要がある。ここで、適切なチューニングを行うためにモニタリングしなければならない計算機システムのリソースの種類や動作内容は、個々の計算機システムの使用者等がチューニングしたい計算機システムの環境（例えば計算機システムで実行されるアプリケーションの種類等）毎に異なる。

上述の様な環境毎の適切なチューニングを目的とした計算機システムのモニタリングを従来技術で行うことを考える。
特許文献１に示された従来技術の場合、どの環境でどのリソースをモニタリングするかが全く考慮されていない。したがって、特許文献１記載の従来技術で環境毎の適切なチューニングを目的としたモニタリングをしようとすると、結果として全てのリソースのモニタリングを行う必要がある。すると、不要な種類のリソースまでモニタリングを行うため、計算機システムへの負荷や計算機から取得されるデータ量が増大する。

一方、非特許文献１に記載された従来技術の場合、モニタリングの対象となるリソースは予め設定されていて、モニタリングの対象となる計算機システムに問題が発見されないとモニタリングの対象となるリソースが追加されない。したがって、非特許文献１記載の従来技術では環境毎の適切なチューニングを目的としたモニタリングを行うことができない。

本発明の目的は、環境に応じた計算機システムのチューニングを適切に行い、かつ計算機システムへの負荷の低減及びネットワークへの負荷を減らすことが可能なシステムモニタリング方法を提供することである。

上記の課題を解決するために、本発明は一実施形態として以下の構成を有する。すなわち、計算機システムと、計算機システムと接続される第二の計算機を有するシステムである。そして、本システムにおいて、計算機システムは第二の計算機に計算機システムで実行されるプログラムの種類を通知し、第二の計算機は、通知された実行されるプログラムの種類に応じて性能項目を特定し、特定した性能項目に関する情報（以下「性能情報」）の収集を計算機システムに通知する。そして計算機システムは、通知の内容に基づいて特定された性能情報を収集する。

又、上述の構成において、更に計算機システムは、第二の計算機に収集した性能情報を通知し、第二の計算機が、通知された性能情報が所定の条件を満たさない場合には、計算機システムの設定を所定の値に変更する指示を計算機システムに送信し、計算機システムが指示に基づいて自身の設定を変更する構成も考えられる。

更に、上述の構成において、計算機システムが、第二の計算機に計算機システムで終了するプログラムの種類を通知し、第二の計算機が、通知された終了するプログラムの種類に応じて第二の性能項目を特定し、計算機システムに第二の性能項目に関する情報（以下「第二の性能情報」）の収集の停止を指示し、計算機システムが収集の停止の指示に基づいて、第二の性能情報の収集を停止する構成としても良い。

尚、上述の構成において、性能情報の収集の通知には、性能情報を計算機システムで収集する周期に関する情報が含まれていても良い。

更に、計算機システムは、計算機及び記憶装置サブシステムを有していてもよい。又、性能項目の情報は、システムにおいて達成すべき性能に関する情報であっても良い。

本発明によれば、環境に応じた計算機システムのチューニングを行うことが出来る。更に、計算機システムのチューニングを行うためのモニタリングに起因する計算機システムへの負荷を低減すること及びモニタリングに基づくネットワークへの負荷を減らすことが可能になる。

以下、図１〜図１９を用いて本発明の実施の形態について説明する。ただし、本発明は以下の実施形態に限定されないのは言うまでもない。

図１は、本発明が実施されるシステムの構成例を示す図である。システムは、管理サーバ１、計算機システム及びネットワーク４を有する。尚、各構成要素は複数あっても良い。
更に計算機システムは、業務サーバ２及び記憶装置サブシステム３を有する。ここでサーバとは一般的な計算機を指す。又、業務サーバ２及び記憶装置サブシステム３は、通信線を介して接続されている。尚、計算機システムは業務サーバのみ、記憶装置サブシステムのみ、あるいはそれぞれが複数含まれていても良い。

管理サーバ１は、ＣＰＵ１１、主記憶１２、ネットワークインタフェース１３、ディスプレイ１４、キーボード１５、ＣＤ−ＲＯＭ１６、コントローラ１７及び記憶装置１８を有する。
業務サーバ２は、ＣＰＵ２１、主記憶２２、ネットワークインタフェース２３、ディスプレイ２４、キーボード２５、ＣＤ−ＲＯＭ２６、コントローラ２７、記憶装置２８及びデータインタフェース２９を有する。

記憶装置サブシステム３は、複数の記憶装置を有する装置である。ここで記憶装置とは、ハードディスクドライブ、ＣＤ−ＲＯＭ、ＤＶＤ等の記憶媒体を指す。記憶装置サブシステム３は、ポート３１、ディスクコントローラ３２、制御メモリ３３、プロセッサ３４、キャッシュメモリ３５、ディスク３６及びネットワークインタフェース３７を有する。ここで、ディスク３６はハードディスクドライブ等の記憶装置である。記憶装置サブシステム３は、ＲＡＩＤ構成を有していても良い。

管理サーバ１の記憶装置１８には、性能管理プログラム１０１、モニタ制御情報記憶テーブル１１１、チューニング情報記憶テーブル１１２、アプリケーション状態記憶テーブル１１３、モニタエージェント管理テーブル１１５及びアプリケーション特性テーブル１０２が格納されている。性能管理プログラム１０１は、ＣＰＵ１１により主記憶１２に読み込まれ、ＣＰＵ１１で実行される。モニタ制御情報記憶テーブル１１１、チューニング情報記憶テーブル１１２、アプリケーション状態記憶テーブル１１３、モニタエージェント管理テーブル１１５及びアプリケーション特性テーブル１０２の各テーブルは、性能管理プログラム１０１の実行時にＣＰＵ１１により主記憶１２に読み込まれる。

業務サーバ２の記憶装置２８には、アプリケーション制御プログラム１０３、アプリケーション１０４、データベース管理システム１０５、データベースモニタエージェント１０５、データベースチューニングエージェント１０７及びアプリケーションスケジュール１１４のプログラムやテーブルが記憶されている。アプリケーション制御プログラム１０３、アプリケーション１０４、データベース管理システム１０５、データベースモニタエージェント１０５及びデータベースチューニングエージェント１０７はＣＤ−ＲＯＭ２６を経由して記憶装置２８に格納され、ＣＰＵ２１により主記憶２２に読み込まれて実行される。アプリケーションスケジュール１１４は、アプリケーション制御プログラム１０３の実行時にＣＰＵ２１により主記憶２２に読み込まれる。

尚、管理サーバ１の記憶装置１８に格納されるプログラムも、ＣＤ−ＲＯＭ１８を介して管理サーバ１にインストールされる。ただし、インストールに使用される記憶媒体は、ＣＤ−ＲＯＭに限らず他の可搬な記憶媒体でも良い。更に、可搬記憶媒体を用いずネットワークを用いてこれらのプログラムを各装置へインストールしても良い。

記憶装置サブシステム３の制御メモリ３３には、先読みプログラム１０８、モニタエージェント１０９及びチューニングエージェント１１０の各種プログラムが格納される。
また、業務サーバ２で使用されるデータは記憶装置サブシステム３のディスク３６に格納される。業務サーバ２によって読み出されるデータは、ディスクコントローラ３２のプロセッサ３２により、ディスク３６からキャッシュメモリ３５を経由してポート３１に転送され、業務サーバ２のデータインタフェース２９を経由して主記憶２２に取り込まれる。業務サーバ２から記憶装置サブシステム３に書き込まれるデータは、上述した読出しとは逆の経路によりディスク３６に書き込まれる。

なお、本実施例では、アプリケーション制御プログラム１０３、アプリケーションスケジュール１１４、アプリケーション１０４、ＤＢＭＳ１０５、ＤＢモニタエージェント１０６、ＤＢチューニングエージェントが同一の業務サーバ２上に存在するが、実際にはアプリケーション制御プログラム１０３とアプリケーションスケジュール１１４が同一サーバ上に、ＤＢＭＳ１０５とＤＢモニタエージェント１０６とＤＢチューニングエージェントが同一サーバ上にあればよい。

また、他の構成として、業務サーバ２と管理サーバ１にあるプログラム及びテーブルが同一サーバ上にある構成でも構わない。

図２は、アプリケーション特性テーブル１０２の内容例を示す図である。アプリケーション特性テーブル１０２には、業務サーバ２で実行されるアプリケーションについての情報が登録される。アプリケーション特性テーブル１０２は、業務サーバ２で実行されるアプリケーションごとに対応するレコードを有する。個々のレコードは、レコードに対応するアプリケーションの名称を示すアプリケーション名が登録されるフィールド２０１及びレコードに対応するアプリケーションの特性（以下「アプリケーション特性」）を記憶するフィールド２０２とを有する。本実施例では、アプリケーションが記憶装置サブシステム３にデータの入出力命令（以下「Ｉ／Ｏ」）を発行する際のディスクアクセスパターンをアプリケーション特性として用いる（フィールド２０２）。

但し、アプリケーション特性は、アプリケーションがサーバのＣＰＵやディスク等の物理リソース及び物理リソース上に構築される論理リソース（ディスク上に構築される論理的なディスク領域等）をどのように利用するかのパターンを示す情報であればよい。サーバのＣＰＵをアプリケーション特性の対象として用いる場合は、ＣＰＵ利用率をアプリケーション特性として用いることができる。

図３は、モニタ制御情報記憶テーブル１１１の構成例を示す図である。モニタ制御情報記憶テーブル１１１には、チューニングの対象となるリソースの設定項目（以下「チューニング項目」）と、当該チューニング項目を制御する場合に計算機システムの何の性能をモニタリングするか（以下「モニタリング項目」）、及びどんな間隔でモニタリングするか（あるいはモニタリングしないか）（以下、「モニタリング間隔」）の対応関係を示す情報が登録される。モニタ制御情報記憶テーブル１１１は、チューニング項目毎に対応するレコードを有する。

各レコードは、チューニング項目を示す情報が登録されるフィールド３０１、及びレコードに対応するチューニング項目に対して、どのモニタリング項目をどんな頻度でモニタリングするか（あるいはしないか）を示すフィールド３０２を有する。本実施例では、ＤＢＭＳキャッシュサイズのチューニングとストレージ先読み量のチューニングを行う場合に、モニタリング項目として、ＤＢＭＳのＩ／Ｏ要求がＤＢＭＳのキャッシュにヒットした割合を示すＤＢＭＳキャッシュヒット率、及び記憶装置サブシステム内のプロセッサの利用率であるストレージプロセッサ利用率をどのような間隔でモニタリングするか（あるいはしないか）をそれぞれフィールド３０２ａ及び３０２ｂに記憶している。なお、これらのモニタリング項目は、ＤＢモニタエージェント１０５及びモニタエージェント１０９によりそれぞれ監視される。尚、使用するアプリケーションの特性やチューニングの手法によって、モニタリング項目も本実施形態で開示されない物になる場合がある。例えば、データのディスクへの配置場所のチューニングの場合には、データが格納される記憶領域毎のＩ／Ｏ数がモニタリング項目となる。尚、他の実施形態として、モニタ制御情報記憶テーブル１１１の項目に、システムでモニタされる可能性がある項目を全て列挙し、個々のアプリケーション特性毎（あるいはチューニング項目毎）に、必要なモニタリング項目の欄にのみ任意のモニタリング間隔を登録し、不要なモニタリング項目の欄には０を設定することにしても良い。

図４は、チューニング情報記憶テーブル１１２の構成例を示す図である。該テーブル１１２には、アプリケーション特性と、その特性に応じたチューニング項目、当該チューニング項目をチューニングする際に使用する値を決定するためのルールが記憶される。チューニング情報記憶テーブル１１２は、アプリケーション特性毎に対応するレコードを有する。各レコードは、対応するアプリケーション特性を登録するフィールド７０１、アプリケーション特性に対応するチューニング項目を登録するフィールド７０２及び対応するルールを登録するフィールド７０３を有する。

図５は、アプリケーション状態記憶テーブル１１３の構成例を示す図である。アプリケーション状態記憶テーブル１１３は、現在システムで稼動しているアプリケーション名と、それに対応したモニタリング項目及びモニタリング間隔の情報を記憶するテーブルである。アプリケーション状態記憶テーブル１１３は、システムで稼動しているアプリケーション毎に対応するレコードを有する。

各レコードは、現在稼動しているアプリケーション名を記憶するフィールド８０１及び対応するアプリケーションのモニタリング項目のモニタリング間隔を示すフィールド８０２を有する。アプリケーション状態記憶テーブル１１３の各レコード８０４は、管理サーバ１が業務サーバ２からアプリケーション起動の通知を受けると追加され、終了の通知をうけると削除される。

図６は、アプリケーションスケジュールテーブル１１４の構成例である。アプリケーションスケジュールテーブル１１４は、業務サーバ２で実行されるアプリケーションのスケジュール（実行開始時間等）の情報を管理するためのテーブルである。アプリケーションスケジュールテーブル１１４は、アプリケーション名を記憶するフィールド９０１及び該アプリケーションが起動する時刻を示すフィールド９０２から構成される。ただし、アプリケーションが終了する時刻等の情報も登録されて良い。

図７は、モニタエージェント管理テーブル１１５の構成例である。モニタエージェント管理テーブル１１４は、管理サーバ２が監視対象とするモニタリング項目が、どの装置のどのモニタエージェントによって監視されているかを記憶しているテーブルである。モニタエージェント管理テーブル１１５は、モニタ項目名を記憶するフィールド１００１、該モニタ項目を監視するモニタエージェント名を記憶するフィールド１００２、及び該モニタエージェントが存在する装置名を記憶する装置名フィールド１００３を有する。尚、各々のテーブルの情報は、性能管理プログラム１０１を開始する前に、管理者がネットワーク等を介して各装置に登録する。

本システムでは、管理サーバ１が業務サーバ２からアプリケーションの実行を通知されると、そのアプリケーションの特性に応じたモニタリング項目及びモニタリング間隔を選択して個々の装置（業務サーバや記憶装置サブシステム３）にモニタリングの開始を指示する。そして、モニタリングの結果を各装置から受信した管理サーバ１は、その結果に基づいて、チューニングを行う必要があるかどうか判断し、チューニングを行う。更に、アプリケーションの終了を通知された管理サーバ１は、必要に応じて、モニタリングの終了を各装置に通知する。

以下、図８を用いて、システムにおけるモニタリングの全体の流れを説明する。尚、以下プログラムが主語になる場合は、実際にはそのプログラムを実行するCPUによって処理が実行される。
まず、タイマにより業務サーバ２のアプリケーション制御プログラム１０３が起動される（ステップ４０１）。アプリケーション制御プログラム１０３は、アプリケーションスケジュールテーブル１１４を参照し、起動するアプリケーションの有無をチェックする。起動するアプリケーションがある場合、アプリケーション制御プログラム１０３は、管理サーバ１の性能管理プログラム１０１に、アプリケーション名とアプリケーションの起動をネットワーク４を介して通知する。尚、業務サーバ２は、アプリケーションスケジュールテーブル１１４の情報以外に、業務サーバ２を使用する管理者等によってアプリケーションの起動の要求が生成された時に本ステップの処理を行っても良い（ステップ４０４）。

アプリケーション名を受取った性能管理プログラム１０１は、チューニング情報記憶テーブル１１２アプリケーション特性テーブル１０２を参照して受信したアプリケーション名に対応するチューニング項目とアプリケーション特性を取得する（ステップ５０２）。さらに性能管理プログラム１０１は、モニタ制御情報記憶テーブル１１１を参照して、取得したアプリケーション特性に対応するモニタリング項目ごとのモニタリング間隔を決定する。そして、性能管理プログラム１０１は、決定したモニタリング項目及びモニタリング間隔の情報を、管理サーバ２及び記憶装置サブシステム３のモニタエージェント１０６、１０９に通知する（ステップ５０４）。

通知を受けたモニタエージェント１０６、１０９は、指定されたモニタリング項目について、指定されたモニタリング間隔でモニタリングを開始する。この際、モニタエージェント１０６、１０９は、モニタリングの開始を、ネットワーク４を介して管理サーバ１の性能管理プログラムに通知する（ステップ１００１）。

モニタリングの開始の通知を受信した性能管理プログラム１０１は、モニタリングが開始されたことを業務サーバ２のアプリケーション制御プログラム１０３にネットワーク４を介して通知する。通知を受取ったアプリケーション制御プログラム１０３は、アプリケーションを起動する（ステップ５０８、ステップ４０５、ステップ１００３）。

アプリケーションが稼動している間、モニタエージェント１０６、１０９は指示されたモニタリング間隔で個々の装置の性能データを取得し、取得した性能データ（以下「モニタデータ」とも言う）を管理サーバ１の性能管理プログラム１０１にネットワーク４を介して通知する（ステップ１００２）。モニタデータを受信した性能管理プログラム１０１は（ステップ５０５）、チューニングの実施が必要であると判断すればチューニングを実行する（ステップ５０７）。

アプリケーションが終了すると（ステップ１００４）、アプリケーション制御プログラム１０３はアプリケーション終了を検知し（ステップ４０６）、終了したアプリケーション名を管理サーバ１の性能管理プログラム１０１にネットワーク４を介して通知し（ステップ４０７）、その結果を受け取る（ステップ４０９）。

アプリケーション名を受取った性能管理プログラム１０１は、アプリケーション開始時と同様にテーブル１０２、１１１、１１３を参照してモニタエージェントの制御方法を決定し、モニタエージェント１０６及び／又は１０９に通知する（ステップ５０４）。通知を受けたモニタエージェントは、通知に従いモニタリング項目及びモニタリング間隔を変更（あるいは終了）する。

以下、各装置における処理手順の詳細について説明する。
図９は、業務サーバ２が、アプリケーション１０４の実行を開始する際に、アプリケーション制御プログラム１０３を実行することによって実施する処理の手順例を示す図である。尚、図８と同じ番号は、それらの処理ステップが一致することを示す。
業務サーバ２は、まずアプリケーションスケジュールテーブル１１４のフィールド１１４を参照して起動すべきアプリケーションがあるかどうかを判断する（ステップ４０２）。起動すべきアプリケーションがある場合、業務サーバ２は起動するアプリケーション名をフィールド９０１から取得し、取得したアプリケーション名とそのアプリケーション１０４を起動することをネットワークI/F２３を介して管理サーバ１に送信する（ステップ４０４）。その後、モニタリングの開始又はモニタリング内容の変更の処理の完了の通知をプログラム１０１から受け取った後（ステップ４０８）、業務サーバ２はアプリケーションの実行を開始する（ステップ４０５）。一方、起動すべきアプリケーションが存在しない場合、業務サーバ２は、ステップ４０１及び４０２の処理を繰り返す。なお、本実施例では、モニタリングが開始（又は内容の変更）された通知を受けてから業務サーバ２がアプリケーションを起動しているが、モニタリングの開始（又は内容の変更）の通知を待たずに業務サーバ２がアプリケーションを起動する構成でもよい。

その後業務サーバ２は、アプリケーション１０４の終了を監視する（ステップ４０６）。アプリケーション１０４の終了を検知すると、業務サーバ２は、終了するアプリケーションの名称とアプリケーションが終了することを管理サーバ１の性能管理プログラム１０１に送信し（ステップ４０７）、プログラム１０１からモニタリングの内容が変更された通知を受けた後（ステップ４０９）、ステップ４０１の処理に戻る。なお、本実施例では、業務サーバ２がモニタリングの内容が変更された通知を受けているが、通知を受けない構成でもよい。

図１０は、管理サーバ１が性能管理プログラム１０１を実行することで計算機システムのモニタリングを実施する際の処理手順の例を示す図である。ここでも、図８と一致するステップは、その内容が一致することを示している。
まず、管理サーバ１は、業務サーバ２からアプリケーション開始又は終了の通知があったか否かをチェックする（ステップ５０１）。次に、管理サーバ１はアプリケーション特性テーブル１０２を参照し、受け取ったアプリケーション名に対応するアプリケーション特性を取得する。尚、業務サーバ２で実行中のアプリケーション１０４に関するアプリケーション特性に関する情報は、次のアプリケーションの実行又はアプリケーションの終了が業務サーバ２から通知されるまで管理サーバ１内で保持される（ステップ５０２）。

その後、管理サーバ１は、チューニング情報記憶テーブル１１２を参照して、取得したアプリケーション特性に対応するチューニング項目及びチューニングルールを取得する。又、モニタ制御情報記憶テーブル１１１を参照して取得したアプリケーション特性に対応するモニタリング項目及びモニタリング間隔の情報を取得する（ステップ５０３）。その後、管理サーバ１は、モニタエージェント制御処理５０４を実行し、モニタリング項目とモニタリング間隔の情報をモニタリングの対象となる業務サーバ２及び記憶装置サブシステム３の双方あるいはいずれか一方に転送する。モニタエージェント制御処理５０４の動作は後で説明する（ステップ５０４）。

その後、管理サーバ１は、業務サーバ２及び記憶装置サブシステム３の双方又はいずれか一方から、指定したモニタリング項目の対象となるリソースの動作や稼動に関する情報であるモニタデータを受け取る（ステップ５０５）。モニタデータを受取った管理サーバ１は、業務サーバ２で実行されているアプリケーション１０４（先に保持したアプリケーション特性の情報から判断される）に対応するチューニング情報記憶テーブル１１２のフィールド７０３に登録された条件に受信したモニタデータが合致するかどうか判断することで、システムのチューニングが必要か否かを判断する（ステップ５０６）。

条件に合致する場合、すなわちチューニングが必要と判断された場合は、管理サーバ１は、保持しているアプリケーション特性の情報に対応するチューニング情報記憶テーブル１１２のフィールド７０２に記憶された情報で指定されるチューニング項目をフィールド７０３の内容に合致させるためのチューニングを実施するよう、モニタデータを送信した業務サーバ２及び記憶装置サブシステム３のいずれか一方又は双方に指示を出す（ステップ５０７）。

一方、モニタリング項目及びモニタリング間隔の情報を受取った業務サーバ２及び記憶装置サブシステム３の双方又はいずれか一方は、受信したモニタエージェント名で指示されたモニタエージェントに対して、モニタリング項目として指定されたリソースの稼動等の情報の収集の開始を指示する。当該モニタエージェントは、モニタリング項目として指定されたリソースの稼動等の情報の収集を開始してモニタデータを作成する。この際、受信したモニタリング項目に対して指示されたモニタリング間隔が０であった場合には、業務サーバ２及び記憶装置サブシステム３は、当該モニタリング項目の情報収集を終了し、モニタリング項目の変更が完了したことを管理サーバ１に通知する。情報収集後、業務サーバ２及び記憶装置サブシステム３の双方又はいずれか一方は、管理サーバ１に収集したモニタデータを送信する。尚、業務サーバ２及び記憶装置サブシステム３は、管理サーバ１から指示されたモニタリング項目毎のモニタリング間隔に従いモニタリングを実施し、この間隔に従って取得したデータを管理サーバ１に転送する。

更に、チューニングの指示を受けた業務サーバ２及び記憶装置サブシステム３の双方又はいずれか一方は、ＤＢチューニングエージェント１０７、１１０を実行して、それぞれ指示内容に従ったチューニングを実施する。

次に、図１１を用いて、モニタエージェント制御実施処理５０４の手順例を説明する。管理サーバ１は、まず業務サーバ２から受取った要求がアプリケーション起動の通知であるか否かをチェックする（ステップ６０４）。アプリケーション起動要求の場合、管理サーバ１は、ステップ５０２及び５０３で取得されたアプリケーション名、モニタリング項目及びモニタリング間隔をアプリケーション状態記憶テーブル１１３に追加する。

アプリケーション起動の通知でない場合（すなわちアプリケーションの終了の通知）は、管理サーバ１は、業務サーバ２から通知されたアプリケーション名をフィールド８０１に持つレコード８０４をアプリケーション状態記憶テーブル１１３から削除する。次に管理サーバ１は、アプリケーション状態記憶テーブル１１３に設定されているモニタリング項目のそれぞれについて、以下の処理を行う。

まず管理サーバ１は、アプリケーション状態記憶テーブル１１３を参照して、１つのモニタリング項目に登録された各アプリケーションにおけるモニタリング間隔のうち、最小モニタリング間隔（正の整数値。ただし、０しかない場合又は０以下の数値が入っている場合は０）を求める（ステップ６０７）。次に管理サーバ１は、モニタエージェント管理テーブル１１５のモニタ項目名フィールド１００１を参照し、モニタリング項目名に一致するレコード１００４を選択、該レコード１００４のモニタエージェント名フィールド１００２及び装置名フィールド１００３を参照して、モニタリング項目をモニタリングするモニタエージェント名及び装置名を取得する（ステップ６０９）。そして、ステップ６０７で求めた値が０より大きい場合は、管理サーバ１は、当該モニタリング項目の名称、当該項目を監視するモニタエージェントの名称、及び最小モニタリング間隔をステップ６０９で取得された装置名で指定される業務サーバ２及び／または記憶装置サブシステム３に通知する。一方、０の場合は当該モニタリング項目に関するモニタリングの中止を業務サーバ２及び／または記憶装置サブシステム３に通知する（ステップ６０８）。

管理サーバ１は、アプリケーション状態記憶テーブル１１３に設定されているモニタリング項目全てについてステップ６０７、６０８の処理を繰り返す。
尚、モニタ制御情報記憶テーブル１１１、チューニング情報記憶テーブル１１２及びアプリケーション特性テーブル１０２への値の設定は、システム管理者が管理サーバ１のキーボードより入力することにより行う。

以下、アプリケーション特性テーブル１０２に図２に示すレコード２０３が、モニタ制御情報記憶テーブル１１１に図３に示すレコード３０５が、チューニング情報記憶テーブル１１２に図４に示すレコード７０４が、アプリケーションスケジュール１１４に図６に示すレコード９０３が、モニタエージェント管理テーブル１１５に図７に示すレコード１００４がそれぞれ記憶されている場合の、システムにおけるモニタリング及びチューニングの例について説明する。なお、当初は、アプリケーション状態記憶テーブル１１３にはレコード８０４は存在しないとする。

まず、アプリケーションスケジュールテーブル１１４のレコード９０３ａに示されるアプリケーション１（以下「ＡＰ１」）が起動された場合のシステムにおけるモニタリングの例について説明する。

業務サーバ２は、タイマに従い定期的に起動すべきアプリケーションがあるか否かをチェックする（図９のステップ４０２）。業務サーバ２は、図６のアプリケーションスケジュールテーブル１１４の各レコード９０３の起動時刻フィールド９０２の値とチェック時点の時刻とを比較することにより起動すべきアプリケーションのチェックを行う。

チェック時点の時刻が１０：００であるとすると、レコード９０３ａのフィールド９０２の値と一致するので、業務サーバ２は、レコード９０３ａのアプリケーション名フィールド９０１に記憶されたＡＰ１を起動することが判断できる。次に、業務サーバ２は、レコード９０３ａのフィールド９０１の値であるＡＰ１（アプリケーション名）を、管理サーバ１に転送する。業務サーバ２は同時に、このアプリケーション名を持つアプリケーションが起動されることも管理サーバ１に通知する。

アプリケーション名ＡＰ１のアプリケーションが起動するという情報を受取った管理サーバ１は、アプリケーション特性テーブル１０２を参照してアプリケーション名がＡＰ１であるレコード２０３ａを選択し、アプリケーション特性としてディスクアクセスパターンがランダムアクセスであることを取得する。

次に、管理サーバ１は、チューニング情報記憶テーブル１１２を参照し、ディスクアクセスパターンがランダムアクセスであるレコード７０４ａを選択し、選択したレコード７０４ａから、チューニング項目としてＤＢＭＳキャッシュサイズ及びそのチューニングルール（ヒット率が８５％以下ならＤＢＭＳキャッシュサイズを増やす）の情報を取得する。

さらに、管理サーバ１はモニタ制御情報記憶テーブル１１１を参照し、チューニング項目がＤＢＭＳキャッシュサイズであるレコード３０５ａを選択し、選択したレコード３０５ａのモニタリング項目（ＤＢＭＳキャッシュヒット率及びストレージプロセッサ利用率）及びモニタリング間隔の情報を取得する。この例では、ＤＢＭＳキャッシュヒット率のモニタリング間隔は１分毎、ストレージプロセッサの利用率のモニタリング間隔は０である。尚、上述したように、モニタリング間隔が０である場合は、モニタリングが行われないことを示している。

次に、管理サーバ１は、業務サーバ２から受取った要求がアプリケーション開始か終了かを判断する。この場合はＡＰ１の開始要求であるため、管理サーバ１は、図５のアプリケーション状態記憶テーブル１１３に、アプリケーション名がＡＰ１、ＤＢＭＳキャッシュヒット率のモニタリング間隔が１分、ストレージプロセッサのモニタリング間隔が０であるレコード８０４ａを追加する。その後、管理サーバ１はまずＤＢＭＳキャッシュヒット率について、最小モニタリング間隔の値を求める。この場合レコード８０４ａの１分毎という値が最小モニタリング間隔の値になる。次に管理サーバ１は、図７のモニタエージェント管理テーブル１１５を参照し、モニタリング項目名がＤＢＭＳキャッシュヒット率であるレコード１００４ａを取得し、該レコード１００４ａのフィールド１００２及び１００３を参照してモニタエージェント名（ＤＢモニタエージェント）及び装置名（業務サーバ２）を取得する。管理サーバ１は、ＤＢＭＳキャッシュヒット率のモニタリングを最小モニタリング間隔の値（ここでは１分間隔）、モニタリング項目名（ＤＢＭＳキャッシュヒット率）、及び当該モニタ項目の監視を実行するモニタエージェント名（ＤＢモニタエージェント）を、業務サーバ２に通知する。

次いで管理サーバ１は、ストレージプロセッサ使用率の最小モニタリング間隔の値を求める。本例においては、この時点ではアプリケーション状態記憶テーブル１１３にはレコード８０４ａしか登録されておらず、かつレコード８０４ａのストレージプロセッサ利用率のモニタリング間隔が０であるので、最小モニタリング間隔は０となる。次に管理サーバ１は、図７のモニタエージェント管理テーブル１１５を参照し、モニタリング項目名がストレージプロセッサ利用率であるレコード１００４ｂを取得し、該レコード１００４ｂのフィールド１００２及び１００３を参照してモニタエージェント名（モニタエージェント）及び装置名（記憶装置サブシステム）を取得する。モニタリング間隔が０であることはモニタリングを行わないことを示すため、管理サーバ１は、モニタリング項目名（ストレージプロセッサ利用率）、及び当該モニタ項目の監視を実行するモニタエージェント名（モニタエージェント）、及びストレージプロセッサ利用率のモニタリングを停止することを記憶装置サブシステム３に通知する。

ＤＢモニタエージェントが監視するＤＢＭＳキャッシュヒット率を１分間隔でモニタリングする通知を管理サーバ１より受けた業務サーバ２は、ＤＢモニタエージェントを実行して、１分間隔でＤＢＭＳ１０５のキャッシュヒット率をモニタリングし、得られたモニタデータを管理サーバ１に送付する。

次に、上述したシステムの状態でシステムがＤＢＭＳキャッシュサイズのチューニングを実施する例について示す。

ＤＢＭＳキャッシュヒット率の情報を収集した業務サーバ２は、その情報、すなわちモニタデータを、管理サーバ１に送信する。ＤＢキャッシュヒット率に関するモニタデータを受取った管理サーバ１は、チューニング情報記憶テーブル１１２を検索し、フィールド７０３に登録されたルールにＤＢＭＳキャッシュヒット率が含まれているレコード７０４を検索する。本例では、レコード７０４ａのフィールド７０３に登録されたルールでＤＢＭＳキャッシュヒット率が使用されているので、このレコード７０４ａが選択される。

管理サーバ１は、レコード７０４ａのフィールド７０３に設定された条件（ここでは「ＤＢＭＳキャッシュヒット率が８５％以下である」又は「ＤＢＭＳキャッシュヒット率が９５％以上である」）を、受け取ったモニタデータに含まれるＤＢキャッシュヒット率が満たすか否かを判定する。もし、受信したモニタデータに含まれるＤＢＭＳキャッシュヒット率が８５％を下回った場合、管理サーバ１は、レコード７０４ａのルール７０３に従い、レコード７０４ａのフィールド７０２に記述されたチューニング項目、ここではＤＢＭＳキャッシュサイズの変更を業務サーバ２に要求する。

ここでは、レコード７０４ａのルール７０３にあるように、ＤＢＭＳキャッシュサイズを５％増やす。ＤＢＭＳキャッシュサイズを５％増やした後、管理サーバ１は、図１０の性能管理プログラム１０１のステップ５０５でＤＢＭＳキャッシュサイズ変更後のモニタデータを受取り、まだＤＢＭＳキャッシュヒット率が８５％を下回っているようであれば、再度ＤＢＭＳキャッシュサイズを５％増やす処理を行う。このように、ＤＢＭＳキャッシュサイズが８５％を超えるまで、管理サーバ１は、キャッシュサイズを増加させる。
要求を受け取った業務サーバ２は、データベースチューニングエージェント１０７を実行することで、データベース管理システム１０５のキャッシュサイズの変更を実施する。

次に、ＡＰ１が起動している状態で、アプリケーション２（以下「ＡＰ２」とも言う）が起動した場合のシステムにおけるモニタリングの例について述べる。この時点で、図５のアプリケーション状態記憶テーブル１１３にはレコード８０４ａのみが記憶されているとする。

業務サーバ２は、アプリケーションスケジュールテーブル１１４を参照した時刻が１０：３０であると、アプリケーションスケジュールテーブル１１４から、起動時刻が１０：３０であるレコード９０３ｂを選択する。次に、業務サーバ２は、選択されたレコード９０３ｂのフィールド９０１からアプリケーション名ＡＰ２を取得し、管理サーバ１にアプリケーション２が起動することを通知する。

通知を受けた管理サーバ１は、ＡＰ１の時と同様の処理を行い、アプリケーション状態記憶テーブル１１３に、アプリケーション名がＡＰ２、ＤＢＭＳキャッシュヒット率のモニタリング間隔が１０分、ストレージプロセッサ使用率のモニタリング間隔が１秒であるレコード８０４ｂを追加する。

その後、管理サーバ１は、アプリケーション状態記憶テーブル１１３を参照して、まずＤＢＭＳキャッシュヒット率の最小モニタリング間隔を求め、さらにＤＢＭＳキャッシュヒット率のモニタリングを行うモニタエージェント名と該モニタエージェントが存在する装置名を、モニタエージェント管理テーブル１１５から取得する。本実施例の場合、ＡＰ１のモニタリング間隔とＡＰ２のモニタリング間隔を比較すると最小モニタリング間隔は１分であり、またモニタエージェント名はＤＢモニタエージェント、装置名は業務サーバであるので、管理サーバ１は、ＤＢモニタエージェントが監視するＤＢＭＳキャッシュヒット率を１分という最小モニタリング間隔で監視することを業務サーバ２に伝える。

次に管理サーバ１は、アプリケーション状態記憶テーブル１１３を参照して、ストレージプロセッサ利用率の最小モニタリング間隔と該ストレージプロセッサ利用率を監視するモニタエージェント名及び該モニタエージェントが存在する装置名を求める。この場合、レコード１００４ｂよりモニタエージェント名はモニタエージェント、装置名は記憶装置サブシステムであることが求まり、また最小モニタリング間隔はレコード８０４ｂの１秒となる。したがって、管理サーバ１は、記憶装置サブシステム３に対してモニタエージェント１０９が監視するストレージプロセッサ利用率を１秒間隔でモニタリングするよう通知する。
通知を受取った記憶装置サブシステム３は、モニタエージェント１０９を用いてプロセッサ３４の利用率のモニタリングを行い、得られた性能データを管理サーバ１に送付する。

次に、ＡＰ１とＡＰ２が起動している状態から、ＡＰ２が終了する場合のモニタリングの例について述べる。
業務サーバ２は、ＡＰ２の終了を検知すると、終了したアプリケーションの名称（ここではＡＰ２）と、当該アプリケーションが終了したことを管理サーバ１に通知する。

アプリケーション終了の通知を受取った管理サーバ１は、通知されたアプリケーション名に基づいて、アプリケーション特性テーブル１０２からレコード２０３ｂを、チューニング情報記憶テーブル１１２からレコード７０４ｂを、モニタ制御情報記憶テーブル１１１からレコード３０５ｂを、それぞれ取得する。その後、管理サーバ１は、アプリケーション状態記憶テーブル１１３からフィールド８０１の値がＡＰ２であるレコード８０４ｂを検索し、検索したレコード８０４ｂをアプリケーション状態記憶テーブル１１３から削除する。

その後管理サーバ１は、ＤＢＭＳキャッシュヒット率の最小モニタリング間隔をアプリケーション状態記憶テーブル１１３から求める。本例の場合、既にレコード８０４ｂが削除され、レコード８０４ａしかアプリケーション状態記憶テーブル１１３には存在しない。したがって、最小モニタリング間隔は、このレコード８０４ａのＤＢＭＳキャッシュヒット率モニタリング間隔（フィールド８０２ａの値）の１分となる。次に、管理サーバ１は、ＤＢＭＳキャッシュヒット率を監視するモニタエージェントの名称（ＤＢモニタエージェント）と当該モニタエージェントが存在する装置の名称（業務サーバ）を求め、モニタエージェント名とモニタリング項目名、及び先に求めた最小モニタリング間隔値を業務サーバ２に通知する。次に管理サーバ１は、ストレージプロセッサ使用率の最小モニタリング間隔を求める。この場合、レコード８０４ａのフィールド８０２ｂの値の０が採用される。

その後、管理サーバ１は、同様にモニタエージェント名（モニタエージェント）と装置名（記憶装置サブシステム）を求め、記憶装置サブシステム３に対して、「モニタエージェント」という名称のモニタエージェントが監視するストレージプロセッサ利用率のモニタリングを停止するよう通知する。

以上示したように、サーバで実行されるアプリケーションのアプリケーション特性に応じてモニタリング項目を変更することで、必要な項目のみのモニタリングを行うことが可能であることが示された。

次に、第二の実施形態の例について説明する。
図１２は、第二の実施形態が実施されるシステムの構成例を示す図である。業務サーバ２に新たにＡＰ目標に関する情報を記憶するＡＰ目標値テーブル１１６及び業務サーバ２の性能データを取得するＯＳモニタエージェント１１７が追加されている点が第一の実施形態とは異なる。又、モニタ制御情報テーブル１１１’の内容も第一の実施形態とは異なる。なお、第一の実施形態におけるシステムと第二の実施形態におけるシステムの双方を含むシステムも本発明に含まれる。本実施形態では、管理者等がシステムで実行されるアプリケーションに要求する性能に合致しない場合にシステムが管理者等へ報告する。したがって、本実施形態では、アプリケーションの特性に関連するチューニング項目が、管理者が指定する任意の性能目標の項目に置き換わる。

図１３は、第二の実施形態で使用されるモニタ制御情報記憶テーブル１１１’の構成例を示す図である。モニタ制御情報テーブル１１１’には、システムにおける個々の性能目標と、当該性能目標の達成を監視するために監視しなければならないモニタリング項目、及びモニタリング間隔の対応関係を示す情報が登録される。モニタ制御情報記憶テーブル１１１’は、個々の性能目標（以下「性能目標項目」）毎に対応するレコードを有する。

各レコードは、性能目標項目が登録されるフィールド１３０１、及び対応する性能目標項目において、どのモニタリング項目をどんな頻度でモニタリングするか（あるいはしないか）を示すフィールド１３０２を有する。本実施例では、トランザクション時間と平均Ｉ／Ｏ時間を性能目標項目とする場合に、モニタリング項目としてトランザクションの開始から終了までの時間を示すトランザクションレスポンス及び記憶装置サブシステム３に対するＩ／Ｏレスポンスの平均値を示す平均Ｉ／Ｏ時間をどのような間隔でモニタリングするか（あるいはしないか）をそれぞれフィールド１３０２ａ及び１３０２ｂに記憶している。尚、使用するアプリケーションによって、モニタリング項目も本実施形態で開示されない物になる場合がある。

図１４は、業務サーバ２で実行されるアプリケーションが達成しなければならない目標性能（以下「ＡＰ目標」）を記憶するＡＰ目標値テーブル１１６の構成例を示す図である。該テーブル１１６には、アプリケーション名と、当該アプリケーションが達成しなければならない性能目標項目及びその値が記憶される。該テーブル１１６は、アプリケーション毎にレコードを有する。各レコードは、アプリケーション名を示すフィールド１４０１、アプリケーションに対応する性能目標項目を示すフィールド１４０２及び性能目標値を示すフィールド１４０３を有する。なお、これらのフィールドへの値の設定は管理者が行う。

図１５は、本実施例におけるアプリケーション状態記憶テーブル１１３の構成例を示す図である。該テーブルの各レコードは、現在稼動しているアプリケーション名を記憶するフィールド８０１及び対応するアプリケーションのモニタリング項目のモニタリング間隔を示すフィールド８０２を有する。アプリケーション状態記憶テーブル１１３の各レコード８０４は、管理サーバ１が業務サーバ２からアプリケーション起動の通知を受けると追加され、終了の通知をうけると削除される。

図１６は、本実施形態におけるモニタエージェント管理テーブル１１５の構成例である。モニタエージェント管理テーブル１１５の各レコードは、モニタ項目名を記憶するフィールド１００１、該モニタ項目を監視するモニタエージェント名を記憶するフィールド１００２、及び該モニタエージェントが存在する装置名を記憶する装置名フィールド１００３を有する。尚、各々のテーブルの情報は、性能管理プログラム１０１を開始する前に、管理者がネットワーク等を介して各装置に登録する。

以下、図１７を用いて、本実施形態におけるシステムにおけるモニタリングの全体の流れを説明する。尚、以下プログラムが主語になる場合は、実際にはそのプログラムを実行するCPUによって処理が実行される。

まず、タイマにより業務サーバ２のアプリケーション制御プログラム１０３が起動される（ステップ４０１）。アプリケーション制御プログラム１０３は、アプリケーションスケジュールテーブル１１４を参照し、起動するアプリケーションの有無をチェックする。起動するアプリケーションがある場合、アプリケーション制御プログラム１０３は、ＡＰ目標値テーブル１１６を参照して起動されるＡＰの性能目標項目を取得し、管理サーバ１の性能管理プログラム１０１に、アプリケーション名とアプリケーションの起動、及び性能目標項目をネットワーク４を介して通知する（ステップ４０４、４０８）。

アプリケーション名と性能目標項目を受取った性能管理プログラム１０１は、モニタ制御情報記憶テーブル１１１を参照して性能目標項目に対するモニタリング項目とモニタリング間隔を取得する（ステップ５０３）。そして、性能管理プログラム１０１は、決定したモニタリング項目及びモニタリング間隔の情報を、管理サーバ２及び記憶装置サブシステム３のモニタエージェント１０６、１０９に通知する（ステップ５０４）。これ以降の処理概要は図８の場合と同一であり、ここでは説明を省略する。

以下、各装置における処理手順の詳細について説明する。尚、図１７と同じ番号は、それらの処理ステップが一致することを示す。

図１８は、本実施例において、業務サーバ２が、アプリケーション１０４の実行を開始する際に、アプリケーション制御プログラム１０３を実行することによって実施する処理例を示す図である。
業務サーバ２は、まずアプリケーションスケジュールテーブル１１４のフィールド１１４を参照して起動すべきアプリケーションがあるかどうかを判断する（ステップ４０２）。起動すべきアプリケーションがある場合、業務サーバ２は起動するアプリケーション名をフィールド９０１から取得し、さらにＡＰ目標値テーブル１１６から起動するＡＰの性能目標項目及び目標値を取得し、取得したアプリケーション名と性能目標項目、目標値、及びそのアプリケーション１０４を起動することをネットワークI/F２３を介して管理サーバ１に送信する（ステップ４０４）。その後の処理は図９の場合と同一であるためここでは説明を省略する。なお、本実施例では、モニタリング内容が変更された通知を受けているが、図９同様、通知を受けない構成でもよい。

図１９は、本実施形態における管理サーバ１が性能管理プログラム１０１を実行することで計算機システムのモニタリングを実施する際の処理手順例を示す図である。
まず管理サーバ１は、業務サーバ２からアプリケーション開始又は終了の通知があったか否かをチェックする（ステップ５０１）。次に、管理サーバ１は図１３に示すモニタ制御情報記憶テーブル１１１を参照し、業務サーバ２から通知された性能目標項目に対応するモニタリング項目とそのモニタリング間隔を取得する（ステップ５０３）。これ以降ステップ５０５までの処理は図１０の場合と同一であるためここでは説明を省略する。

モニタデータを受け取った管理サーバ１は、先に業務サーバ２から受け取った性能目標値とステップ５０５で受け取ったモニタデータを比較し（ステップ５０６）、モニタデータの値が目標を達成していない場合には、問題発生を管理者に通知する（ステップ５０７）。管理者への通知は、例えば管理端末（図示せず）への表示により行われる。

以下、モニタ制御情報記憶テーブル１１１に図１３に示すレコード３０５が、アプリケーションスケジュール１１４に図６に示すレコード９０３が、モニタエージェント管理テーブル１１５に図１６に示すレコード１００４がそれぞれ記憶されている場合の、システムにおけるモニタリング及びチューニングの例について説明する。なお、当初は、アプリケーション状態記憶テーブル１１３にはレコード８０４は存在しないとする。

まず、アプリケーションスケジュールテーブル１１４のレコード９０３ａに示されるアプリケーション１（以下「ＡＰ１」）が起動された場合のシステムにおけるモニタリングの例について説明する。

業務サーバ２は、タイマに従い定期的に起動すべきアプリケーションがあるか否かをチェックする（図１８のステップ４０２）。業務サーバ２は、図６のアプリケーションスケジュールテーブル１１４の各レコード９０３の起動時刻フィールド９０２の値とチェック時点の時刻とを比較することにより起動すべきアプリケーションのチェックを行う。

チェック時点の時刻が１０：００であるとすると、レコード９０３ａのフィールド９０２の値と一致するので、業務サーバ２は、レコード９０３ａのアプリケーション名フィールド９０１に記憶されたＡＰ１を起動することが判断できる。次に、業務サーバ２は、図１４に示すＡＰ目標テーブル１１６を参照し、レコード１４０４のＡＰ名フィールド１４０１の値が今回起動するＡＰの名称であるＡＰ１のレコードを探す。この場合はレコード１４０４ａがこれに該当する。その後、業務サーバ２は該レコード１４０４ａの性能目標項目フィールド１４０２及び性能目標値フィールド１４０３に記憶された値（トランザクション時間、及び３秒以下）を、先に取得したレコード９０３ａのフィールド９０１の値であるＡＰ１（アプリケーション名）と共に、管理サーバ１に転送する。業務サーバ２は同時に、このアプリケーション名を持つアプリケーションが起動されることも管理サーバ１に通知する。

アプリケーション名ＡＰ１のアプリケーションが起動する、またその性能目標項目がトランザクション時間であり性能目標値が３秒以下という情報を受取った管理サーバ１は、モニタ制御情報記憶テーブル１１１’を参照し、性能目標項目がトランザクション時間であるレコード３０５ｃを選択し、選択したレコード３０５ａのモニタリング項目（トランザクションレスポンス及び平均Ｉ／Ｏ時間）及びモニタリング間隔の情報を取得する。この例では、トランザクションレスポンスのモニタリング間隔は１分毎、平均Ｉ／Ｏ時間のモニタリング間隔は０である。尚、上述したように、モニタリング間隔が０である場合は、モニタリングが行われないことを示している。

次に、管理サーバ１は、業務サーバ２から受取った要求がアプリケーション開始か終了かを判断する。この場合はＡＰ１の開始要求であるため、管理サーバ１は、図５のアプリケーション状態記憶テーブル１１３に、アプリケーション名がＡＰ１、トランザクションレスポンスのモニタリング間隔が１分、平均Ｉ／Ｏ時間のモニタリング間隔が０であるレコード８０４ｃを追加する。その後、管理サーバ１はまずトランザクションレスポンスについて、最小モニタリング間隔の値を求める。この場合レコード８０４ｃの１分毎という値が最小モニタリング間隔の値になる。次に、図１６のモニタエージェント管理テーブル１１５を参照し、モニタリング項目名がトランザクションレスポンスであるレコード１００４ｃを取得し、該レコード１００４ｃのフィールド１００２及び１００３を参照してモニタエージェント名（ＤＢモニタエージェント）及び装置名（業務サーバ）を取得する。管理サーバ１は、トランザクションレスポンスのモニタリングを最小モニタリング間隔の値（ここでは１分間隔）、モニタリング項目名（トランザクションレスポンス）、及び当該モニタ項目の監視を実行するモニタエージェント名（ＤＢモニタエージェント）を、業務サーバ２に通知する。

次いで管理サーバ１は、平均Ｉ／Ｏ時間の最小モニタリング間隔の値を求める。本例においては、この時点ではアプリケーション状態記憶テーブル１１３にはレコード８０４ｃしか登録されておらず、かつレコード８０４ｃの平均Ｉ／Ｏ時間のモニタリング間隔が０であるので、最小モニタリング間隔は０となる。次に、図１６のモニタエージェント管理テーブル１１５を参照し、モニタリング項目名が平均Ｉ／Ｏ時間であるレコード１００４ｄを取得し、該レコード１００４ｄのフィールド１００２及び１００３を参照してモニタエージェント名（ＯＳモニタエージェント）及び装置名（業務サーバ）を取得する。モニタリング間隔が０であることはモニタリングを行わないことを示すため、管理サーバ１は、モニタリング項目名（平均Ｉ／Ｏ時間）、及び当該モニタ項目の監視を実行するモニタエージェント名（ＯＳモニタエージェント）、及び平均Ｉ／Ｏ時間のモニタリングを停止することを業務サーバ２に通知する。

ＤＢモニタエージェントが監視するトランザクションレスポンスを１分間隔でモニタリングする通知を管理サーバ１より受けた業務サーバ２は、１分間隔でＤＢＭＳ１０５のトランザクションのレスポンスタイムをモニタリングし、得られたモニタデータを管理サーバ１に送付する。

ステップ５０５で受け取ったトランザクションレスポンスが１秒である場合、これは目標性能値である３秒を達成しているのでループの先頭に戻る。もしレスポンスが１０秒であった場合には、ステップ５０８により、トランザクションレスポンスが性能目標値を達成しなかったことを管理者端末に表示する。ここでの表示項目には、性能目標値を達成しなかった性能目標項目（ここではトランザクション時間）、目標時間（３秒）、観測された時間（１０秒）等の情報が含まれる。

次に、ＡＰ１が起動している状態で、ＡＰ２が起動した場合のシステムにおけるモニタリングの例について述べる。この時点で、図１５のアプリケーション状態記憶テーブル１１３にはレコード８０４ｃのみが記憶されているとする。

業務サーバ２は、アプリケーションスケジュールテーブル１１４を参照した時刻が１０：３０であると、アプリケーションスケジュールテーブルテーブル１１４から、起動時刻が１０：３０であるレコード９０３ｂを選択する。次に、業務サーバ２は、選択されたレコード９０３ｂのフィールド９０１からアプリケーション名ＡＰ２を取得し、管理サーバ１にアプリケーション２が起動することを通知する。

通知を受けた管理サーバ１は、ＡＰ１の時と同様の処理を行い、アプリケーション状態記憶テーブル１１３に、アプリケーション名がＡＰ２、トランザクションレスポンスのモニタリング間隔が０（すなわちモニタリングしない）、平均Ｉ／Ｏ時間のモニタリング間隔が１分であるレコード８０４ｄを追加する。

その後、管理サーバ１は、アプリケーション状態記憶テーブル１１３を参照して、まずトランザクションレスポンスの最小モニタリング間隔を求め、さらにトランザクションレスポンスのモニタリングを行うモニタエージェント名と該モニタエージェントが存在する装置名を、モニタエージェント管理テーブル１１５から取得する。本例の場合、ＡＰ１のモニタリング間隔とＡＰ２のモニタリング間隔を比較すると最小モニタリング間隔は１分であり、またモニタエージェント名はＤＢモニタエージェント、装置名は業務サーバであるので、管理サーバ１は、ＤＢモニタエージェントが監視するトランザクションレスポンスを１分という最小モニタリング間隔で監視することを業務サーバ２に伝える。次に管理サーバ１は、アプリケーション状態記憶テーブル１１３を参照して、平均Ｉ／Ｏ時間の最小モニタリング間隔と該平均Ｉ／Ｏ時間を監視するモニタエージェント名及び該モニタエージェントが存在する装置名を求める。この場合、レコード１００４ｄよりモニタエージェント名はＯＳモニタエージェント、装置名は業務サーバであることが求まり、また最小モニタリング間隔はレコード８０４ｄの１分となる。したがって、管理サーバ１は、業務サーバ２に対してＯＳモニタエージェント１１７が監視する平均Ｉ／Ｏ時間を１分間隔でモニタリングするよう通知する。

通知を受取った記憶装置サブシステム３は、モニタエージェント１０９を用いてプロセッサ３４の利用率のモニタリングを行い、得られた性能データを管理サーバ１に送付する。

次に、ＡＰ１とＡＰ２が起動している状態から、ＡＰ２が終了する場合のモニタリングの例について述べる。
業務サーバ２は、ＡＰ２の終了を検知すると、終了したアプリケーションの名称（ここではＡＰ２）と、当該アプリケーションが終了したことを管理サーバ１に通知する。

アプリケーション終了の通知を受取った管理サーバ１は、通知されたアプリケーション名に基づいて、ＡＰ状態記憶テーブル１１３から、ＡＰ名がＡＰ２であるレコード８０４ｄを削除する。

その後管理サーバ１は、トランザクションレスポンスの最小モニタリング間隔をアプリケーション状態記憶テーブル１１３から求める。本例の場合、既にレコード８０４ｄが削除され、レコード８０４ｃしかアプリケーション状態記憶テーブル１１３には存在しない。したがって、最小モニタリング間隔は、このレコード８０４ｃのトランザクションレスポンスのモニタリング間隔（フィールド８０２ｃの値）の１分となる。次に、管理サーバ１は、トランザクションレスポンスを監視するモニタエージェントの名称（ＤＢモニタエージェント）と当該モニタエージェントが存在する装置の名称（業務サーバ）を求め、モニタエージェント名とモニタリング項目名、及び先に求めた最小モニタリング間隔値を業務サーバ２に通知する。次に管理サーバ１は、平均Ｉ／Ｏ時間の最小モニタリング間隔を求める。この場合、レコード８０４ｃのフィールド８０２ｄの値の０が採用される。

その後、管理サーバ１は、同様にモニタエージェント名（ＯＳモニタエージェント）と装置名（業務サーバ）を求め、業務サーバ２に対して、「ＯＳモニタエージェント」という名称のモニタエージェントが監視する平均Ｉ／Ｏ時間のモニタリングを停止するよう通知する。

以上示したように、本実施形態により、アプリケーションが性能目標を達成しているか否かを判断するためのモニタリング項目を、アプリケーションから性能目標を受け取ることにより変更することで、必要な項目のみのモニタリングを行うことが可能であることが示された。

尚、ＡＰ目標値テーブル１１６を管理サーバ１が有する構成としても良い。この場合、業務サーバ２は、自身で実行されるアプリケーションの名前と実行開始の情報を管理サーバ１へ伝える。そして管理サーバ１は、個々のテーブルを用いてモニタリング項目を特定する。

又、本実施形態では、システムの性能が設定された性能目標項目の値を満たさない場合、管理サーバ１は管理者等へ警告を通知していた。しかし、第一の実施形態と同様にチューニング方法に関する情報を管理サーバ１が有し、その情報に基づいて管理サーバ１がシステムの性能をチューニングする構成としても良い。

計算機及び記憶装置サブシステムを含むシステムの構成例を示す図である。 アプリケーション特性テーブルの構成例を示す図である。 モニタ制御情報記憶テーブルの構成例を示す図である。 チューニング情報記憶テーブルの構成例を示す図である。 アプリケーション状態記憶テーブルの構成例を示す図である。 アプリケーションスケジュールの構成例を示す図である。 モニタエージェント管理テーブルの構成例を示す図である。 システムモニタリングの流れの例を示す図である。 業務サーバでアプリケーションの実行を開始する際の処理の例を示す図である。 管理サーバでモニタリングの制御を実行する処理の例を示す図である。 モニタエージェントの制御方式を決定する処理の例を示す図である。 第二の実施例の計算機及び記憶装置サブシステムを含むシステムの構成例を示す図である。 第二の実施例における、モニタ制御情報記憶テーブルの構成例を示す図である。 アプリケーション目標値テーブルの構成例を示す図である。 第二の実施例における、アプリケーション状態記憶テーブルの構成例を示す図である。 第二の実施例における、モニタエージェント管理テーブルの構成例を示す図である。 第二の実施例における、システムモニタリングの流れの例を示す図である。 第二の実施例における、業務サーバでアプリケーションの実行を開始する際の処理の例を示す図である 第二の実施例における、管理サーバでモニタリングの制御を実行する処理の例を示す図である。

符号の説明

１…管理サーバ、２…データベースサーバ、３…記憶装置サブシステム、３１…ポート、３２…ディスクコントローラ、３３…制御メモリ、３４…プロセッサ、３５…キャッシュメモリ、３６…ディスク、３７…ネットワークインタフェース、４…ネットワーク。

Claims (14)

1. 業務計算機と記憶装置サブシステムとを含む計算機システムと、
   前記計算機システムと接続される管理計算機と、を有するシステムであって
   前記管理計算機は、アプリケーション名毎のアプリケーションプログラムの記憶装置サブシステムへのアクセスパターンを示したアプリケーション特性テーブルと、ディスクアクセスパターン毎のチューニング項目を記したチューニング情報記憶テーブルと、チューニング項目毎のモニタリング項目と前記モニタリング項目毎のモニタリング間隔の対応関係を示すモニタ制御情報記憶テーブルと、を記憶し、
   前記計算機システムは、前記管理計算機に前記計算機システムで実行される所定のプログラムの名前を通知し、
   前記管理計算機は、前記アプリケーション特性テーブルと、チューニング情報記憶テーブルと、モニタ制御情報記憶テーブルとに基いて、通知された前記所定のプログラムの名前に応じたモニタリング項目とモニタリング間隔を特定し、前記特定したモニタリング項及び前記特定したモニタリング間隔を指定したモニタリング開始指示を前記計算機システムに送信し、
   前記計算機システムは、前記通知の内容に基づいて前記特定されたモニタリング項目のモニタリング値を前記特定されたモニタリング間隔毎に収集する、
   ことを特徴とするシステム。
2. 前記計算機システムは、前記モニタリング値を、前記前記管理計算機に通知し、
   前記管理計算機は、通知された前記モニタリング値が所定の条件を満たさない場合には、前記計算機システムの設定を所定の値に変更する指示を前記計算機システムに送信し、
   前記計算機システムは、前記指示に基づいて自身の設定を変更することを特徴とする請求項１記載のシステム。
3. 前記計算機システムは、前記管理計算機に、前記所定のプログラムの名前を指定したプログラム終了通知を送信し、
   前記管理計算機は、前記アプリケーション特性テーブルと、チューニング情報記憶テーブルと、モニタ制御情報記憶テーブルとに基いて、前記前記所定のプログラムのに対応するモニタリング項目を特定し、特定したモニタリング項目のモニタリング停止指示を前記計算機システムに送信し、
   前記計算機システムは、前記モニタリング停止指示に基づいて、前記特定したモニタリング項目のモニタリング値の収集を停止することを特徴とする請求項２記載のシステム。
4. 前記アクセスパターンには、シーケンシャルアクセス及びランダムアクセスがあることを特徴とする請求項１記載のシステム。
5. 前記モニタリング項目には、前記記憶装置サブシステムが有するプロセッサの使用率があることを特徴とする請求項１記載のシステム。
6. 前記業務計算機では、前記記憶装置サブシステムが格納するデータにアクセスするデータベースマネジメントシステムが実行されており、前記モニタリング項目には、前記業務計算機が有するメモリの前記データベースマネジメントシステムによる使用率があることを特徴とする請求項５記載のシステム。
7. 前記所定の条件は、前記記憶装置サブシステムが有するプロセッサの使用率が所定の割合を超えないという条件であることを特徴とする、請求項６記載のシステム。
8. 業務計算機と記憶装置サブシステムとを含む計算機システムに接続される管理計算機であって、
   前記管理計算機は、アプリケーション名毎のアプリケーションプログラムの記憶装置サブシステムへのアクセスパターンを示したアプリケーション特性テーブルと、ディスクアクセスパターン毎のチューニング項目を記したチューニング情報記憶テーブルと、チューニング項目毎のモニタリング項目と前記モニタリング項目毎のモニタリング間隔の対応関係を示すモニタ制御情報記憶テーブルと、を記憶し、
   前記管理計算機は、
   （Ａ）前記計算機システムから、前記計算機システムで実行される所定のプログラムの名前を受信し、
   （Ｂ）前記アプリケーション特性テーブルと、チューニング情報記憶テーブルと、モニタ制御情報記憶テーブルとに基いて、通知された前記所定のプログラムの名前に応じたモニタリング項目とモニタリング間隔を特定し、
   （Ｃ）前記特定したモニタリング項及び前記特定したモニタリング間隔を指定したモニタリング開始指示を前記計算機システムに送信することで、前記計算機システムに、前記通知の内容に基づいて前記特定されたモニタリング項目のモニタリング値を前記特定されたモニタリング間隔毎に収集させる、
   ことを特徴とする管理計算機。
9. 前記管理計算機は、前記計算機システムから、前記モニタリング値を受信し、
   前記管理計算機は、通知された前記モニタリング値が所定の条件を満たさない場合には、前記計算機システムの設定を所定の値に変更する指示を前記計算機システムに送信し、
   前記計算機システムは、前記指示に基づいて自身の設定を変更することを特徴とする請求項８記載の管理計算機。
10. 前記管理計算機は、前記計算機システムから、前記所定のプログラムの名前を指定したプログラム終了通知を受信し、
    前記管理計算機は、前記アプリケーション特性テーブルと、チューニング情報記憶テーブルと、モニタ制御情報記憶テーブルとに基いて、前記前記所定のプログラムのに対応するモニタリング項目を特定し、特定したモニタリング項目のモニタリング停止指示を前記計算機システムに送信することで、前記特定したモニタリング項目のモニタリング値の収集を停止することを特徴とする請求項９記載の管理計算機。
11. 前記アクセスパターンには、シーケンシャルアクセス及びランダムアクセスがあることを特徴とする請求項８記載の管理計算機。
12. 前記モニタリング項目には、前記記憶装置サブシステムが有するプロセッサの使用率があることを特徴とする請求項８記載の管理計算機。
13. 前記業務計算機では、前記記憶装置サブシステムが格納するデータにアクセスするデータベースマネジメントシステムが実行されており、
    前記モニタリング項目には、前記業務計算機が有するメモリの前記データベースマネジメントシステムによる使用率があることを特徴とする請求項１２記載の管理計算機。
14. 前記所定の条件は、前記記憶装置サブシステムが有するプロセッサの使用率が所定の割合を超えないという条件であることを特徴とする、請求項１３記載の管理計算機。

Images