JP2010146543A

JP2010146543A - メモリ消費監視

Info

Publication number: JP2010146543A
Application number: JP2009120245A
Authority: JP
Inventors: Zedlitz Albert; アルベルト・ゼドリッツ; Jean-Baptiste Doudia; ジャン・バティスト・ドゥディア
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2008-12-16
Filing date: 2009-05-18
Publication date: 2010-07-01
Anticipated expiration: 2029-05-18
Also published as: US8090752B2; EP2199915B1; EP2199915A1; CN101753380B; US20100153475A1; CN101753380A; JP5221445B2

Abstract

【課題】相関分析に基づきメモリ消費監視を実行する。
【解決手段】メモリガーベージコレクションイベント及びノードコンテンツサービスリクエストの発生を監視し、ノードコンテンツサービスリクエストとメモリガーベージコレクションイベントとの間の相関を決定し、かつ、ノードコンテンツサービスリクエストのうちの疑わしいリクエストと関連した情報を報告するように動作する、装置、システム、及び、方法が開示されている。疑わしいリクエストは、相関と関連した予め選択された基準を満足するリクエストとして識別してもよい。追加的な装置、システム、及び、方法が開示されている。
【選択図】図１

Description

本発明は、メモリ消費監視に関する。

Java（登録商標）アプリケーションサーバなどのアプリケーションサーバは、多くの場合、多数のサービスリクエストを処理するようにタスク化される。したがって、数個のリクエストだけのときでさえ、サーバ性能は、劇的に低下し、比較的多量のメモリを消費する結果となり得る。このため、そのようなシステムにおけるメモリ消費監視は、システム全体の安定性の維持に有用である。しかし、システムが高度に利用されるとき、メモリ監視活動自体がシステム性能に影響を与え得る。

Analysis of Performance Problems in SOA: Find the Right Track（オンライン）, URL: http://www.ap-verlag.de/Online-Artikel/SOA/200609%20Opnet%20Performance%20in%20SOA.htm

コンピュータ実行可能な方法であって、
メモリガーベージコレクションイベントと、ノードコンテンツサービスリクエストとの発生を監視するステップと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の相関を決定するステップと、
前記相関と関連した予め選択された基準を満足する前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した情報を報告するステップと
を具備する。

本発明の多様な実施例によるメモリ消費監視のプロセス図である。本発明の多様な実施例によるメモリ消費監視のための装置のブロック図である。本発明の多様な実施例によるメモリ消費監視のためのシステムのブロック図である。本発明の多様な実施例によるメモリ消費監視の方法を図示したフローチャートである。本発明の多様な実施例によるメモリ消費監視の追加的な方法を図示したフローチャートである。本発明の多様な実施例による例示的な形態のコンピュータシステムにおける装置のブロック図である。

「セッション」は、通信エンドポイント間の一連のインタラクションとして特徴付けることができる（特定の接続がアクティブな間に生じる）。セッションを開始するために、クライアントなどの１つのノードは、サーバなどの他のノードとの接続をリクエストしてもよい。ノードが合意した場合、コマンド及びデータを交換することができる。この交換はセッションの一部を構成する。セッションは、接続が両エンドで確立されるときに開始し、かつ、接続が終了されるときに終了する。追加的なセッションを開始するための更なるリクエストは共通である。

システム性能に対して比較的影響の少ない大規模なサービスリクエストを適応するため、本明細書に記載されたメカニズムを使用して、相関分析に基づくメモリ消費監視を実行することができる。例えば、多くの実施例では、ガーベージコレクション（ＧＣ）イベントとサービスリクエスト活動との間の相関の統計的な評価を使用して、疑わしいリクエスト活動（過度のメモリ使用をもたらすように見える）を識別することができる。そのようなリクエストを識別及び規制することによって、システムオペレーションの安定性を向上させることができる。例えば、一部の実施例では、これらのメカニズムを管理インターフェースの一部として使用して、メモリ消費（JAVA（登録商標）アプリケーションサーバにおいて生じる）を監視することができる。

JAVA（登録商標）アプリケーションの使用、及び、JAVA（登録商標）アプリケーションサーバが本明細書において一例として説明されるが、説明される多様な実施例はそのように限定されないことに注意しなければならない。メモリ（データ処理システム内のサービスのためのリクエストを適応するためのリソースとして使用することができ、プログラミング言語と関連して動作する）を備えた、どのようなデバイスでも、本明細書に説明されるような過度のメモリ消費を監視することができる。

本明細書の目的上、「アプリケーション」は、プロセッサによって実行することができる命令の集合を意味する。そのようなアプリケーションは、ブラウザ、ワードプロセッサ、スプレッドシートプロセッサ、プレゼンテーションプロセッサ、データベースプロセッサ、ドローイングプロセッサなどを含む。アプリケーションを使用して、電子コンテンツを処理してもよい。

「電子コンテンツ」は、ユーザに示される（例えば、視覚的又は聴覚的に示される）デジタルデータを含む（電子ドキュメント、ページ記述的電子ドキュメントなどのページ記述的電子コンテンツ、メディアストリーム、ウェブページ、ハイパーテキストドキュメント、画像、デジタルビデオ又はビデオレコーディング、デジタルオーディオ又はオーディオレコーディング、アニメーション、例えば、ハイパーテキスト・マークアップ言語（ＨＴＭＬ）又はＸＭＬを含むドキュメントなどのマークアップ言語ドキュメント、記入されるコンポーネントを備えたフォーム、又は、グラフィカルユーザインターフェース（ＧＵＩ）を記述するデータなど）。電子コンテンツは多様なコンテンツ要素である。

「コンテンツ要素」は、電子コンテンツの部分又は一部（部分又は一部として定義されるか又は認められる）を含む。例えば、コンテンツ要素は、コンテンツ要素自体の特徴（例えば、電子ドキュメントのパラグラフ又はファイルフォーマット指定）を自動的に識別してもよく、又は、ユーザによって手動で定義してもよい（例えば、電子ドキュメント内のユーザが選択したワードの集合、デジタル画像のユーザが選択した部分）。コンテンツ要素の実施例は、ページ記述的ドキュメント又は他の電子ドキュメントの一部を含む（例えば、電子テキスト又は他のマテリアルの部分など、電子ドキュメント内の命令のグループなど、デジタルビデオのセクション、又は、デジタルビデオ又はデジタルオーディオのフレーム又はフレームセットなどのメディアストリームの部分の形態のダイナミックコンテンツ、アニメーションのセグメント又はフレームの形態のダイナミックコンテンツ、電子フォーム、フォームテンプレート、フォーム要素、フォームデータ、動作可能な要素仕様又は実行可能な命令、及び、電子コンテンツ内のユーザによって表示可能又はアクセス可能な多様な要素（スクリプト化及び非スクリプト化されたダイナミックコンテンツのインスタンスなどを含む））。

多数のモジュールを含むいくつかのアプリケーション又はプロセスが本明細書に説明される。「モジュール」は、特徴のある機能のユニット（他のモジュールに情報を提供し、かつ、他のモジュールから情報を受け取ることができる）である。したがって、説明されたモジュールは、通信的に接続されているものとして取り扱ってもよい。また、モジュールは、入力又は出力デバイスとの通信を開始し、かつ、リソースに作用することができる（例えば、情報の収集）。モジュールは、必要に応じて、多様な実施例の特定の実行のため、ハードウェア回路、光学コンポーネント、単一又は複数のプロセッサ回路、メモリ回路、ソフトウェアプログラムモジュール及びオブジェクト、ファームウェア、及び、それらの組み合わせを含んでもよい。用語「モジュール」は、コード、データ、又は、計算オブジェクトの識別可能な部分を含んでもよい（例えば、特定の機能、動作、処理、又は、手順を実行するように設計された、ドキュメントアプリケーション）。

「ノード」は、サーバ、クライアント、又は、サービスリクエストを受信可能な独立計算デバイスである。

「リソース」は、ウェブページ、ディスク上のファイル、又は、コンピュータシステム内部の表示（manifestation）である。リソースの他の実施例は、とりわけ、アドレスブックアイテム、データベースエントリ、及び、カレンダアポイントメントを含んでいる。

本明細書に開示された多様な実施例は、監視されているシステムに対して比較的小さな影響で、メモリ消費監視を可能にするように動作することができる。このタイプの動作を含む一部の代表的な実施例がここでより詳細に説明される。

図１は、本発明の多様な実施例によるメモリ消費を監視するプロセス100を図示している。例えば、サーバ114がアプリケーション104を実行する場合を検討する。サーバ114は、１又は複数のネットワーク124を使用して、インターネット150に接続してもよい。多様なリソース156にアクセスする一部として、多数のユニフォームリソースロケータ（ＵＲＬ）サービスリクエスト120をネットワーク124上に入力してもよい。そのようなリクエストは、多数のクライアント160（例えば、特定のウェブサイトに連続的にアクセスするよう動作する）によるブラウザの使用によって生じてもよい。サービスリクエスト120の一部は、サーバ114内のメモリ140の著しい計算を生じる。

Java（登録商標）仮想マシン（ＪＭＶ）では、変数などのアイテムを格納するために使用されたメモリ140は、ヒープスペースと呼ばれる。ヒープスペースは、世代（generation）と呼ばれるより小さなスペースに分割することができる。ヒープ内には、若い世代スペース（エデン（Eden）スペース、生存（Survivor）０スペース、生存１スペースを含む）を含むいくつかの世代が一般に存在する。

特定の世代（オブジェクトを分類する）は、その年齢に依存する。一般に、メモリ内に配置された新規に生まれたメモリオブジェクトは、第１にエデンスペース内に作成される。エデンスペースが満杯であるとき、まだ生きているメモリアイテムは生存０スペースに移動され、かつ、古いオブジェクト（もはや必要とされていない）はＪＶＭによってエデンスペースからクリアされる。これによって、新規に入ってくるオブジェクトに対して余地を設ける。生存０スペースが満杯であるとき、そのスペース内でまだ生きているオブジェクトは生存１スペースに移動され、かつ、生存０スペースは一掃される。

メモリ140内のスペースは、ＧＣ活動を通じて、ＪＶＭによって部分的に管理される。ガーベージコレクタは、メモリヒープスペース周囲の物を移動させ、かつ、あるアイテムが保存されるか又は廃棄されるかを決定する。ＧＣ活動がなければ、使用可能なメモリ140は比較的速く使い果たされる。したがって、ＵＲＬリクエストなどの多数のサービスリクエスト120の後、ＧＣイベントが起こり、もはや必要ではないメモリ140を解放する。

この開示の目的上、同じサービスリクエストが多かれ少なかれ同じ量のメモリ消費を生じることを仮定することができる。これは、クラスローディング、キャッシュフィリングなどにより割り当てられた追加的なメモリが存在するので、例えば、初回（ＵＲＬがアクセスされる）に関して、真か、又は、真ではなくてもよい。しかし、第１アクセス動作中に消費されたメモリの合計量は廃棄するか、又は、恐らく、特別な手順の一部として考慮してもよい。次のＵＲＬサービスリクエストは、平均的な消費の値をより表さなければならない。

ＪＶＭ及びＧＣルーチンを利用する他のプロセスのため、いったん定義されたメモリ領域（例えば、エデンスペース）が使い果たされると、ＣＧルーチンがトリガされることを仮定することができる。その結果、当該サーバ又は他の機械が、ＧＣイベントを経験することなく、固定された数のサービスリクエストを取り扱うことができることを予期することができる。したがって、あるリクエスト（例えば、特定のＵＲＬにアクセスする）が多くのメモリを使用した場合、ＣＧ間隔の間のリクエストの合計数は一般に減少する。したがって、相関分析を使用して、間隔の分散（このタイプの「疑わしい」リクエストを含む、及び、含まない）を見出すことができる。

図２は、本発明の多様な実施例によるメモリ消費を監視するための装置214のブロック図である。装置214はノードを備え、恐らく、図１のサーバ114に類似しているか又は同一であってもよい。図２に戻ると、装置214は、ハードウェア（いくつかのモジュール内に入力としてデータを供給する）を備えていることが分かる。この場合には、ハードウェアはプロセッサ及びメモリ216を備え、かつ、データはＧＣイベント226、及び、入ってくるサービスリクエスト228（例えば、ＵＲＬアクセスのためのリクエスト）を含んでいる。モジュールは、監視モジュール244、相関モジュール248、及び、分析／報告モジュール252を含んでいる。

ＧＣイベント226及び入ってくるリクエスト228は、プロセッサ及びメモリ216の方では、活動の結果として提供することができる。入ってくるリクエスト228が発生し、かつ、メモリが応答して割り当てられるので、ＧＣイベント226も発生する。リクエスト228及びイベント226が実行されるので、それらのアピアランス（appearance）に関する情報は、非常に小さな性能影響でアーカイブすることができる。

更なる分析のための疑わしいリクエストを識別するため、ＣＧイベント226（サービスリクエストがより少なく発生する）の間の時間間隔に注目が集まる。これは、これらの状態がメモリ消費活動の特徴であるためである。したがって、個別のサービスリクエストは、一部の選択された数の間隔ＩＮＴ（ＣＧイベント226の周期的な発生によって定義された）を評価することができる。

一部の実施例では、メモリ消費の監視は、次のステップよるＧＣイベント226及び入ってくるリクエスト228の処理を含んでもよい。
１．監視モジュール224を使用して、イベント226及びリクエスト228をアーカイブし、かつ、恐らく、所定のタイプ（所定のサービスリクエストタイプ（例えば、ＵＲＬ参照を含んだリクエスト）を含んだ選択された数のＧＣイベント間の間隔ＩＮＴにおいて発生する）のリクエストＸの平均数を計算するステップ
２．監視モジュール224を使用して、所定のリクエストを含まない間隔ＩＮＴにおけるリクエストＹの平均数を計算するステップ
３．相関モジュール244を使用して、r = (X -Y) / max (X, Y)（ここで、max (X, Y)はX又はYのどちらか一方の最大値である）として相関値を計算するステップ。これによって、特定のリクエストタイプ（例えば、特定のＵＲＬを含む）及びＧＣ間隔の発生の相関を与える。

負の相関値（例えば、−１に近似されるｒ値）は、評価されたリクエスト（例えば、所定のリクエスト）が、ＧＣイベント226間のリクエスト数を顕著に削減するように動作し、したがって、他よりもよりメモリを消費するように見えることを示している。したがって、負の相関値ｒを発生するサービスリクエストは、「疑わしいリクエスト（suspicious request）」と考えてもよい。疑わしいリクエストは、分析／報告モジュール252を使用して、ユーザ及び／又は管理者に報告してもよい。

一部の実施例では、疑わしいリクエストのより詳細な分析を実行して（恐らくはオフラインで）、実際のメモリ量（特定にリクエストに関連して割り当てられている）を調査することができる。分析（分析／報告モジュール252を使用して実行してもよい）は、疑わしいリクエストから１又は複数のＵＲＬを抽出するステップと、影響を受けたノードを、それをメンテナンスモードに配置することによって、負荷バランシングサービスから除外するステップと、次いで、ノード性能の詳細な分析のため、プロファイラ（profiler）モードに切り替えるステップとを含んでもよい。このとき、各クラスに対するメモリ消費は集約することができ、かつ、ソースコード（余剰メモリ消費に責任のある）は隔離することができる。

一部の実施例では、相関は、サービスリクエストの選択された組み合わせに対して計算される。例えば、相関は、一部の選択された数のＧＣ間隔ＩＮＴ（一緒に現れた複数のＵＲＬリクエスト：X (URL1, URL2, ...)及び(URL1, URL2,...)を有する）を決定することができる。上記したような同じ計算プロセスを適用することができる（２以上のリクエストのグループが同時に処理される場合を除く）。そのような組み合わせの分析は、リクエストが密結合であるときか、又は、２以上のサービスリクエストがＵＲＬ（ほぼ同じ量のメモリを使用する）に関連付けられるとき、有用であり、かつ、組み合わせは、他のリクエストに関連付けられたメモリ使用よりも、顕著により多くのメモリ使用を生じる。

ＧＣ活動のない装置214のため（例えば、ＧＣイベント226が生成されない）、実質的に一定の長さを有する一連の時間間隔は、ＧＣ間隔と同じ方法で取り扱うことができる。したがって、システムがガーベージコレクタを備えていない場合、同じ計算を実行して、時間の各間隔中にメモリバランスを決定することができる。他の実施例を真に理解することができる。

例えば、上記した相関分析の他に、定量分析も実行することができる（恐らく並行して）。これは、相関分析によって与えられた相関の重要性を推定するのに役立てることができる。

次の実施例（ここで、３つのリクエストタイプＡ（サイズ＝８ユニット），Ｂ（サイズ＝４ユニット）及びＣ（サイズ＝２ユニット）が受信され、かつ、ここで、受信したリクエストの現在の取り合わせによって占有されたメモリサイズが、20ユニット（例えば、ＧＣ（サイズ＝20））であるとき、ガーベージコレクションが開始する。）を検討する。３つのＧＣ間隔にわたって、次の数のリクエストが受信されると仮定する。

次の組を各行（即ち、各ＧＣ間隔）に対して計算することができる。
SIZE_MIN = このリクエストに対する最少サイズを推定する。
SIZE_AVG = 全てのリクエストが同じサイズを有すると仮定した平均値を推定する。
SIZE_MAX = 現在のリクエストを除く全てがサイズゼロであると仮定したサイズを推定する。

各計算中、２つの推定（（ａ）各リクエストは同じ量のメモリを消費し、かつ、（ｂ）各リクエストはメモリを消費しない。）を各リクエストに対して実行することができる。したがって、各ＧＣ間隔に対して、各リクエストを推定することができる３つの可能性のある値が存在する。
（１）分析されたリクエストはゼロメモリを消費する。
（２）間隔内の全てのリクエストは、同じサイズのメモリ消費である。又は、
（３）分析されたリクエストを除く、全てのリクエストはゼロメモリ消費である。

（１）から、第１値を推定することができ、SIZE_MIN = Oである。（２）から、第２値を推定することができ、SIZE_AVG= l/ (全てのリクエスト数)である。（３）から、第３値を推定することができ、SIZE_MAX = l/ (分析されたリクエストの数)である。この計算は、各ＣＧ間隔に対して実行することができる。

各組の計算の後、MIN-MAX計算を使用して、前の組の値は次のように組み合わせられる。
SIZE_MIN = MAX(全てのMINのうちの)
SIZE_AVG = MAX(全てのAVGのうちの) （MAXよりも小さい）
SIZE_MAX = MIN (全てのMAXのうちの)

したがって、この検討に対して、各リクエストのSIZE_MIN = 0及びSIZE_AVGは、次のように組み合わせられる。
MAX (MAX (SIZE_AVG (実際), SIZE_AVG (組み合わせ)), SIZE_MAX (組み合わせ))
次いで、SIZE_MAXは、MIN (SIZE_MAX (実際), SIZE_MAX (組み合わせ))として計算される。このような方法で、第１間隔に対する計算の結果は、第２間隔からの結果となる計算の結果と組み合わせられる。次いで、第３間隔に対する計算の結果は、第１及び第２間隔からの結果の組み合わせの結果と組み合わせられる。

上記の実施例から、第１計算において、次の組が決定される。

第２計算において、タイプＣのリクエストに対して、これらの値は次のように決定される。
MIN = 詳細な情報なしに、Ｃをゼロであると推定することができる。
AVG = 全てのリクエストが同じサイズであると推定する。
MAX = 全てのリクエストが、Ｃを除き、ゼロであると推定する。

次いで、第３計算において、第１及び第２計算の結果が組み合わせられる。

次いで、第４計算において、タイプＣのリクエストに対して、SIZE_AVGは、SIZE_AVG = MIN (MAX (1/6, 1/9), 1/8) = 1/8として計算される。最少リクエストの値が非常に高く推定され、かつ、他の全てが非常に低く推定されるので、SIZE_AVGの値は増加しなければならない。全てのリクエストが同じ量のメモリを消費すると仮定された場合、次いで、より少ないメモリを使用したリクエストは非常に高く推定され、かつ、より多くのメモリを使用したリクエストは非常に低く推定されている。より少ないメモリを使用したリクエストが時間とともにSIZE_MAXによって減少されるが、より多くのメモリを使用したリクエストが、MAX計算を使用したSIZE_AVGによって大きくなることを、計算は許可する。このような方法で、前の仮定は時間とともに改善する。

第５計算において、第４計算の結果は、第３計算の結果と組み合わせられる。

その結果、各リクエストのサイズを推定することができる（より多くのＧＣ間隔を用いて、推定はより正確になる）。

定量分析値結果が既知であるので、相関の定数値を除外し、かつ、重み付き相関を設定するのに有用であるか否かに関する決定を行うことができる。重み付き相関を使用して、最少のＵＲＬリクエストを除外した以降のＧＣ間隔内のメモリ消費が既知であることを考慮することができる。ＵＲＬリクエストの別の発生は、所定のＧＣメモリ間隔に作用し、ファクタとして相関関数内に追加することができる。例えば、タイプＣのリクエストがＣＧメモリのうちの1/10を占有すると仮定すると、計算からタイプＣのリクエストを除外することは、タイプＡ及びＢのリクエストの発生が、オリジナルのメモリスペースのうちの(1-2*0.1 = 0.8)を占有することを意味する。さらに他の実施例が真に理解される。

例えば、図３は、本発明の多様な実施例によるメモリ消費を監視するためのシステム310のブロック図である。システム310内で動作する装置314（例えば、サーバとして動作するノード）の一部の実施例は、メモリＧＣイベント及びノードコンテンツサービスリクエストの発生を検出するための監視モジュール344と、ノードコンテンツサービスリクエストとメモリＧＣイベントとの間の相関を決定するためのプロセッサ実行相関モジュール348とを備えている。装置314は、ノードコンテンツサービスリクエスト（相関（例えば、相関ｒ＜0又はｒ＜-0.5）と関連した予め選択された基準を満足する）のうちの疑わしいリクエストと関連した情報を報告するための報告モジュール352も備えている。監視モジュール344と報告モジュール352とは、単一のモジュール内に一体化するか、又は、２つの別々のモジュール（図示したように）として存在してもよい。

一部の実施例では、装置314は、メモリＧＣイベントと関連したタイミング情報を記録するためのメモリ340を備えている。したがって、多様なメモリＧＣイベントと関連した開始時間、終了時間、又は、両方は、メモリ340内に格納することができる。

また、装置314は、装置314内に一体化されるか、又は、それに遠隔に接続されるか（図示したように、有線又は無線ネットワーク324を使用して）のどちらかのディスプレイ334を備えている。装置314に接続されたデバイス318（例えば、ノード）を使用して、ディスプレイ334を収容してもよい。したがって、ディスプレイ334及びモジュール344,348,352は、クライアント及びサーバなどの別々のデバイス（図示したように）に備えてもよい。また、ディスプレイ334及びモジュール344,348,352は、単一のデバイス（例えば、サーバ又はクライアント）又は独立したデバイス（例えば、ラップトップコンピュータ、ＰＤＡ、又は、セルラー電話）内に一体化してもよい。

ディスプレイ334を使用して、疑わしいノードコンテンツサービスリクエストに関連付けられた情報に関するアラートメッセージ374を表示することができる。このような方法で、高い相関値（例えば、r<-0.5）を使用して、視覚的なアラームを作動させて、システム310内の過度のメモリ使用を、システム管理者に警告することができる。

さらに実施例が真に理解される。これらの一部は多様な方法を含んでいる。

例えば、図４は、本発明の多様な実施例によるメモリ消費を監視するための方法411を図示したフローチャートである。方法411は、機械アクセス可能かつ読取可能な媒体において実行され、かつ、ネットワーク内部及び間のプロセスにわたって動作可能である。ネットワークは、有線、無線、又は、有線及び無線の組み合わせであってもよい。方法411は、命令（機械によってアクセスされるとき、図１から図３に図示された要素及びプロセスに関して表示及び説明された処理を実行する）として実行してもよい。このコンテクストを仮定して、メモリ消費の監視が図４を参照して検討される。

一部の実施例では、メモリ消費の監視のコンピュータ実行方法411は、ブロック421で開始し、かつ、メモリＧＣイベント及びノードコンテンツサービスリクエストの発生の監視を含むブロック425に継続してもよい。相関を決定するため、特定の時間間隔（ＧＣイベント開始時間、ＧＣイベント終了時間、又は、両方によって定義された）の間に、ノードコンテンツサービスリクエストの数が計算されるように、ＧＣイベントのタイミングを記録することは有用である。したがって、ブロック425の監視活動は、メモリＧＣイベントの開始時間又は終了時間のうちの少なくとも１つを記録するステップを含んでもよい。

同様に、それらがメモリＧＣイベントの発生に関係しているので、ノードコンテンツサービスリクエストのタイミングを記録することが可能である。したがって、ノードコンテンツサービスリクエストのタイミングを記録することができ、かつ、間隔（ノードコンテンツサービスリクエストタイミングによって定義された）中に発生するガーベージコレクションの数を記録することができる。したがって、ブロック425の監視活動は、ノードコンテンツサービスリクエストの開始時間又は終了時間のうちの少なくとも１つを記録するステップを含んでもよい。

そのようなアプローチは、プロセッサ活動がメモリ消費と関連する環境には有用である。しかし、各場合において、経過時間をプロセッサ使用時間から区別しなければならない（例えば、アイドルスレッドはメモリを消費しない）。

ノードコンテンツサービスリクエストの存在及び／又はタイミングは、キューで記録することができる（相関分析が所望されるとき、関係する情報を周期的な抽出に利用可能にさせる）。したがって、ブロック425の監視活動は、ノードコンテンツサービスリクエストをキューで記録するステップを含んでもよい。

ノードコンテンツサービスリクエスト内に含まれた特定の種類の情報として、ＵＲＬ情報も記録することができる。したがって、ブロック425の監視活動は、ノードコンテンツサービスリクエストの一部として、ＵＲＬ情報を記録するステップを含んでもよい。

方法411は、ノードコンテンツサービスリクエストとメモリＧＣイベントとの間の相関を決定するステップを含むブロック429に続いてもよい。上記したように、相関は、時間間隔（メモリＣＧイベントによって定義された）中のノードコンテンツサービスリクエストの数の間で決定してもよい。

一部の実施例では、例えば、ＵＲＬがサービスリクエストの一部を構成するとき、相関は、ノードコンテンツサービスリクエストの平均数（選択されたＵＲＬを含む）、及び、ノードコンテンツサービスリクエストの平均数（選択されたＵＲＬを含まない）を使用して決定される。したがって、ブロック429の活動は、時間間隔（メモリＧＣイベントによって定義された）中のノードコンテンツサービスリクエストの包含的な平均数（選択されたＵＲＬを含む）と、ノードコンテンツサービスリクエストの排他的な平均数（選択されたＵＲＬを含まない）との間の相関を決定するステップを含んでもよい。

一部の実施例では、上記したように、平均は、相関を決定するための特定の方法で組み合わせてもよい。したがって、ブロック429の活動は、包含的な平均又は排他的な平均の最大値によって除算された、包含的な平均と排他的な平均との間の差異として、相関を計算するステップを含んでもよい。

一部の実施例では、ＧＣコレクション間隔は、第１ＧＣイベントの開始時間（第２ＧＣイベントの開始時間まで）か、又は、第１ＧＣイベントの終了時間（第２ＧＣイベントの終了時間まで）の間の間隔として定義することができる。したがって、時間間隔（ブロック429の相関を決定するのに使用された）は、ＧＣイベントの開始時間及びＧＣイベントの終了時間のうちの１つによって定義してもよい。

２以上の密結合されたサービスリクエストが過度のメモリ使用を発生させているか否かを決定するため、ブロック429の活動は、時間間隔（メモリＧＣイベントによって定義された）中のノードコンテンツサービスリクエストの一部の数の間の相関を決定するステップを含んでもよい（例えば、ノードコンテンツサービスリクエストの数は、複数の共通ＵＲＬ値に基づいている）。

方法411は、予め選択された基準（ノードコンテンツサービスリクエストとメモリＧＣイベントとの間の相関が、ノードコンテンツサービスリクエストのうちの疑わしいリクエストの追加的な分析をトリガするのに十分であることを示す）と関連した閾値を超えていることを検出するステップを含むブロック433に続いてもよい。例えば、相関が所定の閾値（例えば、r<-0.5）をクロスするとき、疑わしいノードコンテンツサービスリクエストの追加的な分析を開始することができる。

したがって、ブロック433で疑わしいリクエストが見つからない場合、次いで、方法411は、ブロック425に戻り、ＣＧイベント及び入ってくるノードコンテンツサービスリクエストの監視を継続してもよい。そうでなければ、相関決定と関連した予め選択された基準の満足により、疑わしいリクエストであるとリクエストが識別された場合、方法411は、疑わしいノードコンテンツサービスリクエストと関連した情報（例えば、１又は複数のＵＲＬ）を報告するステップを含むブロック437に続いてもよい。ブロック437の報告するステップの活動は、ＧＵIの一部として、相関又は情報（ノードコンテンツサービスリクエストのうちの疑わしいリクエストと関連した）のうちの少なくとも１つを表示するステップをさらに含んでもよい。

このような方法で、ＧＣイベント及び入ってくるリクエストを監視することによって、あるサーバコンテンツサービスリクエストに関係した疑わしいメモリ消費活動を、システム性能に対して比較的小さな影響で、認識及び報告することができる。さらなる実施例が真に理解される。

例えば、図５は、本発明の多様な実施例によるメモリ消費を監視するための方法511を図示したフローチャートである。方法511は、機械アクセス可能かつ読取可能な媒体において実行され、かつ、ネットワーク内部及び間のプロセスにわたって動作可能である。ネットワークは、有線、無線、又は、有線及び無線の組み合わせであってもよい。方法511は、命令（機械によってアクセスされるとき、図１から図４に図示された要素及びプロセスに関して表示及び説明された処理を実行する）として実行してもよい。このコンテクストを仮定して、メモリ消費の監視が図５を参照して検討される。

一部の実施例では、メモリ消費を監視するコンピュータ実行方法511は、ブロック521で開始し、かつ、メモリＧＣイベントとノードコンテンツサービスリクエスト（ＵＲＬ情報を含む）との間のタイミング関係を監視するステップを含むブロック525に続く。

方法511は、ノードコンテンツサービスリクエストとメモリＧＣイベントとの間の相関を決定するステップを含むブロック529に続いてもよい。例えば、相関は、時間間隔（ＧＣイベントによって定義された）中のノードコンテンツサービスリクエストの平均を使用して決定することができる。したがって、ブロック529の活動は、選択された数の間隔（メモリＧＣイベントによって定義された）中のノードコンテンツサービスリクエストの包含的な平均数と、選択された数の間隔（メモリＧＣイベントによって定義された）中のノードコンテンツサービスリクエストの排他的な平均数との間の相関を決定するステップを含んでもよい。

上記したように、リクエストの組み合わせからのＵＲＬを相関分析に使用して、選択されたＵＲＬが共に動作して、大量のメモリを消費するか否かを決定することができる。したがって、ブロック529の活動は、複数のノードコンテンツサービスリクエストと関連したＵＲＬ情報を組み合わせて、複数のノードコンテンツサービスリクエストのうちの個別のリクエスト間の相関を決定するステップを含んでもよい。

方法511は、ブロック533に続き、疑わしいリクエストが識別されたか否かを決定してもよい。そのようなリクエストが見つけられなかった場合、次いで、方法511は、ブロック525に戻り、ＧＣイベント及びノードアクセスリクエストの監視を継続してもよい。そうでなければ、リクエストが相関と関連した予め選択された基準を満足すると識別された場合、疑わしいリクエストとして特徴付けるため、次いで、方法511は、疑わしいノードコンテンツサービスリクエストと関連した情報を報告するステップを含むブロック537に続いてもよい。したがって、一部の実施例では、方法511は、リクエスト（ＵＲＬを含むか、又は、含まない）の発生よりもむしろ、ＧＣタイミング関係（特にＵＲＬの使用を含む）を監視するように動作してもよい。

疑わしいリクエストと関連した情報は、ディスプレイ表面（例えば、フラットパネルディスプレイ）上に、インターネットブラウザ又はバナーを使用して表示することができる。したがって、ブロック537の報告する活動は、ＧＵＩ（例えば、図３のアラートメッセージ374を参照）の一部として、ウェブページウィンドウ又はサイドバーウィンドウ又は両方を表示するステップを含んでもよい。

方法511は、ノードコンテンツサービスリクエストがノードによってもはや処理されないように、ネットワークノードを命令して、維持モードに入るステップを含むブロック541に続いてもよい。このような方法で、疑わしいリクエストを受信するノードは、維持モードを使用したさらなる分析のために、ネットワークを外すことができる。ブロック541の活動の一部として、方法511は、ノードを命令して、プロファイラモードに入るステップを含んでもよい。

選択された回数で、ＧＣイベントを停止して、ノードコンテンツサービスリクエストに応答して、ふるまいをより詳細に分析してもよい。例えば、ＪＶＭの実施例では、Java（登録商標）の方法「System.gc」を無効化することができる（Java（登録商標）仮想マシン(ＪＶＭ)ツールインターフェース(ＴＩ)（Jvmti->ForceGarbageCollection）を使用して、ＧＣをまだトリガすることができるが）。したがって、方法511は、ブロック545で、メモリＧＣイベントを選択的に無効化するステップを含んでもよい。

一部の実施例では、疑わしいリクエストの結果として使用されたメモリは、プロファイラモードにおいて決定することができ、かつ、ＧＣイベントによって格納されたメモリも、このモードにおいて決定することができる。したがって、方法511は、ブロック549に進み、１又は複数の疑わしいノードコンテンツサービスリクエストに、ノード内で、割り当てられた第１メモリ量を決定するステップと、メモリＧＣイベントによって割り当てを解除された（deallocated）第２メモリ量を決定するステップとを含んでもよい。

割り当てられたメモリが格納されたメモリよりも一貫して大きい場合、次いで、メモリリーク、又は、時間とともに一貫したメモリの損失（調査中である疑わしいノードコンテンツサービスリクエストによる）が存在する可能性がある。したがって、方法511は、ブロック553で、第１メモリ量と第２メモリ量とを比較して、メモリリークが存在する否かを決定するステップを含んでもよい。次いで、方法511は、ブロック557で終了してもよい。

図５に示された各方法の要素は、図４に示された方法の要素のいずれかに追加するか、又は、置き換えてもよいことが当業者には真に理解される。加えて、図４から図５の各方法の要素は、多様な方法で組み合わせて、直列、並列、ループ、及び／又は、繰り返し方法で、各図からの要素を使用する多様な方法を構成してもよいことも当業者には真に理解される。

図６は、本発明の多様な実施例によるコンピュータシステム600の代表的な形態における機械602のブロック図である。コンピュータシステム600は、本明細書において検討された１又は複数の活動（図４から５に図示された活動を含む）を、システム600に実行させるための１組の命令612を含んでもよい。システム600は、図３のシステム310に類似している又は同一であるか、又は、その要素のうちのいずれか（例えば、装置314又はデバイス318）であってもよい。

図６では、機械602のコンポーネントは、メインメモリ620、静的又は不揮発性メモリ624、大容量記憶装置606を含んでもよいことが分かる。プロセッサ604に接続された他のコンポーネントは、出力デバイス628（ビデオディスプレイなど）、入力デバイス632（キーボードなど）、カーソル制御デバイス636（マウスなど）を含んでもよい。また、ネットワークインターフェースデバイス640（ネットワーク644に、プロセッサ604及び他のコンポーネントを接続する）は、バス616に接続してもよい。

プロセッサ604、メモリ620,624、及び、記憶装置606は、命令612（実行されるとき、機械602に、本明細書に記載された１又は複数の方法を実行させる）をそれぞれ含んでもよい。命令612は、多数の周知の転送プロトコル（例えば、ハイパーテキスト転送プロトコル）のうちのいずれか１つを利用して、ネットワークインターフェースデバイス640を介して、ネットワーク644上にさらに転送するか、又は、受信してもよい。バス616に接続されたこれらの要素のうちのいずれかは、実現される固有の実施例によって、不在、単一で存在、又は、複数の数で存在してもよい。

一部の実施例では、機械602は、スタンドアローンデバイスとして動作するか、又は、他の機械に接続してもよい（例えば、ネットワーク化）。ネットワーク化された環境では、機械602は、ノード（例えば、サーバ−クライアントネットワーク環境におけるサーバ又はクライアントデバイス、又は、ピアツーピア（又は分散した）環境におけるピアマシン）の機能で動作してもよい。機械602は、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、セットトップボックス（ＳＴＢ）、ＰＤＡ、セルラー電話、ウェブアプライアンス、ネットワークルータ、スイッチ又はブリッジ、その機械によって行われるアクションを指定する１組の命令（シーケンシャルか又はそうではないもの）を実行可能な機械を含んでもよい。さらに、単一の機械602だけが図示されているが、用語「機械」は、個別に、又は、共同で１組（又は複数の組）の命令を実行して、本明細書で検討された１又は複数の方法を実行する機械の集合を含んで利用しなければならない。

機械可読媒体608は、単一の媒体として示されるが、用語「機械可読媒体」は、１又は複数の命令612を格納する単一媒体又は複数の媒体（例えば、集中又は分散データベース、及び／又は、関係するキャッシュ及びサーバ、プロセッサ604レジスタ、メモリ620,624及び記憶装置606などの多様な記憶媒体）を含んで利用しなければならない。用語「機械可読媒体」は、機械によって実行するための１組の命令を格納、コード化又はキャリーが可能であり、かつ、機械602に、本発明の１又は複数の方法のうちのいずれかを実行させ、又は、そのような１組の命令によって利用されたか、又は、関連付けられたデータ構造を格納、コード化又はキャリーが可能である媒体を含むように利用しなければならない。したがって、用語「機械可読媒体」又は「コンピュータ可読媒体」は、固体記憶装置及び光学及び磁気媒体などの有形の媒体を含んで利用しなければならない。

最後に、上記したように、メモリ消費が相関分析を使用して監視されるとき、システム性能に及ぶ影響は比較的小さいことが分かる。したがって、多くのインスタンスでは、分析結果が迅速（恐らくは、メモリ消費状態（そうでなければ、システム動作の崩壊となる恐れのある）を修復するのに間に合う）に利用可能であるので、全システム性能は、これらの解決策（メモリ動作とより直接的に相互作用する）によって、向上させることができる。

本発明の実施例は、多様なアーキテクチャのプラットフォーム、オペレーティング及びサーバシステム、デバイス、システム、又は、アプリケーションにおいて、実行することができる。本明細書に示された特定のアーキテクチャのレイアウト又は実装は、説明及び理解のためだけに、このように提供され、かつ、多様な実施例を限定することを意図していない。

要約は、37C.F.R1.72(b)に従うように提供され、かつ、読者が、技術的な開示の性質を迅速に確認することを可能にする。それは、特許請求の範囲の範囲又は意味を、解釈又は限定することに使用されないという理解の下に提出されている。

この発明の詳細な説明では、多数の特徴が、説明を合理化する目的で、単一の実施例に一緒にグループ化されている。説明のこの方法は、包含（請求された実施例が各請求項に明白に列挙されたよりも多くの特徴を有する）として解釈されてはならない。むしろ、特許請求の範囲が反映するので、発明の主題は、単一の開示された実施例の全ての特徴には決してない。したがって、特許請求の範囲は、別々の実施例としてそれら自体に基づく各請求項を備えて、これによって、発明の詳細な説明に組み込まれている。

100 プロセス
104 アプリケーション
114 サーバ
120 サービスリクエスト
124 ネットワーク
140 メモリ
142 プロセッサ
150 インターネット
156 リソース
160 クライアント
214 装置
216 プロセッサ及びメモリ
226 ＧＣイベント
228 入ってくるサービスリクエスト
244 監視モジュール
248 相関モジュール
252 分析／報告モジュール
310 システム
314 装置
318 デバイス
340 メモリ
342 プロセッサ
344 監視モジュール
348 相関モジュール
352 報告モジュール
334 ディスプレイ
374 アラートメッセージ

Claims

コンピュータ実行可能な方法であって、
メモリガーベージコレクションイベントと、ノードコンテンツサービスリクエストとの発生を監視するステップと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の相関を決定するステップと、
前記相関と関連した予め選択された基準を満足する前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した情報を報告するステップと
を具備する方法。
前記監視するステップは、前記メモリガーベージコレクションイベントの開始時間又は終了時間のうちの少なくとも１つを記録するステップを含むことを特徴とする請求項１に記載の方法。
前記監視するステップは、前記ノードコンテンツサービスリクエストの開始時間又は終了時間のうちの少なくとも１つを記録するステップを含むことを特徴とする請求項１に記載の方法。
前記監視するステップは、前記ノードコンテンツサービスリクエストをキューで記録するステップを含むことを特徴とする請求項１に記載の方法。
前記監視するステップは、前記ノードコンテンツサービスリクエストの一部として、ユニフォームリソースロケータ（ＵＲＬ）情報を記録するステップを含むことを特徴とする請求項１に記載の方法。
前記決定するステップは、前記メモリガーベージコレクションイベントによって定義された時間間隔中の前記ノードコンテンツサービスリクエストの数の間の相関を決定するステップを含むことを特徴とする請求項１に記載の方法。
前記決定するステップは、前記メモリガーベージコレクションイベントによって定義された時間間隔中の選択されたユニフォームリソースロケータを含む前記ノードコンテンツサービスリクエストの包含的な平均数と、前記選択されたユニフォームリソースロケータを含まない前記ノードコンテンツサービスリクエストの排他的な平均数との間の相関を決定するステップを含むことを特徴とする請求項１に記載の方法。
前記包含的な平均と前記排他的な平均との差異として、前記相関を計算し、前記包含的な平均と前記排他的な平均との最大値によって除算するステップをさらに含むことを特徴とする請求項７に記載の方法。
前記時間間隔は、ガーベージコレクションイベントの開始時間、及び、ガーベージコレクションイベントの終了時間のうちの１つによって定義されることを特徴とする請求項７に記載の方法。
前記決定するステップは、前記メモリガーベージコレクションイベントによって定義された時間間隔中の前記ノードコンテンツサービスリクエストの数の間の前記相関を決定するステップを含み、
ノードコンテンツサービスリクエストの数は、複数の共通ユニフォームリソースロケータ値に基づくことを特徴とする請求項１に記載の方法。
前記サービスリクエストの定量分析を実行して、前記相関のため、少なくとも１つの重み付き係数を提供するステップをさらに含むことを特徴とする請求項１に記載の方法。
コンピュータ実行可能な方法であって、
メモリガーベージコレクションイベントと、ユニフォームリソースロケータを含むノードコンテンツサービスリクエストとの間のタイミング関係を監視するステップと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の相関を決定するステップと、
前記相関と関連した予め選択された基準を満足する前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した情報を報告するステップと
を含むことを特徴とする方法。
前記決定するステップは、選択された数の前記メモリガーベージコレクションイベントによって定義された間隔中の前記ノードコンテンツサービスリクエストの包含的な平均数と、前記選択された数の前記メモリガーベージコレクションイベントによって定義された間隔中の前記ノードコンテンツサービスリクエストの排他的な平均数との間の前記相関を決定するステップを含むことを特徴とする請求項１２に記載の方法。
前記報告するステップは、グラフィックユーザインターフェースの一部として、ウェブページウィンドウ、又は、スライドバーウィンドウのうちの少なくとも１つを表示するステップを含むことを特徴とする請求項１２に記載の方法。
前記ノードコンテンツサービスリクエストが前記ノードによってもはや処理されないように、ネットワーク内のノードを命令して、維持モードに入るステップをさらに含むことを特徴とする請求項１２に記載の方法。
前記ノードを命令して、プロファイラモードに入るステップと、
前記ノードコンテンツサービスリクエストのうちの前記疑わしいもののうちの少なくとも１つに対して、前記ノード内に割り当てられた第１メモリ量を決定するステップと
をさらに含むことを特徴とする請求項１５に記載の方法。
前記メモリガーベージコレクションイベントのうちの１つによって割り当てを解除された第２メモリ量を決定するステップをさらに含むことを特徴とする請求項１６に記載の方法。
前記第１メモリ量と、前記第２メモリ量とを比較して、メモリリークが存在するか否かを決定するステップをさらに含むことを特徴とする請求項１７に記載の方法。
前記メモリガーベージコレクションイベントを選択的に無効にするステップをさらに含むことを特徴とする請求項１２に記載の方法。
複数のノードコンテンツサービスリクエストと関連した前記ユニフォームリソースロケータ情報を組み合わせて、前記複数のノードコンテンツサービスリクエストのうちの個別のものの間の前記相関を決定するステップをさらに含むことを特徴とする請求項１２に記載の方法。
コンピュータに方法を実行させるために格納された命令を含むコンピュータ可読媒体であって、前記方法は、
メモリガーベージコレクションイベントと、ノードコンテンツサービスリクエストとの発生を監視するステップと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の相関を決定するステップと、
前記相関と関連した予め選択された基準を満足する前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した情報を報告するステップと
を具備することを特徴とするコンピュータ可読媒体。
前記方法は、
前記相関が前記予め選択された基準と関連した閾値を超過したことを検出するステップと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の前記相関が、前記ノードコンテンツサービスリクエストのうちの前記疑わしいものの追加的な分析をトリガするのに十分であることを示すステップと
を含むこと特徴とする請求項２１に記載のコンピュータ可読媒体。
前記報告するステップは、グラフィカルユーザインターフェースの一部として、前記ノードコンテンツサービスリクエストのうちの前記疑わしいものと関連した、前記相関又は前記情報のうちの少なくとも１つを表示するステップを含むこと特徴とする請求項２１に記載のコンピュータ可読媒体。
装置であって、
メモリガーベージコレクションイベントと、ノードコンテンツサービスリクエストとの発生を検出するための監視モジュールと、
前記ノードコンテンツサービスリクエストと、前記メモリガーベージコレクションイベントとの間の相関を決定するためのプロセッサ実行可能な相関モジュールと、
前記相関と関連した予め選択された基準を満足する前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した情報を報告するための報告モジュールと
を含むことを特徴とする装置。
前記メモリガーベージコレクションイベントと関連したタイミング情報を記録するためのメモリをさらに含むことを特徴とする請求項２４に記載の装置。
前記ノードコンテンツサービスリクエストのうちの疑わしいものと関連した前記情報に関して、アラートメッセージセージを表示するためのディスプレイをさらに含むことを特徴とする請求項２４に記載の装置。