JP4912401B2 - パフォーマンス情報およびイベント情報を適応的に収集するシステムおよび方法 - Google Patents

Description

本発明は、コンピュータ・システム内で情報を適応的に収集する方法および装置に関する。具体的には、本発明の一態様では、永続メモリ（ｐｅｒｓｉｓｔｅｎｔ ｍｅｍｏｒｙ）に格納する前にデータを効率的に集約または圧縮することが可能である。

多くの場合、コンピュータ・システムは、パフォーマンス情報またはイベント情報あるいはその両方を収集する必要がある。パフォーマンス情報は、ＣＰＵ（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）使用率、応答時間、メモリ使用量、Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）帯域幅などの測定値を含み得るが、これらに限定はされない。システムは幅広い種類のイベントを監視し得る。例えばウェブ・サーバは、多くの場合、受信したｈｔｔｐ要求を記憶する。データベース・トランザクションが記録されることもある。システムは、デバッグ目的のためまたはプログラムの実行をプロファイルするために、情報を記憶することもある。

情報を記録することはオーバーヘッドを招く。ディスクに情報を格納することは、Ｉ／Ｏ帯域幅を消費し、コンテキスト・スイッチを必要とすることもある。パフォーマンスに悪影響を及ぼし得る。加えて、多量のディスク・スペースが消費されることもある。情報を記録することの重要性、および情報を多く記録しすぎることにより起こり得る大きなオーバーヘッドを理由に、パフォーマンス情報およびイベント情報を収集するより効率的な方法が必要とされている。

例えば、コンピュータ・システムに関するパフォーマンス情報を取得するのに利用可能なツールがいくつかある。Ｕｎｉｘ（Ｔｈｅ Ｏｐｅｎ Ｇｒｏｕｐの登録商標）オペレーティング・システム（ｗｗｗ．ｕｎｉｘ．ｏｒｇ）は、パフォーマンス情報の取得用に／ｐｒｏｃなどの複数の機能を有する。マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ（ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ））からのＷｉｎｄｏｗｓ（マイクロソフト社の登録商標）オペレーティング・システムも、パフォーマンス情報の提供用にいくつかの機能を有する。ＩＢＭ社は、Ｔｉｖｏｌｉ（ＩＢＭ社の登録商標）ファミリーのソフトウェア製品（ｗｗｗ．ｔｉｖｏｌｉ．ｃｏｍ）により、コンピュータ・システムに関するパフォーマンス情報を収集するツールをいくつか提供している。

これら既存のソリューションの主要な問題は、収集される情報が過多になる可能性があることである。これにより、パフォーマンス情報収集のオーバーヘッド（ＣＰＵおよび記憶装置両方に関して）が大きくなりすぎる可能性がある。

イベント情報を適応的に収集してオーバーヘッドを低減することが本発明の目的である。特に、本発明の一態様においては、ＣＰＵのオーバーヘッドおよびスペースのオーバーヘッド両方のバランスをとる方法が提供される。

本発明の他の具体的な態様は、例えば、格納される情報量を減らすために複数のエンティティをより少ない数のエンティティに集約しデータを圧縮する技術を含む。

したがって本発明により、第１コンピューティング・ノードと、第２コンピューティング・ノードおよび記憶デバイスのうちの少なくとも１つとから成るシステムにおいて、第１コンピューティング・ノードから次のうちの少なくとも１つ、すなわち記憶デバイスおよび第２コンピューティング・ノードのうちの少なくとも１つへ情報を伝達する方法が提供される。本発明では、利用可能なリソースについての見積もりを少なくとも１つ収集するためにコンピューティング・ノードが監視され、その見積もりに基づいてデータ量が変更される。続いて、変更されたデータが次のうちの少なくとも１つ、すなわち記憶デバイスおよび第２コンピューティング・ノードのうちの少なくとも１つへ送信される。

加えて、本発明により、データ集約に最適なバッチ・サイズの決定が実現される。そこでは、いくつかのバッチ・サイズに関して、バッチ化された情報を永続記憶装置へ送信するコスト、およびバッチ化されたデータの喪失の複数のコストが見積もられる。続いて、これらのコストの合計に基づき、いくつかの異なるバッチ・サイズから最適なバッチ・サイズが選択される。

さらに、本発明によりデータの選択的な圧縮が実現される。そこでは、いくつかの圧縮アルゴリズムのうち、利用可能なリソースを上回るオーバーヘッドを招かないのはどれであるかが決定される。続いて、決定された複数のアルゴリズムのうちの１つが圧縮を最大化するよう選択される。

図１は、本発明の機能を有するシステムを表す。１つまたは複数のアプリケーション・プロセス１１が、永続記憶装置１２に情報を記憶する情報ロガー（ｌｏｇｇｅｒ）１０と通信している。ディスク、ＤＡＳＤおよびＣＤが永続記憶装置の例である。

アプリケーション・プロセスは、例えば、ＣＰＵ使用率、応答時間、Ｉ／Ｏ帯域幅、ネットワーク帯域幅などのパフォーマンス統計に関して監視されている実行プログラムを含むとよい。次に、監視の結果生じるＣＰＵ使用率などの統計が情報ロガーへ送信される。ロガーは、例えば、種々のベンダから入手できる標準的なプログラミング言語（例えば、Ｊａｖａ（サンマイクロシステムズ社の登録商標）、Ｃ、Ｃ＋＋、アセンブリ、機械語など）を使用してソフトウェア内に実装することも可能である。この例における本発明の一態様は、どれだけの情報をどの形式で、永続記憶装置への記憶用に情報ロガーへ送信するかを決定することである。

図２は、本発明の機能を有する別のシステムを表す。異なる複数の情報ロガー２１が、別々のアプリケーション・プロセス２０に関連付けられている。これは、単一の情報ロガーが複数のアプリケーション・プロセスに関連付けられている図１とは対照的である。

図３に描かれているように、アプリケーション・プロセスを実行し得るプロセッサ３０が、パフォーマンス・モニタ３１により監視されるとよい。パフォーマンス・モニタ３１は、ＣＰＵに加えて任意選択で、Ｉ／Ｏ、ネットワークまたはディスクあるいはその全てを監視してもよい。

パフォーマンス・モニタは、例えば、種々のベンダから入手できる標準的なプログラミング言語（例えば、Ｊａｖａ（登録商標）、Ｃ、Ｃ＋＋、アセンブリ、機械語など）を使用してソフトウェア内に実装することも可能である。

本発明の一例では、パフォーマンス・モニタは、実行中のコンピュータ・プログラムなど、プロセッサ３０で実行されているアプリケーション・プロセスからのＣＰＵ使用率などのパフォーマンス結果を情報ロガーへ送信してもよく、続いて情報ロガーは、どの結果を永続記憶装置に格納するかを選択する。

図４は、本発明の動作方法の流れ図を表す。ステップ４０では、少なくとも１つのアプリケーションが少なくとも１つのプロセッサ３０上で実行されており、情報が定期的に永続記憶装置１２へ送信される。永続記憶装置へ情報を送信するためのオーバーヘッドは、時々大きくなることもある。ステップ４０において、図３のパフォーマンス・モニタ３１が、情報を格納するためのオーバーヘッドの量を判断するために使用されてもよい。

情報を格納するためのオーバーヘッドの量が大きいと判断されると、処理はステップ４３へ進むとよい。ステップ４３において、システムは情報格納のためのオーバーヘッドを低減させる。そうするためには、次のいくつかの方法のうちの少なくとも１つを使用するとよい。
１．情報を定期的に収集する。この場合、情報収集の頻度を下げることでオーバーヘッドを低減させられる。
２．システムが、例えばシステムのパフォーマンス特性などを表し得る数列を収集している場合、新たな値が決定されるたびに新たな数値を格納するのではなく、いくつかの値の平均を永続記憶装置に保存する。いくつかの値の平均を時々永続的に格納する。オーバーヘッドを低減させるために、永続記憶装置に格納される前に平均される値の数がステップ４３で増やされてもよい。
３．最後の平均がディスクに格納されて以降の数値の平均だけではなく、移動平均を格納する。例えば、ディスクに数値を格納するまでに、システムは新たな数値を５つ受信すると仮定する。５０の最新数値の移動平均は、５０の最新数値の平均に相当する。ディスクへの最終書き込み以降に受信された５つの数値の単純平均を格納するのではなく、この移動平均を格納してもよい。
４．ディスクに全ての値を格納する前に主記憶装置にいくつかの値を保存する。この、永続記憶装置の更新のバッチ化により、受信してすぐに個々の値をそれぞれ格納するよりも大幅にオーバーヘッドを低減できる。この手法の欠点は、直ちにディスクに格納されない情報が、機械の障害が発生した場合に喪失される可能性があることである。障害が発生する可能性に基づいて、ディスクの更新をバッチ化するかどうかを決定すればよい。

システムが利用可能なリソースを十分有するとステップ４０で判断されると、データ削減量を減らしてより多くのデータを収集するよう選ぶことができる（ステップ４２）。これは、永続記憶装置１２に保存される情報の精度を高めることになる。

本発明は、ディスクの更新をバッチ化するかどうかを決定し、もしする場合は、バッチがどのくらいの大きさであるべきかを決定する以下の方法を含む。障害が発生した場合に喪失される情報に対してコストが割り当てられる。例えば、コスト関数は以下のようにしてもよい。
Ｃ１（ｓ）＝ａ＊ｐ＊ｓ
ａは定数、ｐは障害発生の確率、ｓはバッチ全体がディスクに書き込まれるまでに蓄積される情報量（すなわちバッチ・サイズ）である。これは、コストがバッチ・サイズと共に直線的に増える単純なコスト関数である。より複雑な関数も可能である。例えば、コスト関数はバッチ・サイズに加え、喪失される特定の情報など、他の複数のパラメータを含んでもよい。図５のステップ５１は、障害が発生した場合に喪失される情報に関するコスト関数を決定することを表す。Ｃ１はその例である。ステップ５０および５１の順序は入れ替えてもよい。加えて、ステップ５０および５１を同時に行うことも可能である。

コストは、情報を永続記憶装置へ送信するためのオーバーヘッドにも割り当てられる。例えばコスト関数をＣ２（ｓ）＝ｂ＊ｒ／ｓとしてもよく、この場合、ｂは何らかの定数であり、ｒは情報がディスクへ送信される平均速度であり、ｓはバッチ・サイズである。より複雑なコスト関数も可能である。例えば、コスト関数を動的なものとし、システムへの負荷により決定してもよい。Ｉ／Ｏサブシステムに高負荷がかかっている場合、永続記憶装置へ送信される情報が多いほどシステムに負荷をかけすぎる可能性がある。これをコスト関数に反映させると、Ｉ／Ｏシステムに過負荷がかかっている場合は永続記憶装置の更新を延期させることになる。図５のステップ５０は、永続記憶装置への情報送信に関するコスト関数を決定することを表す。Ｃ２は図５のステップ５０の例である。

総コストＣ３はＣ１およびＣ２の合計となる：
Ｃ３（ｓ）＝ａ＊ｐ＊ｓ＋ｂ＊ｒ／ｓ

続いてシステムは、ｓにコスト関数を適用することで生じる値、Ｃ３を最小化するｓの値を決定すればよい。一年目の微積分の標準的な手法を使用してＣ３を最小化できる。同様に、その他の方法（単純な近似など）を使用してＣ３を最小化することも可能である。図５のステップ５２は総コスト関数を最小化するバッチ・サイズを選ぶステップを表す。最終的な結果として、良好なパフォーマンスの必要性と、システム障害が発生した場合に喪失される情報を最小化することの必要性とのバランスがとれる、ディスクへの情報送信用のバッチ・サイズｓをシステムが選ぶ。

障害が発生した場合に喪失される情報に関するコスト関数は、障害発生の確率または障害が発生した場合に喪失される情報あるいはその両方を計算に入れ、これらに伴い増大することも考えられる。多くの場合、障害が発生した場合に喪失される情報は予定のバッチ・サイズに比例する。

ディスクへの情報送信に関するコスト関数は、情報がディスクへ送信される速度に伴い大きくなると思われる。加えて、バッチ・サイズの増大に伴い小さくなると思われる。

リモート・ノードへの情報送信に関するコスト関数は、情報がリモート・ノードへ送信される速度に伴い大きくなると思われる。加えて、バッチ・サイズの増大に伴い小さくなると思われる。

他の実施形態では、情報は、ディスクではなくリモート・ノードへ送信されてもよい。この場合、コスト関数Ｃ２または同様のコスト関数が、リモート・ノードへ更新を送信するコストを表し得る。

他の場合では、バッチ作成のコスト（例えば、ＣＰＵ、ディスク、Ｉ／Ｏにおいてのものなど）がバッチ・サイズによって決まることも考えられる。Ｃ４’（ｓ）を、サイズｓのバッチを作成するコストとする。多くの場合、Ｃ４’（ｓ）は、ディスクにデータを格納することまたはデータをリモート・ノードへ送信すること、あるいはその両方に関連するコストに比べ小さく、その場合これは無視できる。しかし、Ｃ４’（ｓ）が大きい場合には次のコスト方程式：
Ｃ３’（ｓ）＝Ｃ１’（ｓ）＋Ｃ２’（ｓ）＋Ｃ４’（ｓ）がある。Ｃ３’（ｓ）は総コストであり、Ｃ１’（ｓ）は障害が発生した場合に喪失される情報に関するコストであり、Ｃ２’（ｓ）は永続記憶装置またはリモート・ノードあるいはその両方への情報の送信に割り当てられたコストである。

本発明の別の重要な態様は、ディスクへ送信する前に情報を選択的に圧縮することである。情報を圧縮することで、Ｉ／Ｏ帯域幅の消費ならびにディスク・スペースの使用率が低下する。悪い面は、ＣＰＵのオーバーヘッドが大きくなる可能性があるということである。従って、システムは、小さい処理オーバーヘッドの必要性と、ディスク・スペースの使用率と合わせたＩ／Ｏ帯域幅とのバランスをとる必要がある。

圧縮は図４のボックス４１内に描かれている。選択的に圧縮を実行するための好適な方法が図６に描かれている。システムは、少なくとも１つ、しかし通常は複数の圧縮アルゴリズムを利用できる（ステップ６０）。なお、この明細書全体の「圧縮アルゴリズム」という用語は、「圧縮アルゴリズムの実装」と解釈されてもよい。システムは各圧縮アルゴリズムについて、オーバーヘッド、忠実度（言い換えると、圧縮アルゴリズムにより情報が喪失される場合の喪失度）、および結果として見込まれるサイズ縮小量の見積もりを有する。システムは、圧縮に利用できるＣＰＵリソースｒを決定する（ステップ６１）。パフォーマンス・モニタ３１をこの決定に役立てることも可能である。永続記憶装置に書き込むデータ・バッチをシステムが有するときに、許容できる喪失度を示すパラメータＢがデータに関連付けられていればよい。そのようなパラメータが存在しない場合は、喪失のない圧縮アルゴリズムだけが許容される。Ｂを超える喪失をもたらさず、ｒを上回るＣＰＵリソースにつながらない利用可能な圧縮アルゴリズムの中から、最小の圧縮データをもたらす圧縮アルゴリズムが使用される（ステップ６２）。最悪の場合圧縮は実行されない。

忠実度の閾値は、例えば、もとのバイトの９９．５％が保持されるというものであってもよい。

圧縮が行われない場合、またはデータが永続記憶装置へ送信される時点で不十分な量の圧縮が実行される場合、任意選択のステップとしてシステムは、十分なリソースがシステムにできるまで圧縮の実行を待ってからデータを圧縮してもよい。

永続記憶装置に情報を格納するためのオーバーヘッドを低減するという状況で本発明を説明してきた。明らかなことであるが、総括としては、コンピューティング・ノードから別のコンピューティング・ノードへの情報伝達に関わるＩ／Ｏ帯域幅およびオーバーヘッドを低減するよう本発明は使用される。

図７は、本発明が実装され得るコンピューティング・システム７００のハードウェア実装を示すブロック図である。例えば、この用途において複数の情報ロガー、永続記憶装置、複数のアプリケーション・プロセス、複数のパフォーマンス・モニタなどを上記のように実装するために、図７にある具体例としての構造が使用されてもよい。

さらに、当然のことながら、個々の構成要素／ステップは、１つまたは複数の同様のコンピュータ・システム上に実装されてもよい。分散型コンピューティング・システムに実装する場合は、個々のコンピュータ・システムまたはデバイスあるいはその両方が、インターネット、すなわちワールド・ワイド・ウェブなどの適切なネットワークを介して接続されればよい。なお、システムは、プライベート・ネットワークまたはローカル・ネットワークを通して実現されてもよい。本発明は特定のネットワークに限定されない。

図のように、コンピュータ・システム７００は、コンピュータ・バス７１またはそれに代わる接続機構を介してつながれた、少なくとも１つのプロセッサまたはコンピューティング・ノード３０、メモリ７３、複数のＩ／Ｏデバイス７４、ネットワーク・インタフェース７５、および永続記憶装置１２によって実装されてもよい。

当然のことながら、システム７００は、通常図４、５および６の流れ図に対応する命令を実行する１つまたは複数のプロセッサ３０を含むとよい。情報ロガー１０、アプリケーション・プロセス１１またはパフォーマンス・モニタ３１あるいはその全ては、１つまたは複数のプロセッサ３０上で実行されてもよい。

当然のことながら、本願明細書で使用される「プロセッサ」という用語は、例えばＣＰＵ（中央処理装置）またはその他の処理回路あるいはその両方を含むものなど、あらゆる処理デバイスを含むよう意図されている。同様に、当然のことではあるが、「プロセッサ」という用語は２つ以上の処理デバイスを指すこともあり、処理デバイスに関連付けられた種々の構成要素は他の処理デバイスにより共有されてもよい。

本願明細書で使用される「メモリ」という用語は、例えばＲＡＭ、ＲＯＭ、キャッシュなどのような、プロセッサまたはＣＰＵに関連付けられたメモリなどを含むよう意図されている。

永続記憶装置は、ディスク記憶、ハード・ドライブ、リムーバブル・メモリ・デバイス（例えばディスケット）などを含み得るが、これらに限定はされない。

記憶デバイスは、メモリ、永続記憶装置などを含み得るが、これらに限定はされない。記憶デバイスは、セル式電話などの移動デバイスまたはパーベイシブ・デバイス（ｐｅｒｖａｓｉｖｅ ｄｅｖｉｃｅ）上に存在してもよい。

入出力デバイス、すなわちＩ／Ｏデバイスは、例えば、処理装置へのデータ入力用の１つまたは複数の入力デバイス（例えばキーボード、マウスなど）、または、処理装置に関連し、結果を提示する１つまたは複数の出力デバイス（例えばスピーカ、ディスプレイなど）、あるいはその両方を含み得る。

ネットワーク・インタフェースは、例えば、コンピュータ・システムが別のコンピュータ・システムと適切な通信プロトコルを介して通信することを可能にする、１つまたは複数の送受信機を含んでもよい。

したがって、本願明細書中で説明された方法を実行する命令またはコードを含むソフトウェア・コンポーネントは、永続記憶装置に格納されてもよく、利用準備ができると部分的または全体的にメモリへロードされてＣＰＵにより実行されてもよい。

本願明細書中、本発明の具体的な実施形態を添付の図面を参照して説明してきたが、当然のことながら、本発明はこれらの厳密な実施形態に限定されず、本発明の範囲または意図を逸脱せずに当業者によって他の様々な変更および修正が加えられてもよい。

１つまたは複数のアプリケーション・プロセスが単一の情報ロガーと通信する、本発明の機能を有するシステムである。 異なる複数の情報ロガーが別々のアプリケーション・プロセスに関連付けられている、本発明の機能を有する別のシステムである。 本発明に従った、関連するパフォーマンス・モニタを有するプロセッサである。 本発明に従った、パフォーマンス情報およびイベント情報を適応的に収集する方法である。 本発明に従った、バッチ・サイズを決定する方法である。 本発明に従った、情報を圧縮する方法である。 本発明を実装し得るコンピューティング・システムのハードウェア実装を示すブロック図である。

Claims (11)

1. 第１コンピューティング・ノードと、第２コンピューティング・ノードおよび記憶デバイスのうちの少なくとも１つとから成るシステムにおいて、前記第１コンピューティング・ノードから前記記憶デバイスおよび前記第２コンピューティング・ノードのうちの少なくとも１つへ情報を伝達する方法であって、
   利用可能なリソースについての少なくとも１つの見積もりを収集するために、前記第１コンピューティング・ノードを監視するステップと、
   収集されるデータ量を、利用可能なリソースについての前記少なくとも１つの見積もりに基づいて変更するステップと、
   データ集約用のバッチ・サイズを決定するステップと、
   前記バッチ・サイズに応じた量のデータを、前記記憶デバイスおよび前記第２コンピューティング・ノードのうちの少なくとも１つへ送信するステップと
   を含み、
   前記データ集約用のバッチ・サイズを決定するステップは、
   複数の第１コストを、前記記憶デバイスおよびコンピューティング・ノードのうちの１つへデータを送信するための別々のサイズの関数として見積もるステップと、
   複数の第２コストを、前記データの喪失のための別々のサイズの関数として見積もるステップと、
   見積もられた前記第１コストおよび前記第２コストに基づき、前記バッチ・サイズを選択するステップとを含み、
   前記バッチ・サイズは、見積もられた前記コストのうちの少なくとも２つの集約を最小にすることにより決定される、方法。
2. 利用可能なリソースについての前記少なくとも１つの見積もりは、処理能力、Ｉ／Ｏ帯域幅およびネットワーク帯域幅のうちの少なくとも１つの見積もりを含む、請求項１に記載の方法。
3. 収集されるデータ量を変更するステップは、前記データのパーツが収集される頻度を変更することを含む、請求項１または２に記載の方法。
4. 収集されるデータ量を変更するステップは、複数エンティティをより少ない数のエンティティに結合することを含む、請求項１〜３のいずれか１項に記載の方法。
5. 利用可能なリソースについての前記少なくとも１つの見積もりの増加に応答して、収集されるデータ量を増やすステップをさらに含む、請求項１〜４のいずれか１項に記載の方法。
6. 前記エンティティは数値を含み、複数エンティティをより少ない数のエンティティへ前記結合することは、平均および移動平均のうちの少なくとも１つを計算することを含む、請求項４または５に記載の方法。
7. 前記第１コストを見積もることはコスト関数を決定することを含む、請求項１〜６のいずれか１項に記載の方法。
8. 前記第２コストを見積もることはコスト関数を決定することを含む、請求項１〜７のいずれか１項に記載の方法。
9. 前記バッチ・サイズに一致する量のデータを、前記記憶デバイスおよび前記コンピューティング・ノードのうちの少なくとも１つへ送信するステップをさらに含む、請求項１〜８のいずれか１項に記載の方法。
10. 前記集約は合計を含む、請求項１〜９のいずれか１項に記載の方法。
11. 第１コンピューティング・ノードと、第２コンピューティング・ノードおよび記憶デバイスのうちの少なくとも１つとから成るシステムにおいて、前記第１コンピューティング・ノードから前記記憶デバイスおよび前記第２コンピューティング・ノードのうちの少なくとも１つへ情報を伝達するためのプログラムであって、コンピュータに、
    利用可能なリソースについての少なくとも１つの見積もりを収集するために、前記第１コンピューティング・ノードを監視するステップと、
    収集されるデータ量を、利用可能なリソースについての前記少なくとも１つの見積もりに基づいて変更するステップと、
    データ集約用のバッチ・サイズを決定するステップと、
    前記バッチ・サイズに応じた量のデータを、前記記憶デバイスおよび前記第２コンピューティング・ノードのうちの少なくとも１つへ送信するステップと、
    を実行させ、
    前記データ集約用のバッチ・サイズを決定するステップは、
    複数の第１コストを、前記記憶デバイスおよびコンピューティング・ノードのうちの１つへデータを送信するための別々のサイズの関数として見積もるステップと、
    複数の第２コストを、前記データの喪失のための別々のサイズの関数として見積もるステップと、
    見積もられた前記第１コストおよび前記第２コストに基づき、前記バッチ・サイズを選択するステップとを含み、
    前記バッチ・サイズは、見積もられた前記コストのうちの少なくとも２つの集約を最小にすることにより決定される、プログラム。

Images