(57)【要約】      （修正有）【課題】情報システムの性能が不十分な場合に、チューニングの知識や経験を持った管理者がいない場合でも、性能不足の要因を特定する。【解決手段】複数のリソースの状態を監視し、チューニングに必要なリソース条件が満足されるとき、チューニンクを実行して、チューニング効果を測定する。リソース条件が満足されなくなるか、または、チューニング効果が一定の基準を満たさなくなるまでこれを繰り返す。チューニング結果に基づき、性能向上を阻害する要因を、リソース不足、アプリケーションの構造、外部要因のいずれか１つまたは複数に決定する。【選択図】図２
2010165042.tif 000002
【特許請求の範囲】
【請求項１】
複数のリソースを含む情報システムの性能管理装置であって、
前記情報システムのチューニング項目と、前記チューニング項目のチューニングに必要なリソース条件とを記憶したチューニング情報記憶手段と、
各前記リソースの状態を監視するリソース状態監視手段と、
前記チューニング項目に対応するリソース条件が満足されるか否かを、前記チューニング項目に対応するリソース条件により指定されるリソースの状態に基づき検査する検査手段と、
前記リソース条件が満足されるとき前記チューニング項目のチューニングを実行するチューニング実行手段と、
前記チューニングが実行された後、前記チューニング項目のチューニング効果を測定する効果測定手段と、
前記チューニング項目と、前記チューニングが実行されたか否かと、実行された場合の前記チューニング効果とを関連づけたチューニング結果情報を記憶するチューニング結果情報記憶手段と、
前記検査手段、前記チューニング実行手段、前記効果測定手段、前記チューニング結果情報記憶手段による一連の処理を繰り返し行うように制御する制御手段と、
前記チューニング結果情報記憶手段に記憶された前記チューニング結果情報に基づき前記情報システムの性能向上を阻害する要因を分析する分析手段と、
を備えた性能管理装置。
【請求項２】
前記制御手段は、前記チューニング項目に対応するリソース条件が満足されなくなったらまたは前記チューニング効果が一定の基準を満たさなくなったら、前記繰り返し制御を終了し、
前記分析手段は、性能向上を阻害する要因を、リソース不足、前記情報システムで稼働するアプリケーションの構造、外部要因のいずれか１つまたは複数に決定する
ことを特徴とする請求項１に記載の性能管理装置。
【請求項３】
選択手段と、取り消し手段とをさらに備え、
前記チューニング情報記憶部は、複数の前記チューニング項目と、前記複数のチューニング項目のそれぞれのチューニングに必要な複数の前記リソース条件とを記憶し、
前記選択手段は、前記チューニング情報記憶手段からチューニング項目を選択し、
前記検査手段、前記チューニング実行手段、前記効果測定手段、前記チューニング情報結果記憶手段は、前記選択手段により選択されたチューニング項目を処理の対象とし、
前記取り消し手段は、前記選択されたチューニング項目のチューニングの実行を、前記チューニングの効果測定が行われた後、取り消し、
前記制御手段は、前記選択手段、前記検査手段、前記チューニング実行手段、前記効果測定手段、前記チューニング結果情報記憶手段、前記取り消し手段による一連の処理を繰り返し行うように制御し、
前記選択手段は、前記制御手段による繰り返し制御において、前記チューニング情報記憶手段内の複数のチューニング項目をそれぞれ順番に選択することを繰り返し、
前記チューニング実行手段は、各前記チューニング項目について１回ずつ前記一連の処理が行われたら、各前記チューニング項目のうち最も効果が高かったチューニング項目のチューニングを実行する
ことを特徴とする請求項１に記載の性能管理装置。
【請求項４】
前記制御手段は、前記複数のチューニング項目のそれぞれに関して、前記チューニング項目に対応するリソース条件が満足されなくなったらまたは前記チューニング項目に対応するチューニング効果が一定の基準を満たさなくなったら、前記繰り返し制御を終了し、
前記分析手段は、各性能向上を阻害する要因を、リソース不足、前記情報システムで稼働するアプリケーションの構造、外部要因のいずれか１つまたは複数に決定する
ことを特徴とする請求項３に記載の性能管理装置。
【請求項５】
前記チューニング項目の前記チューニングは、前記チューニング項目に対応するチューニングパラメータを予め定められた量だけ更新することにより行う
ことを特徴とする請求項１ないし４のいずれか一項に記載の性能管理装置。
【請求項６】
前記チューニング情報記憶手段は、前記チューニング項目に対応するチューニングの効果を測定するために用いる測定対象リソースの情報を保持し、
前記効果測定手段は、チューニング後の前記測定対象リソースの状態と、チューニング前の前記測定対象リソースの状態とに基づいて前記チューニングの効果測定を行う
ことを特徴とする請求項１ないし５のいずれか一項に記載の性能管理装置。
【請求項７】
前記効果測定手段は、前記効果の測定前に、前記測定対象リソースの状態が安定するのを待機し、前記測定対象リソースの状態が安定した後で、前記効果測定を行う
ことを特徴とする請求項６に記載の性能管理装置。
【請求項８】
複数のリソースを含む情報システムの性能管理を行うコンピュータにおいて実行する性能管理プログラムであって、
前記コンピュータに
前記情報システムのチューニング項目と、前記チューニング項目のチューニングに必要なリソース条件とを記憶したチューニング情報記憶手段にアクセスするステップと、
各前記リソースの状態を監視するリソース状態監視ステップと、
前記チューニング項目に対応するリソース条件が満足されるか否かを、前記チューニング項目に対応するリソース条件により指定されるリソースの状態に基づき検査する検査ステップと、
前記リソース条件が満足されるとき前記チューニング項目のチューニングを実行するチューニング実行ステップと、
前記チューニング項目のチューニング効果を測定する効果測定ステップと、
前記チューニング項目と、前記チューニングが実行されたか否かと、実行された場合に測定された前記チューニング効果とを関連づけたチューニング結果情報をチューニング結果情報記憶手段に記憶する記憶ステップと、
前記検査ステップ、前記チューニング実行ステップ、前記効果測定ステップ、前記記憶ステップによる一連の処理を繰り返し行うように制御する制御ステップと、
前記チューニング結果情報記憶部に記憶された前記チューニング結果情報に基づき前記情報システムの性能を分析する分析ステップと、
を実行させるための性能管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報システムの性能不足の要因を分析する性能管理装置および性能管理プログラムに関する。
【背景技術】
【０００２】
現在の情報システムには、多くの利用者にサービスを提供するために、高い性能が要求される。情報システムの性能を向上させるための処置(チューニング)には、計算機リソースの追加やアプリケーションの修正など様々な項目があり、状況に応じて適切なものを実施する必要がある。このため、情報システムの性能向上を実現するためには、豊富な知識や経験が必要となる。
【０００３】
情報システムの性能を向上させる方法としては、特許文献１に開示された方法などが知られている。この方法では、遠隔から情報システム(ユーザシステム)の状態を監視し、状態に適したチューニングを実施することで情報システムの性能を向上させている。遠隔から性能向上サービスを提供することで、ユーザシステム側にチューニングの知識や経験を持った管理者がいない場合でもユーザシステムの性能を向上させることが可能である。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2005-18103号公報
【特許文献２】特開2002-268922号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
計算機リソースの不足やアプリケーションの構造に問題がある場合、チューニングを実施しても目標の性能が実現できない場合がある。しかし、特許文献１などの従来技術では、目標性能が達成できない場合に、その原因が特定できなかった。
【０００６】
情報システムの性能不足の要因を分析する方法としては、特許文献２に開示された方法などが知られているが、分析の単位がサーバ(計算機)であるため、すなわちボトルネックとなるサーバを特定できるのみであるため、詳細な分析(例えば、計算機リソース不足、不適切な設定、アプリケーションの構造のいずれが原因か)が行なえなかった。
【０００７】
本発明は、情報システムの性能が不十分な場合に性能不足の要因を特定することを可能とした性能管理装置および性能管理プログラムを提供する。
【課題を解決するための手段】
【０００８】
本発明の一態様としての性能管理装置は、
複数のリソースを含む情報システムの性能管理装置であって、
前記情報システムのチューニング項目と、前記チューニング項目のチューニングに必要なリソース条件とを記憶したチューニング情報記憶手段と、
各前記リソースの状態を監視するリソース状態監視手段と、
前記チューニング項目に対応するリソース条件が満足されるか否かを、前記チューニング項目に対応するリソース条件により指定されるリソースの状態に基づき検査する検査手段と、
前記リソース条件が満足されるとき前記チューニング項目のチューニングを実行するチューニング実行手段と、
前記チューニングが実行された後、前記チューニング項目のチューニング効果を測定する効果測定手段と、
前記チューニング項目と、前記チューニングが実行されたか否かと、実行された場合の前記チューニング効果とを関連づけたチューニング結果情報を記憶するチューニング結果情報記憶手段と、
前記検査手段、前記チューニング実行手段、前記効果測定手段、前記チューニング結果情報記憶手段による一連の処理を繰り返し行うように制御する制御手段と、
前記チューニング結果情報記憶手段に記憶された前記チューニング結果情報に基づき前記情報システムの性能向上を阻害する要因を分析する分析手段と、
を備える。
【０００９】
本発明の一態様としての性能管理プログラムは、
複数のリソースを含む情報システムの性能管理を行うコンピュータにおいて実行する性能管理プログラムであって、
前記コンピュータに
前記情報システムのチューニング項目と、前記チューニング項目のチューニングに必要なリソース条件とを記憶したチューニング情報記憶手段にアクセスするステップと、
各前記リソースの状態を監視するリソース状態監視ステップと、
前記チューニング項目に対応するリソース条件が満足されるか否かを、前記チューニング項目に対応するリソース条件により指定されるリソースの状態に基づき検査する検査ステップと、
前記リソース条件が満足されるとき前記チューニング項目のチューニングを実行するチューニング実行ステップと、
前記チューニング項目のチューニング効果を測定する効果測定ステップと、
前記チューニング項目と、前記チューニングが実行されたか否かと、実行された場合に測定された前記チューニング効果とを関連づけたチューニング結果情報をチューニング結果情報記憶手段に記憶する記憶ステップと、
前記検査ステップ、前記チューニング実行ステップ、前記効果測定ステップ、前記記憶ステップによる一連の処理を繰り返し行うように制御する制御ステップと、
前記チューニング結果情報記憶部に記憶された前記チューニング結果情報に基づき前記情報システムの性能向上を阻害する要因を分析する分析ステップと、
を実行させる。
【発明の効果】
【００１０】
本発明により、情報システムの性能が不十分な場合に性能不足の要因を特定できる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態としての性能管理装置１、２によって管理される情報システム（管理対象システム）を示す図。
【図２】本実施形態に係わる性能管理装置１、２の構成を示すブロック図。
【図３】チューニング情報記憶部に記憶されるチュ−ニング情報の例を示す図。
【図４】チューニング情報記憶部に記憶されるチューニング情報の例を示す図。
【図５】公開リソース情報記憶部に記憶される公開リソース情報の例を示す図。
【図６】チューニング管理部の動作の流れを示したフローチャート。
【図７】チューニング(T)の実施動作の詳細フローを示すフローチャート。
【図８】チューニング(T)の取り消し動作の詳細を示すフローチャート。
【図９】チューニング結果情報の例を示す図。
【図１０】リソース要求を受信した際の公開リソース管理部の動作を示すフローチャート。
【図１１】安定化確認要求を受信した際の公開リソース管理部の動作を示すフローチャート。
【図１２】性能管理装置１と性能管理装置２の連携を説明する図。
【図１３】結果分析部の動作の一例を説明するフローチャート。
【図１４】本実施形態におけるチューニング結果情報と分析結果の一例を示す図。
【図１５】本実施形態におけるチューニング結果情報と分析結果の別の一例を示す図。
【発明を実施するための形態】
【００１２】
以下、図面を参照しながら、本発明の実施形態について説明する。
【００１３】
図１は、本発明の一実施形態としての性能管理装置１、２によって管理される情報システム（管理対象システム）１１を示す。管理対象システム１１は、インターネット２１を介して、HTTPリクエスト等の負荷を生成する負荷生成装置（あるいはクライアント端末）３１に接続されている。
【００１４】
管理対象システム１１は、互いにネットワークを介して接続された、サーバ計算機１とサーバ計算機２とを備える。サーバ計算機２にはアプリケーションサーバ（ミドルウェア）と、本実施形態に係る性能管理装置１が配置され、サーバ計算機２にはデータベース管理システムと、本実施形態に係る性能管理装置２が配置されている。
【００１５】
アプリケーションサーバ上で動作するアプリケーションはアプリケーションサーバを介してクエリ（SQL）を、データベース管理システムに送信し、データベース管理システム上で動作するアプリケーションはクエリ（SQL）に基づきデータベース検索を実行し、検索結果を、データベース管理システムを介してアプリケーションサーバ上で動作するアプリケーションに返す。
【００１６】
アプリケーションサーバに対しては、スレッドプールサイズ(TP)とコネクションプールサイズ(CP)が設定可能である。スレッドプールサイズ（TP）はメモリにあらかじめ作成して溜めておくスレッドの個数のことであり、コネクションプールサイズ（CP）は、データベース管理システムとの間に継続的に張っておくコネクションの個数のことである。
【００１７】
データベース管理システムに対しては、クエリキャッシュサイズ(QC)と同時接続可能数(MC)が設定可能である。クエリキャッシュサイズ（QC）は検索結果を記憶しておくキャッシュのサイズのことであり、同時接続可能数（MC）はアプリケーションサーバとの間で同時に確立可能なコネクションの個数のことである。
【００１８】
ここでは初期値として、アプリケーションサーバには、スレッドプールサイズ（TP）＝５、コネクションプールサイズ（CP）＝１が設定されており、データベース管理システムには、クエリキャッシュサイズ（QC）=1MB、同時接続可能数（MC）=１が設定されているとする。
【００１９】
図２は、本実施形態に係わる性能管理装置の構成を示すブロック図である。図１の性能管理装置１、２はそれぞれ図２の構成を有する。
【００２０】
図２の性能管理装置は、各種データ（チューニング指示、リソース要求、安定化確認要求など）を受信する受信部１０１と、各種データ（たとえば公開リソース要求）を送信する送信部１０２と、CPUの利用率およびメモリの利用率などの計算機状態（リソース状態）を監視する計算機状態監視部（リソース状態監視手段）１０３と、チューニングを管理するチューニング管理部１０４と、チューニング結果を分析する結果分析部（分析手段）１０５と、外部コンポーネントに公開するリソース（公開リソース）を管理する公開リソース管理部１０６と、チューニングに必要な条件等を記述したチューニング情報を記憶するチューニング情報記憶部１０７と、チューニング結果を保持するチューニング結果記憶部１０８と、公開リソースの情報を記憶する公開リソース情報記憶部１０９とを備える。
【００２１】
チューニング管理部１０４は、たとえば本発明の選択手段、検査手段、チューニング実行手段、効果測定手段、取り消し手段を備える。またチューニング管理部１０４は、検査手段、チューニング実行手段、効果測定手段、チューニング結果記憶部１０８による一連の処理を繰り返し行うように制御する制御手段、また、選択手段、検査手段、チューニング実行手段、効果測定手段、チューニング結果記憶部１０８、取り消し手段による一連の処理を繰り返し行うように制御する制御手段を備える。
【００２２】
性能管理装置１のチューニング管理部１０４はアプリケーションサーバのチューニングを管理し、性能管理装置２のチューニング管理部１０４はデータベース管理システムのチューニングを管理する。
【００２３】
各機能部１０１〜１０９はハードウェアによって構成されても、ソフトウェアモジュールとして構成されてもよい。ソフトウェアモジュールの場合は、これらソフトウェアモジュールをプロセッサが記憶媒体から読み出して実行することで各機能部の処理が実現される。
【００２４】
以下ではまず性能管理装置１、２を動作させる前に事前に情報を記憶しておくチューニング情報記憶部１０７と公開リソース情報記憶部１０９について説明する。
【００２５】
チューニング情報記憶部１０７は、チューニング管理部１０４によってチューニングを行うにあたって必要な条件等をチューニング項目毎に記述したチューニング情報を記憶する。本実施形態ではシステムの性能を向上させるためのチューニングを想定する。
【００２６】
図３は、サーバ計算機１のチューニング情報記憶部１０７に記憶されるチュ−ニング情報の例を示す。図４は、性能管理装置２のチューニング情報記憶部１０７に記憶されるチューニング情報の例を示す。
【００２７】
図３および図４のチューニング情報は事前にチューニング情報記憶部１０７に記憶されている。チューニング情報は、チューニング項目の名称を記した項目名フィールドと、チューニングを行う際のチューニング項目の設定値の更新量（変更量）を事前に定義した更新量フィールドと、チューニングに必要なリソース条件を記した必要リソースフィールドと、チューニング効果を確認する判定基準を記した効果判定フィールドとを含む。
【００２８】
ここで、リソースとは、ソフトウェアを実行するために割り当てられるハードウェアの時間量や領域（範囲量）である。例えば、CPU利用率やメモリ量など、アプリケーションサーバやデータベース管理システム等のソフトウェアにより使用される計算機リソースである。また、チューニング項目とは、ソフトウェアの使用するリソースを変更するための動作を識別するための情報である。例えば、上述のチューニング項目の名称のものなどがある。また、リソース条件は、該チューニング項目毎に定義されるチューニングを実行するために必要となるリソースに関する制約条件である。
【００２９】
図３の例では、スレッドプールサイズ（TP）を増加させるチューニングは、スレッドプールサイズの設定値を５増やすことによって行なう。このチューニングは、CPU利用率が８０％以下（すなわち空き率が２０％以上）、空きメモリが１０MB以上のときに適用可能（実行可能）であり、チューニング効果の有無はCPU（測定対象リソース）の利用率があらかじめ定めた値以上増加したか否かで判定する。
【００３０】
またコネクションプールサイズ（CP）を増加させるチューニングは、コネクションプールサイズの設定値を３増やすことによって行なう。このチューニングは、CPU利用率が８０％以下（すなわち空き率が２０％以上）であり、空きメモリが１０MB以上であり、サーバ計算機２の公開リソースである同時接続可能数（MC）が「CPの現在値＋３」以上確保できるときに適用可能（実行可能）であり、チューニング効果の有無はCPU（測定対象リソース）の利用率があらかじめ定めた値以上増加したか否かで判定する。
【００３１】
図３の例で示される効果判定方法は一例であり、効果の判定は、別の方法、例えば、実際の応答時間またはスループットなどを用いても行なってもよい。
【００３２】
図４の例では、クエリキャッシュサイズ（QC）を増加させるチューニングは、クエリキャッシュサイズを１MB増やすことによって行う。このチューニングは空きメモリが１０MB以上のときに適用可能であり、チューニング効果の有無はロードアベレージ（測定対象リソース）があらかじめ定めた値以上低下したか否かで行う。ここでロードアベレージ低下の「ロードアベレージ」は、ＣＰＵの割り当てを待っているジョブ（ロード）の個数のアベレージ（平均）である。
【００３３】
公開リソース情報記憶部１０９は、外部コンポーネント（たとえばサーバ計算機１にとってのサーバ計算機２、あるいはサーバ計算機２にとってのサーバ計算機１）におけるチューニングに応じて値の変更が必要になることのあるリソース（公開リソース）の情報を記憶する。
【００３４】
図５は性能管理装置２の公開リソース情報記憶部１０９に記憶される公開リソース情報の例を示す。公開リソース情報は事前に公開リソース情報記憶部１０９に記憶されている。
【００３５】
図５の例では、同時接続可能数(MC)を増やすための条件として、空きメモリ容量が(１０×ＭＣの更新量)MB以上であり、かつ、ＭＣの更新量によらずCPU利用率が８０％以下であることが指定されている。たとえばMCを３個増やしたい場合は、空きメモリ容量が１０×３＝３０MB以上必要である。
【００３６】
次に、図６〜図８を用いて、チューニング管理部１０４の動作について説明する。
【００３７】
図６はチューニング管理部１０４の動作の流れを示したフローチャートである。
【００３８】
以下では、負荷生成装置３１からネットワーク２１を介してサーバ計算機１に負荷（たとえばＨＴＴＰリクエスト）を与えた状態で、たとえば開発者が、図示しない入力手段を用いて、性能管理装置１にチューニング指示を入力した場合を想定して説明を行う。チューニング指示は、サーバ計算機１の負荷が一定値以上になったら、自動的に性能管理装置１に対して入力されるようにしてもよい。
【００３９】
性能管理装置１へ入力されたチューニング指示は受信部１０１で受信され、受信部１０１からチューニング管理部１０４へ送られる（Ｓ１０１）。
【００４０】
チューニング管理部１０４はチューニング指示を受けると、カウンタ値を初期化し（カウンタ値を１にし）（Ｓ１０２）、さらにチューニングフラグをTrueに設定する（Ｓ１０３）。チューニングフラグは、性能管理装置１がチューニングを実行中であるか否かを示すフラグである。Trueはチューニング実行中を示し、Falseはチューニングが実行中でないことを示す。チューニングフラグは、後の説明から理解できるように、性能管理装置１、２間を連携させるための制御に用いられる。
【００４１】
続いて、チューニング管理部１０４は、内部変数(Tmax、Emax)の初期化を行なう（Ｓ１０４、Ｓ１０５）。Tmaxは、最も効果のあるチューニング項目を記憶するための変数であり、Tmaxは有効チューニング項目変数とも称される。Emaxはチューニング効果の最大値を記憶するための変数であり、Emaxは最大効果変数とも称される。
【００４２】
また、チューニング管理部１０４は、チューニング実行前のリソース状態の情報をシステム状態監視部１０３から取得し、これを事前状態情報として記憶する（Ｓ１０６）。リソース状態は、たとえばCPU使用率、メモリの空き率などである。
【００４３】
次に、チューニング管理部１０４は、チューニング情報記憶部１０７に記憶されている全てのチューニング項目を順次選択し（Ｓ１０７）、各選択したチューニング項目(T)のそれぞれについて以下の(1)〜(4)の処理（Ｓ１０８〜Ｓ１１５）を行なう。Ｓ１０７の順次選択の処理はチューニング管理部１０４が備える本発明の選択手段により行われる。
【００４４】
(1)チューニング(T)を実施する（Ｓ１０８）。
【００４５】
図７はチューニング(T)の実施動作のフローを示すフローチャートである。
【００４６】
まず、チューニング情報に基づいてチューニングの実施に必要なリソースをすべて確保する（Ｓ２１１、Ｓ２１２）。これはチューニング管理部１０４が備える本発明の検査手段により行う。例えば、チューニング項目としてスレッドプールサイズ（TP）の増加を実施する場合は、空きのCPU利用率が２０％以上であり、かつ空きのメモリ容量が１０MB以上あるか否かを検査し（図３参照）、これらの条件が満たされるときはこれらのリソースを確保する。チューニングの実施に必要なリソースに他のサーバ計算機（ここではサーバ計算機２）の公開リソース（リモートの公開リソース）が含まれるときは、当該公開リソースも確保する必要がある。この場合、リソース要求を他のサーバ計算機に送り、他のサーバ計算機から利用可能応答が返されたときはリソースが確保できたと判断し、利用不可応答が返されたときはリソースが確保できなかったと判断する。公開リソースの確保は他のサーバ計算機の公開リソース管理部１０６で行うが、この動作の詳細については後に説明する。
【００４７】
チューニングの実施に必要なリソースのうち確保できないリソースが１つでもある場合は（Ｓ２１３のＮＯ）、確保したリソースをすべて解放し（Ｓ２２０、Ｓ２２１）、そのチューニング項目を適用不可能（実施不可能）と判定する（Ｓ２２３）。
【００４８】
チューニングの実施に必要なリソースをすべて確保できた場合は（Ｓ２１３のＹＥＳ）、チューニング実施前のチューニング項目の設定値を「前値」として記憶した上（Ｓ２１４）、当該チューニング項目の設定値を変更する（Ｓ２１５）。これはチューニング管理部１０４が備える本発明のチューニング実行手段により行う。これにより、チューニングを実施する。設定値の変更は、前値＋事前定義変数により行う。事前定義変数は、図３または図４に示した更新量のことである。
【００４９】
チューニングを実施した後は、Ｓ２１３で確保したすべてのリソースの状態が安定化するのを待機する（Ｓ２１６〜Ｓ２１８）。リソースが安定したか否かは以下のようにして判断する。まず自サーバ計算機（ここではサーバ計算機１）のリソース（ローカルのリソース）については所定時間が経過したら安定化したと判断する。また他のサーバ計算機（ここではサーバ計算機２）の公開リソース（リモートの公開リソース）については当該他のサーバ計算機の公開リソース管理部１０６に安定化確認要求の送信により問い合わせることにより安定化を確認する。公開リソース管理部１０６の動作については後述する。
【００５０】
すべてのリソースが安定したら（Ｓ２１８のＹＥＳ）、そのチューニング項目を適用可能（実施可能）と判断する（Ｓ２１９）。
【００５１】
(2)次に、チューニング（T）が適用可能であったかを検査する（図６のＳ１０９）。
【００５２】
(3)チューニング（T）が適用可能な場合は(3a)から(3e)の処理を行なう。
(3a)計算機状態監視部１０３からリソース状態の情報を取得し、これを事後状態情報として記憶する（Ｓ１１０）。
(3b)チューニングの効果(Et)を測定する（Ｓ１１１）。これはチューニング管理部１０４が備える本発明の効果測定手段により行う。
(3c)効果（Et）が Emaxより大きいか否かを判定する（Ｓ１１２）
(3d)大きい場合は、EmaxとTmaxの値をそれぞれ更新する（Ｓ１１３）。すなわち現在のチューニング（T）の識別子をTmaxに代入し、Ｓ１１１で測定された効果（Et）をEmaxに代入する。
(3e)(3d)の後、またはEtが Emax以下である場合（Ｓ１１２のＮＯ）、実施したチューニング（T）を取り消す（Ｓ１１４）。これはチューニング管理部１０４が備える本発明の取り消し手段により行う。
【００５３】
図８はチューニングの取り消し動作（Ｓ１１４）の詳細を示すフローチャートである。チューニングの取り消しでは、まずチューニング(T)の設定を図７のＳ２１４で記憶した前値に戻す（Ｓ３０１）。次いで、チューニング実施時に確保したすべてのリソースを解放する（Ｓ３０２、Ｓ３０３）。
【００５４】
(4)実施したチューニング(T)を取り消したら、またはチューニング（T）が適用可能でなかった場合（Ｓ１０９のＮＯ）、チューニング結果情報を作成し、チューニング結果記憶部１０８に記憶する（Ｓ１１５）。チューニング結果情報は、カウンタ値と、チューニング項目名と、Ｓ１０９でのチューニングの適用可否と、Ｓ１０６で取得した事前状態情報と、Ｓ１１０で取得した事後状態情報とを関連づけたものである。チューニング結果情報の詳細は後述する（図９参照）。
【００５５】
すべてのチューニング項目についての処理が終了したら、Tmaxがnullであるか否かを検査し（Ｓ１１６）、nullでない場合は（ＹＥＳ）、Tmaxで表されるチューニング項目のチューニングを実施し（Ｓ１１７）、またカウンタを１増加させる（Ｓ１１８）。そして、フローを戻って、内部変数の初期化（Ｓ１０４、Ｓ１０５）、リソース状態情報（事前状態情報）の取得（Ｓ１０６）を行い、この後は、上記と同様にして、再度、すべてのチューニング項目を対象にＳ１０７〜Ｓ１１５を行う。Ｓ１１６〜Ｓ１１８の処理による繰り返しの制御はチューニング管理部１０４が備える本発明の制御手段により行われる。なおいったんチューニングが適用不可と判定されたチューニング項目については以降ステップＳ１０７での選択対象から除外して処理の不可を軽減するようにしてもよい。
【００５６】
このように、本実施例では、できるだけ高い性能を実現するために、すべてのチューニング項目のうち最も効果の高いチューニングを選択するが、例えば、効果のあるチューニングから無作為にチューニングを選択するなど、別の方法で選択を行ってもよい。
【００５７】
ステップＳ１１６において、Tmaxがnullであった場合は（Ｓ１１６のＮＯ）、チューニングフラグをFalseに設定し（チューニングフラグを初期化し）（Ｓ１１９）、結果分析部１０５に対し、チューニング結果記憶部１０８内に記憶したチューニング結果情報の分析を指示する（Ｓ１２０）。
【００５８】
図９は、チューニング結果情報の例を示す。
【００５９】
チューニング結果情報は、カウンタ値と、チューニング項目名と、チューニングの適用可否と、事前状態情報(PC：CPU利用率、PL：ロードアベレージ、PM：空きメモリ量)と、事後状態情報(CC：CPU利用率、CL：ロードアベレージ、CM：空きメモリ量)とを関連づけている。なお、ここでは、３つの情報（ＣＰＵ利用率、ロードアベレージ、空きメモリ量）を状態情報として用いているが、例えば、転送パケット数など別の情報を用いてもよい。
【００６０】
ここでは４つのチューニング結果情報（データ）D1〜D4が示される。
【００６１】
チューニング結果情報D1、D2はカウンタ値が１のときに、コネクションプールサイズ（CP），スレッドプールサイズ（TP）の各チューニング項目に対して生成されたものであり、チューニング結果情報D3、D4はカウンタ値が２のときに、コネクションプールサイズ（CP），スレッドプールサイズ（TP）の各チューニング項目に対して生成されたものである。
【００６２】
この例では、カウンタ値が１の間、コネクションプールサイズ（CP），スレッドプールサイズ（TP）の各チューニング項目のいずれもステップＳ１０９で適用可能と判断されている。この際、コネクションプールサイズ（CP）のチューニングの方が、効果が大きかったため、コネクションプールサイズ（CP）のチューニングが選択され（Tmaxにコネクションプールサイズ（CP）の識別子が格納され）、ステップＳ１１７で実施されている。カウンタ値が２のときは、いずれのチューニング項目もステップＳ１０９で適用不可と判断されたため、チューニングが行われることなく（ステップＳ１１６のＮＯ）、処理が終了している。
【００６３】
ここで図６のステップＳ１１１（効果（Et）の測定）の処理について補足説明を行う。
【００６４】
チューニングの効果（Et）の測定は、チューニング情報（図３、図４参照）を参照し、効果判定フィールドに指定される指標の事前状態情報と事後状態情報の値の差分を計算することによって行なう。例えば、図９のチューニング結果情報（データ）D１の場合、判定指標がCPUの利用率の増加であり、このとき事後CPU利用率CCが85、事前CPU利用率PCが30であることから、効果が55(=85-30)と計算される。なお、効果判定フィールドの内容（指標）がチューニング項目によって異なる場合は、効果の値を正規化することで、各チューニング項目間での効果の比較を行うことができる。
【００６５】
以下、図１０および図１１を用いて公開リソース管理部１０６の動作について説明する。
【００６６】
公開リソース管理部１０６は、相手のサーバ計算機（ここではサーバ計算機１）の性能管理装置から送信される、リソース要求と安定化確認要求に対してそれぞれ図１０および図１１の処理を行なう。
【００６７】
図１０は、リソース要求を受信した際の公開リソース管理部１０６の動作を示すフローチャートである。
【００６８】
相手のサーバ計算機（ここではサーバ計算機１）から図７のステップＳ２１２で公開リソース（たとえばMC）のリソース要求が送信され、これを受信部１０１で受信して、公開リソース管理部１０６に転送する（Ｓ４０１）。
【００６９】
公開リソース管理部１０６は、リソース要求を受けると、公開リソース情報記憶部１０９にアクセスし、公開リソース情報における該当公開リソースの更新条件（図５参照）を検査する（Ｓ４０２）。
【００７０】
例えば、性能管理装置２がサーバ計算機１から同時接続可能数(MC)のリソース要求を受けた場合は、サーバ計算機２のCPU利用率が８０％以下であるか否か、また空きメモリ容量が１０MB×更新量以上存在するか否かを検査する。たとえばサーバ計算機１におけるアプリケーションサーバのコネクションプールサイズ（CP）を更新するとき、MCを３つ増加させる必要があるため（図３参照）、このとき空きメモリ容量は１０MB×３＝３０MB以上存在する必要がある。
【００７１】
検査の結果、更新条件を満たさない場合は（Ｓ４０３のＮＯ）、相手のサーバ計算機（ここではサーバ計算機１）に利用不可応答を返す（Ｓ４０４）。
【００７２】
一方、検査の結果、更新条件を満たす場合は（Ｓ４０３のＹＥＳ）、公開リソースのリソース利用量を更新する(設定値を変更する)（Ｓ４０５）。
【００７３】
次に、安定化フラグをFalseに設定する（Ｓ４０６）。すなわち、公開リソースの設定値に変化があったときは、安定化フラグをFalseに設定することで、後に図１１で説明するように自サーバ計算機（ここではサーバ計算機２）側でチューニングを行うようにし向ける。この後、相手のサーバ計算機に利用可能応答を返す（Ｓ４０７）。
【００７４】
図１１は、安定化確認要求を受信した際の公開リソース管理部１０６の動作を示すフローチャートである。
【００７５】
相手のサーバ計算機（ここではサーバ計算機１）から図７のステップＳ２１７で安定化確認要求が送信され、これを受信部１０１で受信して、公開リソース管理部１０６に転送する（Ｓ５０１）。
【００７６】
公開リソース管理部１０６は、安定化確認要求を受けると、安定化フラグを検査する。
【００７７】
安定化フラグがTrueの場合は（Ｓ５０２のＹＥＳ）、安定応答を返す（Ｓ５０３）。
【００７８】
安定化フラグがFalseの場合は（Ｓ５０２のＮＯ）、チューニングフラグを検査する（Ｓ５０４）。
【００７９】
チューニングフラグがTrueの場合は（Ｓ５０４のＹＥＳ）、チューニングの終了を待機する（Ｓ５０６）。チューニングフラグがFalseの場合は（Ｓ５０４のＮＯ）、チューニング管理部１０４にチューニングを指示し、チューニングの終了を待機する（Ｓ５０６）。なお、初期状態ではチューニングフラグはFalseである。チューニングの指示を受けたチューニング管理部１０４は図６のフローチャートに示した処理を行うことによりチューニングを行う。
【００８０】
チューニング管理部１０４によるチューニングが終了したら安定化フラグをTrueに設定し（Ｓ５０６）、相手のサーバ計算機に安定応答を返す（Ｓ５０３）。
【００８１】
このように、安定化確認要求の受信とチューニングの実施を関連づけることによって、複数の性能管理装置（ここでは性能管理装置１、２）を連携させることが可能となる。
【００８２】
図１２を用いて性能管理装置１と性能管理装置２の連携についてさらに詳細に説明する。図１２は、性能管理装置１でコネクションプールサイズ（CP）増加のチューニングを実施する場合（図６のS107で「CP増加」を選択した場合）の処理の流れを示している。なお、図１２では、２つの性能管理装置の連携に関係しない処理は一部を除いて省略されている。
【００８３】
図３を参照するとCP増加を実施するためには、「CPの現在値＋３」の同時接続可能数（MC）がサーバ計算機２において必要である。
【００８４】
そこで、性能管理装置１は、まず、CP増加のチューニングを実施する前に、性能管理装置２に対し同時接続可能数（MC）に関するリソース要求を送信する（Ｓ６０１）。
【００８５】
性能管理装置２は、リソース要求を受信すると図１０のフローチャートの処理を行う。ここでは、性能管理装置２から利用可能応答（図１０のＳ４０７参照）が返信されるものとする（Ｓ６０２）。
【００８６】
性能管理装置１は、利用可能応答を受信すると、設定の変更を行うことによりCP増加のチューニングを実施し（図７のＳ２１５参照）、リソースの安定化を待機する（図７のＳ２１８参照）。この際、性能管理装置１は、安定化確認要求を性能管理装置２に送信する（Ｓ６０３）。
【００８７】
性能管理装置２は、安定化確認要求を受信すると図１１のフローチャートの処理を実行する。この際、性能管理装置２の公開リソース管理部１０６からチューニング管理部１０４にチューニングが指示され（図１１のＳ５０５参照）、サーバ計算機２でのチューニングが実施される。性能管理装置２は、チューニングが終了したら、安定応答を返す（図１１の５０５参照）（Ｓ６０４）。
【００８８】
図１３〜図１５を用いて、結果分析部１０５の動作について説明する。
【００８９】
図１３は、結果分析部１０５の動作の一例を説明するフローチャートである。
【００９０】
結果分析部１０５は、チューニング管理部１０４により生成されたチューニング結果情報をチューニング結果記憶部１０８から読み出し、チューニング項目毎に図１３の処理を行なう。例えば、図９のチューニング結果情報が対象の場合は、CP増加(データD1とD3)、およびTP増加(データD2とD4)のそれぞれについて図１３に示す結果分析フローの処理を行なう。
【００９１】
結果分析部１０５は、まず、該当チューニング項目が一回以上適用可能であったかを検査する（Ｓ７０１）。これは、該当チューニング項目に関するチューニング結果情報のうち、「適用」の値が可となっているものが１つ以上あるか否かによって検査する。
【００９２】
ここで、適用可能が１つもなかった場合は、性能不足の要因が、ローカルリソースの不足(Lr)の可能性が中程度(2)で、ローカルアプリケーションの構造(La)の可能性が小さく(1)、外部コンポーネント（ここではサーバ計算機２）の可能性がほぼ無い(0)と判断する（Ｓ７０２）。すなわちローカルリソース不足の可能性が高いが、アプリケーションの可能性もあると判断する。なお、ここでローカルとは性能管理装置が配置された計算機（ここではサーバ計算機１）のことである。
【００９３】
一回以上適用可能であった場合は、一回以上効果があったか否か（一定の基準を満たしたか否か）をチューニング結果情報とチューニング情報を利用して検査する（Ｓ７０３）。具体的には、チューニング管理部による図６のＳ１１１と同様にして効果の測定を行って差分を求め、求めた差分があらかじめ定めた値以上のときは効果があったと判定し、あらかじめ定めた値未満のときは効果が無かったと判定する。
【００９４】
効果が無かった場合は、性能管理装置が配置される計算機（ここではサーバ計算機１）の負荷が高いか否かを、チューニング結果情報に含まれる事後のリソース状態に基づき検査する（Ｓ７０４）。
【００９５】
負荷が高い場合（たとえばある閾値を超える場合）は、ローカルアプリケーションの構造が性能不足要因である可能性が高いと判断する（Ｓ７０５）。すなわち、負荷が高くローカルリソースも余っているのに性能向上できないのでローカルアプリケーションの構造が問題である可能性が高いと判断する。一方、負荷が低い場合（たとえばある閾値以下の場合）は、外部コンポーネントが性能不足要因である可能性が高いと判断する（Ｓ７０６）。すなわちそもそも負荷が高くなく、当該計算機に性能不足要因がない可能性が高いと判断する。
【００９６】
チューニング項目が一回以上適用可能でありかつ一回以上効果が有った場合は、該チューニング項目の終了条件を検査する（Ｓ７０７）。終了条件は、チューニング結果情報においてカウンタ値が最も大きいデータから判定する。
【００９７】
カウンタ値が最大のデータの「適用」項目が不可である場合は、終了条件は「適用不可」と決定し、カウン値が最大のデータについて効果が無かった場合は、終了条件は「効果無し」と決定する。
【００９８】
終了条件が適用不可である場合は、ローカルリソースの不足が性能不足要因である可能性が高いと判断する（Ｓ７０８）。すなわち効果のあるチューニングが適用できなくなったのでリソース不足の可能性が高いと判断する。
【００９９】
終了条件が効果無しである場合は、性能管理装置が配置される計算機（ここではサーバ計算機１）の負荷を、上記カウンタ値が最大のデータ（チューニング結果情報）と、チューニング情報とを利用して検査する（Ｓ７０９）検査の方法は上記Ｓ７０４と同様にして行うことができる。
【０１００】
負荷が高い場合は、ローカルリソースの不足の可能性がほぼ無く、ローカルアプリケーションの構造の可能性が中程度で、外部コンポーネントの可能性が小さいと判断する（Ｓ７１０）。すなわち、効果がなくなったためローカルアプリケーションの構造が問題である可能性が高いが、既に最適化されている可能性もあり、他の計算機を修正することが必要な可能性もあると判断する。
【０１０１】
一方、負荷が低い場合は、外部コンポーネントの可能性が高いと判断する（Ｓ７１１）。すなわちそもそも負荷が高くなく、当該計算機に性能不足要因がない可能性が高いと判断する。
【０１０２】
なお、図１３の動作例はあくまで分析の一例であり、他の形態をとることも可能である。例えば、負荷の測定を、実際の応答時間、またはスループットによって行なってもよい。また、例えば、「適用不可」の場合に、不足しているリソースをより詳細に検査(メモリかあるいはCPUかなど)してもよい。
【０１０３】
図１４に、本実施形態におけるチューニング結果情報と分析結果の一例を示す。ここではサーバ計算機１のCPUの処理能力が不足している場合の例が示される。CPUの処理能力が低いためスレッドプールやコネクションプールのサイズを増やすことで、すぐにCPUの利用率が高くなってしまう。このため図示のようなチューニング結果情報および分析結果が得られている。
【０１０４】
14aは性能管理装置１をチューニングして得られたチューニング結果情報であり、14bは性能管理装置１と連携されてチューニングが行われた性能管理装置２のチューニング結果情報を示す。また14cは性能管理装置１の分析結果を示し、14dは性能管理装置2の分析結果を示す。
【０１０５】
分析結果14c、14dから、性能管理装置１ではローカルリソースの不足が性能不足要因の可能性が高いと判断され、性能管理装置２では外部コンポーネントが性能不足要因の可能性が高いと判断される。
【０１０６】
これらの結果から、サーバ計算機１の計算機リソース不足が性能不足の要因であることが容易に判断できる。
【０１０７】
図１５に、本実施形態におけるチューニング結果情報と分析結果の別の一例を示す。データベース管理システムの利用においてメモリが効率的に利用できない場合の例が示される。データベース管理システムでクエリキャッシュのサイズを増やしても性能を向上させることができないため、図示のようなチューニング結果情報および分析結果が得られている。
【０１０８】
15aは性能管理装置１をチューニングして得られたチューニング結果情報であり、15bは性能管理装置１と連携されてチューニングが行われた性能管理装置２のチューニング結果情報を示す。また15cは性能管理装置１の分析結果を示し、15dは性能管理装置2の分析結果を示す。
【０１０９】
分析結果15c、15dから、性能管理装置1では外部コンポーネントが性能不足要因の可能性が高いと判断され、性能管理装置２ではローカルアプリケーション（データベース管理システムを利用するアプリケーション）の構造が性能不足要因の可能性が高いと判断される。
【０１１０】
これらの結果から、データベース管理システムの利用に関連する部分のアプリケーションの構造が性能不足の要因であることが容易に判断できる。
【０１１１】
本実施の形態では、性能管理装置をサーバ計算機１、２にそれぞれ分けて搭載したが、サーバ計算機１、２に対して１つの性能管理装置を配置し、１つの性能管理装置でサーバ計算機１、２に対するチューニング等の処理を行うようにしてもよい。この場合、公開リソースを介した性能管理装置間の連携は不要になるため、処理を効率的に行うことができる。
【０１１２】
また本実施の形態では２つのサーバ計算機１，２によって情報システム（管理対象システム）が形成されていたが、情報システムは１つのサーバ計算機によって形成されてもよい。またこの場合、当該１つのサーバ計算機のチューニング項目数は１つであっても複数であっても本発明は適用可能である。
【０１１３】
このように、本実施形態によれば、性能不足の要因が、計算機リソースの不足であるのか、あるいはアプリケーションの構造であるかを容易に分析することが可能となる。また本実施形態によれば、このように、情報システムの性能が不十分な場合に、その理由が特定できるため、正確な対応が可能となる。例えば、アプリケーションの構造に問題がある場合に、無駄なハードウェアを購入するなどの状況を避けることができる。
【符号の説明】
【０１１４】
１：性能管理装置、サーバ計算機
２：性能管理装置、サーバ計算機
１０１：受信部
１０２：送信部
１０３：計算機状態監視部（リソース状態監視手段）
１０４：チューニング管理部（選択手段、検査手段、チューニング実行手段、効果測定手段、取り消し手段、制御手段）
１０５：結果分析部（分析手段）
１０６：公開リソース管理部
１０７：チューニング情報記憶部
１０８：チューニング結果記憶部
１０９：公開リソース情報記憶部
【図１】
2010165042.tif 000003
【図２】
2010165042.tif 000004
【図３】
2010165042.tif 000005
【図４】
2010165042.tif 000006
【図５】
2010165042.tif 000007
【図６】
2010165042.tif 000008
【図７】
2010165042.tif 000009
【図８】
2010165042.tif 000010
【図９】
2010165042.tif 000011
【図１０】
2010165042.tif 000012
【図１１】
2010165042.tif 000013
【図１２】
2010165042.tif 000014
【図１３】
2010165042.tif 000015
【図１４】
2010165042.tif 000016
【図１５】
2010165042.tif 000017