JP2019522836A

JP2019522836A - ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関

Info

Publication number: JP2019522836A
Application number: JP2018558661A
Authority: JP
Inventors: チャン，エリック・エス
Original assignee: オラクル・インターナショナル・コーポレイション
Priority date: 2016-05-09
Filing date: 2017-05-08
Publication date: 2019-08-15
Anticipated expiration: 2037-05-08
Also published as: US20170322861A1; US20220214918A1; CN109313600A; US11640320B2; US11614969B2; EP3455735A1; US20180074854A1; US20170337085A1; CN109313599A; JP2022003566A; US20220019467A1; CN109313601B; US11144352B2; US10417111B2; US20210334139A1; JP6952058B2; JP6913695B2; EP3455732B1; JP2023052064A; CN109313601A

Abstract

実施形態は、メモリ効率を最適化するために、ヒープをため込んでいるスタックトレースを特定する。いくつかの実施形態は、プロセスによるヒープ使用量が閾値を上回っている時間の長さを判断できる。次に、いくつかの実施形態は、この時間の長さの間のプロセスのヒープ情報を決定してもよい。ヒープ情報は、この時間の長さにおける各間隔のヒープ使用量情報を含む。次に、いくつかの実施形態は、この時間の長さの間の１つ以上のプロセスのスレッド情報を決定できる。スレッド情報を決定することは、スレッドのクラスを決定することを含み、スレッド情報は、スレッドのクラスの各々について、間隔の各々のスレッド強度情報を含む。次に、いくつかの実施形態は、ヒープ情報をスレッド情報に相関させて、閾値を上回るヒープ使用量に対応するコードを特定してもよい。次に、いくつかの実施形態は、このコードに関連するアクションを開始してもよい。

Description

関連出願の相互参照
本願は、２０１７年５月５日に出願され、「Correlation of Thread Intensity and Heap Usage to Identify Heap-Hoarding Stack Traces（ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関）」と題された米国通常出願第１５／５８８，５３１号、２０１６年５月９日に出願され、「Correlation of Thread Intensity and Heap Usage to Identify Heap-Hoarding Stack Traces（ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関）」と題された米国仮出願第６２／３３３，７８６号、２０１６年５月９日に出願され、「Memory Usage Determination Techniques（メモリ使用量判断技術）」と題された米国仮出願第６２／３３３，７９８号、２０１６年５月９日に出願され、「Compression Techniques for Encoding Stack Traces Information（スタックトレース情報を符号化するための圧縮技術）」と題された米国仮出願第６２／３３３，８０４号、２０１６年５月９日に出願され、「Correlation of Stack Segment Intensity in Emergent Relationships（出現した関係におけるスタックセグメント強度の相関）」と題された米国仮出願第６２／３３３，８１１号、２０１６年５月９日に出願され、「Systems and Methods of Stack Trace Analysis（スタックトレース分析のシステムおよび方法）」と題された米国仮出願第６２／３３３，８０９号、２０１６年５月２３日に出願され、「Characterization of Segments of Time-Series（時系列のセグメントの特徴づけ）」と題された米国仮出願第６２／３４０，２５６号、２０１７年５月５日に出願され、「Memory Usage Determination Techniques（メモリ使用量判断技術）」と題された米国通常出願第１５／５８８，５２６号、２０１７年５月５日に出願され、「Compression Techniques for Encoding Stack Trace Information（スタックトレース情報を符号化するための圧縮技術）」と題された米国通常出願第１５／５８８，５２３、および、２０１７年５月５日に出願され、「Correlation of Stack Segment Intensity in Emergent Relationships（出現した関係におけるスタックセグメント強度の相関）」と題された米国通常出願第１５／５８８，５２１の国際出願であり、米国特許法第１１９条（ｅ）の下で、これらの出願に基づく優先権の利益を主張するものであり、これらの出願のすべてを、あらゆる目的のために引用により本明細書に援用する。

（１）２０１７年５月８日に出願され、「MEMORY USAGE DETERMINATION TECHNIQUES（メモリ使用量判断技術）」と題されたＰＣＴ通常特許出願ＰＣＴ／ＵＳ２０１７／０３１５８９号（代理人整理番号：０８８３２５−１０４７５７６（１７５２１０ＰＣ））。

（２）２０１７年５月８日に出願され、「COMPRESSION TECHNIQUES FOR ENCODING STACK TRACE INFORMATION（スタックトレース情報を符号化するための圧縮技術）」と題されたＰＣＴ通常特許出願ＰＣＴ／ＵＳ２０１７／０３１５９３号（代理人整理番号：０８８３２５−１０４７５７８（１７５２２０ＰＣ））。

（３）２０１７年５月８日に出願され、「CORRELATION OF STACK SEGMENT INTENSITY IN EMERGENT RELATIONSHIPS（出現した関係におけるスタックセグメント強度の相関）」と題されたＰＣＴ通常特許出願ＰＣＴ／ＵＳ２０１７／０３１５９４号（代理人整理番号：０８８３２５−１０４７５８２（１７５２３０ＰＣ））。

背景
一般に、クラウドサービスプロバイダは、顧客とのサービスレベル契約（ＳＬＡ：ＳｅｒｖｉｃｅＬｅｖｅｌＡｇｒｅｅｍｅｎｔｓ）を満たすために運用資源を維持する。プロバイダは、クラウドサービスがＳＬＡに適合していることを確実にするために、自身が提供するサービスのパフォーマンス評価指標を常時監視する。しかしながら、利用可能なツールが、差し迫ったＳＬＡ違反を予測または検出する機能を有していない場合があるので、この運用資源では、当該違反を避けることができないだろう。これに加えて、ツールは、ＳＬＡ違反の根本的原因を診断する機能を有していない場合があるので、運用には、このような違反が生じたときにそれを解決するためにより多くの時間がかかってしまうだろう。その結果、カスタマーエクスペリエンスに悪影響を与えてしまう可能性がある。

さらに、このようなＳＬＡは、ＳＬＡ違反を回避し、かつ、契約内容を満たしているかどうかを判断するために、データを体系的に解析して、当該データに含まれる実行可能な情報に従って先回りして行動することを要求し得る。サービスレベル契約およびその他の要件に従うことは、非常に煩わしく、時間が経つにつれてさらに煩わしくなるだろう。

上述の機能を得るためには、システムの下位レベルのイベントおよびシステム測定に基づいて簡単に更新できる上位レベルの状態モデルを使用して当該システムを表す手法が必要である。下位レベルのイベントの評価指標を取得することに関して、当該システムの基礎となるアプリケーションプログラムを計測してイベントの正確な測定値を収集することができる。しかしながら、このような手法では、計測自体が測定値に影響を与え得る。この問題は、メソッドの前後の計測コードの実行時間がメソッド自体の実行時間の大半を占める場合（たとえば、メソッド呼び出し回数が多い場合）には、より顕著であり得る。

概要
メモリ効率を最適化するためにヒープをため込んでいるスタックトレースを特定するための特定の手法を開示する。いくつかの実施形態は、ソフトウェア実行環境内で高いヒープ使用量に対応するコードを特定するために、ヒープ情報をスレッド情報と相関させてもよい。

一実施形態は、方法を対象とする。この方法は、１つ以上のコンピュータシステムによって、１つ以上のプロセスによるヒープ使用量が閾値を上回っている時間の長さを判断するステップと、時間の長さの間の１つ以上のプロセスのヒープ情報を決定するステップと含み、ヒープ情報は、時間の長さにおける複数の間隔の各々のヒープ使用量情報を含み、方法は、さらに、時間の長さの間の１つ以上のプロセスのスレッド情報を決定するステップを含み、スレッド情報を決定するステップは、１つ以上のスレッドのクラスを決定するステップを含み、スレッド情報は、１つ以上のスレッドのクラスの各々について、複数の間隔の各々のスレッド強度情報を含み、方法は、さらに、ヒープ情報をスレッド情報に相関させて、閾値を上回るヒープ使用量に対応する１つ以上のプロセスの１行以上のコードを特定するステップと、１行以上のコードを特定することに応答して、１行以上のコードに関連する１つ以上のアクションを開始するステップとを含み得る。

例示的な実施形態を、下記の図面を参照しながら以下に詳細に説明する。

一定期間にわたって１つのスレッドのランタイムを比較的高い周波数の標本抽出レートでプロファイリングする例を示す図である。例示的な呼び出しコンテキストのツリーを示す図である。いくつかの実施形態に係る、一定期間にわたる仮想マシンのスレッドダンプの例を示す図である。いくつかの実施形態に係る、スレッド分類シグネチャの例を示す図である。いくつかの実施形態に係る、スレッド分類シグネチャの例を示す図である。いくつかの実施形態に係る、スレッド分類シグネチャの例を示す図である。いくつかの実施形態に係る、スレッドダンプに応答した１つ以上のスレッド分類シグネチャの生成および／または変更を表す簡略フローチャートである。分岐点を検出することに応答したスレッド分類シグネチャの生成または変更を表す簡略フローチャートである。いくつかの実施形態に係る、高いヒープ使用量に対応するコードの特定を表す簡略フローチャートである。いくつかの実施形態に係る、様々なスレッドのクラスと高いヒープ使用量との相関度合いの算出を表す簡略フローチャートである。標本の測定値に割り当てられた重みが当該標本の測定値に関連する標本抽出時間間隔に対して、例示的なデータセットの時間領域にわたってプロットされた、例示的なグラフである。本番環境におけるヒープ使用量を求めるためのそれぞれ異なる線形回帰法によって導出されたトレンドグラフを示す例示的なチャートである。標準的なロバスト回帰法によって得られた誤った結果を示す別のトレンドグラフを示す例示的なチャートである。いくつかの実施形態に係る、信号の予測の生成を表す簡略フローチャートである。特定の実施形態を実現するための分散システムの略図である。いくつかの実施形態に係る、クラウドサービスとしてサービスが提供され得るシステム環境の１つ以上のコンポーネントの簡略ブロック図である。特定の実施形態を実現するために使用され得る例示的なコンピュータシステムを示す図である。

特許または出願ファイルは、色つきで製作された少なくとも１つの図面を含む。カラー図面を有する当該特許または特許出願公開の原稿は、請求および必要な料金の支払いが行われると、庁によって提供される。

詳細な説明
Ｉ．概要
下記の記載において、本開示の実施形態の十分な理解を与えるために、説明の便宜上、具体的な詳細を記載する。しかしながら、これらの具体的な詳細なしに様々な実施形態を実施してもよいことは明らかである。図面および説明は、限定を意図したものではない。

本開示は、全体として、最適化の可能性のためにマルチスレッドプロセス（たとえば、アプリケーションプログラム）内のコードブロックを特定し、かつ、将来のヒープ使用量および／またはスレッド強度を予測するために、ヒープ使用量統計データおよびスレッド強度統計データを利用することに関する。スレッド強度統計データは、プロセスの基礎となるコードを計測せずに、またはコード注入を使用せずに、プロセスの応答、負荷、およびリソース使用を追跡するために利用してもよい。具体的には、スレッドの型またはスタックセグメントの型の強度は、スレッドが実行中のまたはスタックセグメントが参照中のコードブロックの「ホット性（hotness）」の統計的測定値を指してもよい。コードブロックのホット性は、実行量（たとえば、コードブロックの呼び出し回数×コードブロックの実行時間）によって定量化され得る。ホット性の高いコードブロックのほうが、呼び出し回数が多く、および／または応答時間が長い。

規則的または不規則な時間間隔でプロセスから出力される一連のスレッドダンプを解析することによって、いくつかの実施形態は、（１）低オーバヘッドであり、（２）中断を伴わない、（３）常時接続で監視する、かつ（４）計測コードが計測中のコードの実行時間の大半を占めてしまう問題（すなわち、ハイゼンベルク問題）を回避する、統計的標本抽出ソリューションを提供してもよい。

いくつかの実施形態は、強度統計データに基づいてスレッドおよびスタックセグメントを分類してもよい。ソフトウェア実行環境（たとえば、仮想マシン）から受信したスレッドダンプに含まれる個々のスレッドのスタックトレースを監視することによって、監視プロセスは、当該スレッドを、スレッドのスタックトレースの内容に基づいて１つ以上のスレッドクラスに分類できる。さらに多くのスタックトレースが解析されると、いくつかの実施形態は、スレッドクラスのサブクラスへの分岐を観測し、最終的には、スレッドクラスの階層構造を作成してもよい。たとえば、スタックセグメント（Ａ）がスタックセグメント（Ａ，Ｂ，Ｄ）の成分であると観測された場合、スレッド型（Ａ，Ｂ，Ｄ）は、スレッド型（Ａ）のサブクラスであると言えるだろう。また、スレッド型（Ａ，Ｃ）は、スレッド型（Ａ）のサブクラスであるとも言えるだろう。（Ａ，Ｂ，Ｄ）および（Ａ，Ｃ）に対応する強度統計データの集成が（Ａ）に対応する強度統計データによって表され得るという意味では、スレッド型（Ａ）は、サブクラス（Ａ，Ｂ，Ｄ）および（Ａ，Ｃ）を含む。これに加えて、いくつかの実施形態は、スレッドクラス階層構造を下方向に進み（たとえば、ツリーまたはグラフを横断し）、特定のスレッドクラスの強度がこのスレッドクラスの１つ以上のサブクラスの強度にどのように比例し得るかを観測してもよい。たとえば、（Ａ）のスレッド強度は、（Ａ，Ｂ，Ｄ）および（Ａ，Ｃ）のスレッド強度に比例し得る。その他の実施形態では、各スタックトレースは、二分木として表されてもよい。

いくつかの実施形態は、測定値、変化率（rate of change）、加速度、季節因子、および残差を推定するための１つ以上のシーケンシャルフィルタを提供できる。複数の期間（たとえば、平日期間および週末期間）の別々の季節指数を表し、かつ、複数の期間の季節因子を正規化するための手法がこのような実施形態によって実行されてもよい。具体的には、いくつかの実施形態は、複数の期間の各々の季節指数の別個のシーケンスを表してもよい。たとえば、複数の期間は、平日期間、週末期間、四半期末の期間、または個々の祝祭日期間を含んでもよい。また、複数の期間の季節指数を推定する際、いくつかの実施形態は、（１）季節指数をくりこんで（renormalize）、すべての期間にわたって共通のスケールおよび共通の基準レベルを提供し、（２）隣接する期間の端から端まで平滑化スプラインをフィットさせて、１つの期間に含まれるサイクル間の、または２つの隣接する期間に含まれるサイクル間の円滑な遷移をもたらしてもよい。くりこみによって、複数の期間の間の季節因子は、共通のスケールを有し得る。

いくつかの実施形態は、ヒープ使用量統計データと、様々なスレッドのクラスの強度統計データとの間でトレンドを相関させて、高いヒープ使用量との相関度が高い強度統計データを有するスレッドのクラスを特定してもよい。ソフトウェア実行環境において、強度統計データが高いヒープ使用量と高い相関関係にあるスレッドのクラスの中から、非効率なヒープメモリ使用量が見つかる確率は高い。スレッドのクラスが特定されると、スレッドのクラスに関連するコードが調査および／または最適化されてもよい。

いくつかの実施形態は、プロセスを実行するマルチスレッド型環境（たとえば、仮想マシン）のモデル（たとえば、一変量モデル、多変量モデル）を構築および保守してもよい。モデルは、各スレッドクラスの強度の季節トレンド、線形トレンド、および一次非線形トレンドを含む。システムの性能のトレンドについての季節調整済みの長期予測を取得するためにこのようなモデルが用いられてもよい。

（１）スレッドを動的に分類してスレッドクラスのサブクラスの強度がスレッドクラスの総強度にどのように寄与するかを観測し、（２）検出された高いヒープ使用量の期間と様々なスレッドのクラスがどれくらい密接に相関関係にあるのかを観測することによって、いくつかの実施形態は、クラウドサービス・プロビジョニングシステム内のパフォーマンス欠陥の検出および観測を容易にしてもよい。軽微なパフォーマンス欠陥であっても、プロセス内のＳＬＡ違反となり得る問題が明らかになる場合が多いので、サービスプロバイダがパフォーマンス欠陥を検出して対処することを可能にすることによって、このような違反のリスクが大幅に低減される可能性がある。

ＩＩ．スレッドのランタイムのプロファイリング
図１〜図２は、様々なスタックセグメントが互いに関連してどれくらいの間スレッドのコールスタック上に存在するのかを判断するために、実行中のスレッドをプロファイリングする手法を表す図である。図１は、一定期間にわたって１つのスレッド１００のランタイムを比較的高い周波数の標本抽出レートでプロファイリングする例を示す。場合によっては、特定の手法は、ランタイムプロファイラを利用して、スレッドの複数のスタックトレース標本を出力し、図２に示す呼び出しコンテキストのツリー２００を構成してもよい。ランタイムプロファイラが採用する標本抽出間隔がスレッドの実行時間と比較して短い場合、スレッドの呼び出しコンテキストごとの観測回数（すなわち、呼び出し回数）の統計データを使用して、標本抽出間隔に対する呼び出しコンテキストの実行時間を正確に推定および／または表すことができる。

たとえば、図１に示すように、スレッド１００の総実行時間は、１００ミリ秒〜１秒の間であってもよいのに対して、標本抽出間隔は、１０ミリ秒〜１００ミリ秒の間である。スレッドがどのメソッドを呼び出すかによっては、スレッドの実行中にスレッドのスタック内に異なる呼び出しコンテキストが存在してもよい。スレッドは、スタックセグメントＡに対応するメソッドのセットを呼び出すことによって、その実行を開始してもよい。

なお、スタックセグメントは、線形接続された１つ以上のスタックフレームのセットに対応する。線形接続されたスタックフレームは、スタックトレース内で常に一緒に観測されるため、その強度統計データは同じである。したがって、スタックセグメントＡは、スタックフレームａ１、ａ２、およびａ３などの複数のスタックフレームに対応してもよい。スレッドを標本抽出することによって、標本抽出されたスレッドの呼び出しコンテキスト全体をスタックフレームのリストで記述したスタックトレースができてもよい。リストにあるスタックフレームのいくつかが線形接続されている場合、これらのスタックフレームは、概念的に１つのスタックセグメントにまとめられてもよい。その結果、スタックトレースは、１つ以上のスタックフレームを各々が含む１つ以上のスタックセグメントを含むだろう。

スレッドがその実行を続けると、スタックセグメントＡに関連するコードが、当該スレッドに、スタックセグメントＢに対応するメソッドのセットを呼び出させてもよい。次に、スタックセグメントＢに関連するコードが、スレッドに、スタックセグメントＤに対応するさらに別のメソッドのセットを呼び出させてもよい。短い期間の後、ランタイムプロファイラは、スレッド１００の標本１を取ってもよく、その結果、第１スタックトレースができる。第１スタックトレースから、ランタイムプロファイラは、スタックセグメントＡ、Ｂ、およびＤが標本抽出時にスタック上にあったと判断できる。１つの標本抽出間隔の後、ランタイムプロファイラは、スレッドの別の標本２を取ってもよく、その結果、第２スタックトレースができる。第２スタックトレースから、ランタイムプロファイラは、スタックセグメントＡ、Ｂ、およびＤがスタック上にあったと判断できる。スレッドが実行を継続すると、スタックセグメントＤに関連するメソッドが返されてもよく、その結果、スタックから飛び出したスタックセグメントＤに対応するスタックフレームができる。次に、ランタイムプロファイラは、スレッドの別の標本３を取ってもよく、その結果、第３スタックトレースができる。第３スタックトレースから、ランタイムプロファイラは、スタックセグメントＡおよびＢがスタック上にあったと判断できる。

スレッドが実行すると、スタックセグメントＢはスタックセグメントＥを呼び出し、スタックセグメントＥはスタックセグメントＦを呼び出す。次に、標本４を取ることによって、スタックセグメントＡ、Ｂ、Ｅ、およびＦがスタック上にあったことを示す第４スタックトレースができる。スタックセグメントＦ、Ｅ、およびＢは、互いを返す。次に、標本５を取ることによって、スタック上にスタックセグメントＡしかないことを示す第５スタックトレースができる。スタックセグメントＡは、スタックセグメントＣをスタック上にのせる。スタックセグメントＣが戻る前に標本６および７が取られ、その結果、スタックセグメントＡおよびＣがスタック上にあることを示す第６スタックトレースおよび第７スタックトレースができる。最終的に、スタックセグメントＣが戻り、スタック上にはスタックセグメントＡしか残らない。スタックセグメントＡに関連するメソッドが戻ったとき、スレッドは実行を終了する。

図２に示すように、呼び出しコンテキストのツリー２００は、標本抽出間隔に対するスタックセグメントＡ〜Ｆの実行時間を表す。ノード２０２は、７つの標本すべてにおいてスタックセグメントＡが観測されたことを示す。ノード２０４は、７つの標本のうちの４つおいてスタックセグメントＢが観測されたことを示す。ノード２０６は、７つの標本のうちの２つにおいてスタックセグメントＣが観測されたことを示す。ノード２０８は、７つの標本のうちの２つにおいてスタックセグメントＤが観測されたことを示す。ノード２１０は、７つの標本のうちの１つにおいてスタックセグメントＥが観測されたことを示す。ノード２１２は、７つの標本のうちの１つにおいてスタックセグメントＦが観測されたことを示す。スレッド１００の総実行時間が標本抽出間隔の存続期間のほぼ１０倍であるので、各スタックセグメントの観測回数は、スタックセグメントの実行時間と密接な相関関係にあるだろう。たとえば、スタックセグメントＢが４回観測されたので、スタックセグメントＢの相対実行時間は、少なくとも標本抽出間隔の４倍であると推測できる。

場合によっては、スレッド１００が動作する環境（すなわち、ソフトウェア実行環境）は、標本抽出間隔ごとに１つのスレッドダンプが１回出力される仮想マシン（たとえば、ＨｏｔｓｐｏｔＪａｖａ（登録商標）仮想マシン（ＪＶＭ））に対応してもよい。スレッドダンプを出力する前に、仮想マシンは、実行中のスレッドのすべて（たとえば、スレッド１００）にセーフポイントで一時停止するよう信号を送ってもよい。このセーフポイントメカニズムは、フル（full）ガベージコレクションを実行する前にスレッドを一時停止するためにガベージコレクタが使用するものと同様であってもよい。なお、カーネルモードで実行中（たとえば、入出力操作上で実行中／ブロック中）のスレッドは、スレッドがカーネルモードを出て戻る（たとえば、ＪＶＭモードに戻る）までセーフポイントで一時停止しなくてもよい。

なお、しかしながら、高い頻度率でセーフポイントメカニズムを呼び出すことは、相当なオーバヘッドにつながる。したがって、高標本抽出レートに頼るランタイムプロファイリング手法は、本番環境よりも開発環境またはテスト環境にふさわしいだろう。

オーバヘッドを減らすために、いくつかの実施形態は、標本抽出レートを下げることを補償するためのシステムモデルを採用する。たとえば、いくつかの実施形態は、マルチスレッドプロセスのスレッドの強度を追跡して、待機時間を決定する閾値を上回る強度を有するスレッドのみを標本抽出してもよい。低標本抽出レートまたは適応標本抽出レートを採用する実施形態の１つの利点は、カーネルモードで実行中のスレッドがセーフポイントで一時停止させられることが少ないことである。オーバヘッドを低減するその他の方法は、標本抽出中のスレッドの強度に釣り合うように標本抽出間隔を長くすることを必要としてもよい。たとえば、１分の標本抽出間隔は、本番環境内で無視できるオーバヘッドをもたらし得るが、本番環境においてスレッドとその成分スタックセグメントの相対実行時間を導出するには短すぎる可能性がある。したがって、いくつかの実施形態は、リトルの公式の仮定と一致させるための定常平均エルゴード性または周期定常平均エルゴード性を示す本番システムのための常時接続の性能監視ソリューションを提供してもよい。このような実施形態では、常時接続の性能監視ソリューションは、本番システムの１台以上の仮想マシン内で実行中のスレッドを定期的に標本抽出する監視プロセス（すなわち、制御システム）に含められてもよい。

ＩＩＩ．スレッドの分類
様々な実施形態は、スレッドクラスを特定して当該スレッドクラスに関係する強度統計データを追跡するために１台以上の仮想マシン（たとえば、ＪＶＭ）から出力された一連のスレッドダンプ標本を逐次解析するための手法を提供する。たとえば、仮想マシン内での１つ以上のマルチスレッドプロセスの実行中、制御システムは、仮想マシンのスレッドダンプを定期的に出力してもよい。このスレッドダンプによって、仮想マシンにおいて動作中のスレッド毎のスタックトレースができてもよい。受信するスタックトレースごとに、制御システムは、スタックトレースに含まれるテキストを解析して、関連するスレッドを分類し、すべてのスレッドクラスについて追跡された強度統計データをスタックトレースに基づいて更新してもよい。

スレッドを分類することに加えて、実施形態は、前に分類されたスタックセグメントに沿った分岐点で新しいスタックセグメントが出現する度に、当該新しいスタックセグメントを分類してもよい。スレッドクラスが発見される前に制御システムが第１スタックトレースを観測した場合、制御システムは、スタックトレース内のスタックフレームのシーケンス全体が線形接続されていると考えてもよい。なぜならば、今のところスタックフレームのシーケンス全体が一緒でしか現れていないからである。これに応答して、制御システムは、スレッドクラスを初期化して、スタックトレース全体（すなわち、スタックフレームのシーケンス全体）を分類してもよい。制御システムがスタックフレームの様々なシーケンスを含む後続スタックトレースを観測すると、制御システムは、追加のスレッドクラスを初期化して、スタックフレームの一意の順列の各々を分類することができる。場合によっては、制御システムは、先に観測されたスタックトレースとスタックフレームを共有しない（すなわち、共通のスタックフレームを有さない）スタックトレースを観測する場合がある。これに応答して、制御システムは、別のスレッドクラスを初期化して新しいスタックトレースの全体を分類すればよい。

しかしながら、より一般的には、制御システムは、１つ以上のスタックフレームを、先に観測されたスタックトレースと共有するスタックトレース観測することができる。図１に戻ると、たとえば、制御システムが観測した第１スタックトレースが｛（Ａ，Ｂ，Ｄ）｝（すなわち、標本１または標本２に含まれるスタックトレース）であるとする。このスタックトレースは、スタックセグメントＡ、Ｂ、およびＤに含まれるスタックフレームを含む。制御システムは、スレッドクラス｛（Ａ，Ｂ，Ｄ）｝を初期化し、スタックセグメントＡ、Ｂ、およびＤに含まれるスタックフレームを含むと観測されるすべてのスレッドを分類してもよい。次に、制御システムによって観測された第２スタックトレースが｛（Ａ，Ｃ）｝（すなわち、標本６または標本７に含まれるスタックトレース）であるとする。この点については、制御システムは、第１スタックトレースと第２スタックトレースは互いに異なるが、第１スタックトレースと第２スタックトレースは、スタックセグメントＡに含まれるスタックフレームのすべてを共有していると判断してもよい。これによって、スタックセグメントＡにおいて分岐点ができる。これに応答して、制御システムは、スレッドクラス｛（Ａ，Ｃ）｝を初期化して、スタックセグメントＡおよびＣをコールスタック上に含むすべてのスレッドを分類してもよい。

なお、スタックセグメントＡに含まれるスタックフレームがスタックセグメント（Ｂ，Ｄ）に含まれるスタックフレームとは別に観測されたので、スタックセグメントＡと（Ｂ，Ｄ）は、もはや、線形接続されているとは制御システムによって考えられていない。しかし、制御システムは、スタックセグメントＡに含まれるスタックフレームは線形接続されており、スタックセグメント（Ｂ，Ｄ）に含まれるスタックフレームは線形接続されていると今も考えている。この点については、制御システムは、スレッドクラス｛（Ａ，Ｂ，Ｄ）｝およびスレッドクラス｛（Ａ，Ｃ）｝のいくつかのスレッドセグメント成分を初期化して、新しく発見された分岐点によって形成された新しいスタックセグメントを分類してもよい。具体的には、制御システムは、スレッドセグメント（Ａ）、スレッドセグメント（Ｂ，Ｄ）、およびスレッドセグメント（Ｃ）を初期化してもよい。スレッドセグメント（Ａ）および（Ｂ，Ｄ）は、スレッドクラス｛（Ａ，Ｂ，Ｄ）｝の成分であり、スレッドセグメント（Ａ）および（Ｃ）は、スレッドクラス｛（Ａ，Ｃ）｝の成分である。

いくつかの実施形態は、分類シグネチャを用いてスタックトレースおよびスタックセグメントを表してもよい。具体的には、トレースシグネチャは、特定のスレッドクラスのスタックトレースを表すために用いることができ、セグメントシグネチャは、特定のスレッドセグメントのスタックセグメントを表すために用いることができる。各トレースシグネチャは、合成解析処理によって作成されるラベル付けされた二分木から成る組（tuple）に対応してもよい。一方では、スレッドセグメントの各セグメントシグネチャは、スレッドクラスに対応する組のノードに対応してもよい。当該スレッドクラスのスレッドセグメントが組の成分である。後に解析処理において、組を解析木のように（たとえば、生成文法（production grammar）の一部として）用いて、入ってくるスタックトレースを認識してもよい。

上記例に戻ると、第１スタックトレースの観測の後、第２スタックトレースの観測の前、スレッドクラス｛（Ａ，Ｂ，Ｄ）｝は、１つの二分木からなる組に対応してもよい。第１スタックトレース内のフレームのシーケンス全体が１つのスタックセグメントと考えられるので、当該１つの二分木は、スタックセグメント（Ａ，Ｂ，Ｄ）を表す１つの根ノードを含んでもよい。第２スタックトレースの観測の後、組は、まだ１つの二分木しか含んでいないだろう。しかしながら、ここで、二分木は、スタックセグメント（Ａ，Ｂ，Ｄ）を表す根ノードと、スタックセグメント（Ａ）を表す根ノードの第１子ノードと、スタックセグメント（Ｂ，Ｄ）を表す根ノードの第２子ノード、という３つの別々のノードを含んでもよい。トレースシグネチャとセグメントシグネチャとを合成する処理については、図４〜図６を参照して以下にさらに詳細に説明する。

二分木に含まれる各ノードは、コンパクト符号と称され得るラベルまたは識別子によって一意に識別されてもよい。いくつかの実施形態では、スレッドクラスに対応する組の各最上位ノードを識別する１つ以上のコンパクト符号によって、特定のスレッドクラスのスレッドが表されてもよい。ハフマン符号化またはその他のエントロピー符号化方式と同様のやり方で、いくつかの実施形態は、より人気のある（すなわち、より高いスレッド強度の）および／または最初に発見されるスレッドクラスに、より短い組を関連付けてもよい。その結果、より短いコンパクト符号のシーケンスによって、より一般的な型のスレッドをコンパクトに表すことができる。いくつかの実施形態では、これは、オフライン解析（すなわち、オフライン処理）でスタックトレースの確率分布をまず解析して、スタックトレースを頻度の低いものから順に制御システムに送ることによって確実にされてもよい。

オフライン解析に頼らない実施形態では、制御システムは、１台以上の仮想マシン（すなわち、オンライン処理）から定期的に出力されるスレッドダンプとともにスタックトレースを順々に受信してもよい。

異なる型のスタックトレースが観測される順序は、各型のスタックトレースの強度の影響を受ける可能性がある。すなわち、強度が高いスタックトレースは、統計上、シーケンスの中で早く観測される傾向がある。したがって、このような実施形態は、（１）特定のスレッドクラスのスレッド強度が、関連するスタックトレースの発生確率を表し、（２）強度が強いスレッドクラスに関連するスタックトレースのほうが、強度が低いスレッドクラスに関連するスタックトレースよりも前に観測されることが多い、と想定してもよい。この点については、制御システムは、最も高い強度のスレッドについて最もコンパクトな表現を自然に導出する。したがって、オフライン処理ではなくスレッド強度統計データに頼ることによって、いくつかの実施形態は、一連のスレッドダンプに応答して観測されるスタックトレースにとって最適な圧縮アルゴリズムを提供することができる。

Ａ．スレッド強度の季節変動

いくつかの実施形態では、季節トレンド把握処理は、不規則な標本抽出間隔（たとえば、ヒープ使用量の標本抽出および／またはスレッドダンプの出力）を考慮に入れるために、そして、コーシー分布問題を克服するために、変数フィルタパラメータを使用してもよい。また、この処理は、複数の種類の様々な長さ（たとえば、１日、２日）の期間（たとえば、平日期間、週末期間、および祝祭日期間）を逐次フィルタリングすることをサポートできる。さらに、この処理は、スレッドダンプに基づいて決定されるスレッド強度統計データの特定の信頼水準を維持しつつ、季節変動に応じてスレッドダンプの出力率を調整してオーバヘッドを低減できる。また、場合によっては、スレッドダンプ率を調整することによって、オフライン処理のためにネットワーク（たとえば、ＬＡＮ、インターネット）で他のマシン（たとえば、ビッグデータ・レポジトリ）に運ばれる必要のあるスレッドダンプデータの量を最低限に抑えてもよい。

いくつかの実施形態では、季節トレンド把握処理は、平日期間（すなわち、２４時間）を９６個の１５分間隔に分割してもよく、この結果、平日期間ごとに９６個の季節指数（すなわち、季節）ができる。この処理は、週末期間（すなわち、４８時間）を１９２個の１５分間隔に分割してもよく、この結果、週末期間ごとに１９２個の季節指数ができる。特定の長さのデータセット（たとえば、１つまたは２つの週末を含む１０日間のスレッドダンプまたはヒープ使用量を記録した時系列）を受信すると、処理は、１つの平日にわたって観測された季節パターンと全週末にわたって観測された季節パターンとを分けるために、平日期間と週末期間とに多期間トレンド把握フィルタを別々に適用することができ、この結果、各平日に含まれる９６個の季節指数に対して、９６個の季節因子からなるセット、および、各週末に含まれる１９２個の季節指数に対して、１９２個の季節因子からなるセットができる。次に、この処理は、「１」という季節因子が平日期間および週末期間に共通の基準レベルを表すように、平日季節因子および週末季節因子をくりこんでもよい。

なお、１よりも大きい季節因子が季節指数に割り当てられた場合、その季節指数は、期間の残りと比較して、平均値よりも高い値を有する。一方では、１よりも小さい季節因子が季節指数に割り当てられた場合、その季節指数は、期間の残りと比較して、平均値よりも低い値を有する。たとえば、午前９時〜午前９時１５分という間隔に対応する季節指数の特定のスレッドクラスのスレッド強度の季節因子が１．３である場合、午前９時〜午前９時１５分という間隔の間のその特定のスレッドクラスの平均スレッド強度は、その特定のスレッドクラスの平日全体の平均スレッド強度よりも３０％高い。

いくつかの実施形態では、平日期間は２４時間ごとに繰り返し、週末期間は５日または７日ごとに繰り返すが、季節トレンド把握処理は、祝祭日（たとえば、労働者の日（Labor Day）、クリスマス祭日）を、１２か月に１回の頻度で繰り返す別個の期間として分けてもよい。１という季節因子がすべての期間に共通の基準レベルを表すように、平日期間および週末期間の季節因子のセットとともに、このような祝祭日期間の季節因子のセットがくりこまれてもよい。必要に応じて適切にその他の頻度が各期間に用いられてもよい。例として、祝祭日が６か月ごとの頻度などで分けられてもよいのに対して、平日は、１２時間ごとに繰り返す期間などであってもよい。

いくつかの実施形態では、強度統計データの決定および追跡は、将来の値および変化率を予測することをさらに含んでもよい。しかしながら、標本抽出間隔は、不規則で有り得、または、気まぐれにゼロに近づいてしまったりさえする。標本抽出間隔が気まぐれにゼロに近づいてしまう場合、変化率は、平均および標準偏差が未定義であるコーシー分布の確率変数になる可能性がある。適応標本抽出間隔を用いて季節トレンドを決定することについてのコーシー分布問題を克服するために、いくつかの実施形態は、ホルト（Ｈｏｌｔ）の２重指数フィルタ、ウィンター（Ｗｉｎｔｅｒ）の３重指数フィルタ、ライト（Ｗｒｉｇｈｔ）の不規則な間隔のための拡張、ハンザック（Ｈａｎｚａｋ）の時間近接間隔の調整因子、外れ値の検出、および外れ値のカットオフの適応型スケーリングを伴うクリッピングなど、様々な適応を採用してもよい。指数フィルタの５つのセットをデータセットに逐次適応して、平日期間および週末期間の季節因子のセットを推定することができる。

Ｂ．分類シグネチャおよび圧縮方式
特定の実施形態は、コンパクト符号の可変長シーケンスをスレッドのスタックトレースに割り当て得る。シーケンスの長さは、スレッドの強度によって異なる。例示的なスタックトレースを以下に示す。

スタックトレースの例では、ＪａｖａＤａｔａｂａｓｅＣｏｎｎｅｃｔｉｖｉｔｙ（ＪＤＢＣ）ドライバのスタックセグメント（すなわち、「ｏｒａｃｌｅ．ｊｄｂｃ．ｄｒｉｖｅｒ…」を含んだ２つのスタックフレーム）下のスタックフレーム「ｏｒａｃｌｅｍｄｓｃｏｒｅＭｅｔａｄａｔａＯｂｊｅｃｔｇｅｔＢａｓｅＭＯ」は、ＭｅｔａＤａｔａＳｅｒｖｉｃｅ（ＭＤＳ）ライブラリが当該ＪＤＢＣスタックセグメントに対応するＪＤＢＣ動作を呼び出すことを示す。ＭＤＳライブラリのスタックセグメント（すなわち、「ｏｒａｃｌｅ．ｍｄｓ…」を含んだ３つのスタックフレーム）下のスタックフレーム「ｏｒａｃｌｅａｄｆｍｏｄｅｌｓｅｒｖｌｅｔＡＤＦＢｉｎｄｉｎｇＦｉｌｔｅｒｄｏＦｉｌｔｅｒ」は、ＭＤＳ動作がＡｐｐｌｉｃａｔｉｏｎＤｅｖｅｌｏｐｍｅｎｔＦｒａｍｅｗｏｒｋ（ＡＤＦ）動作によって呼び出されることを示す。このスタックトレースの下部のＷｅｂＬｏｇｉｃスタックセグメント（すなわち、「ｗｅｂｌｏｇｉｃ…」を含んだ４つのスタックフレーム）が示すように、ＡＤＦ動作は、ＨｙｐｅｒｔｅｘｔＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ（ＨＴＴＰ）Ｓｅｒｖｌｅｔリクエストによって呼び出される。

例として、２レベルハフマン符号化法を用いて上記スタックトレースを符号化して圧縮することができ、その結果、このスタックトレース例を表すコンパクト符号のシーケンスができる。第１レベルでは、圧縮ツール（たとえば、ｇｚｉｐ）が、「ＳｅｒｖｌｅｔＲｅｑｕｅｓｔＩｍｐｌ．ｊａｖａ」および「ｗｅｂｌｏｇｉｃ．ｓｅｒｖｌｅｔ．ｉｎｔｅｒｎａｌ．ＳｅｒｖｌｅｔＲｅｑｕｅｓｔＩｍｐｌ．ｒｕｎ」など、スタックトレース内の部分文字列を検出して、これらの部分文字列がどれだけ頻繁にスタックトレースに存在するかに応じて部分文字列のハフマン符号を導出できる。圧縮比を上げるためには、より頻繁に存在する部分文字列に、より短いハフマン符号を割り当てればよい。第１レベルの圧縮の後、圧縮されたスタックトレースは、ハフマン符号から部分文字列を復元するために使用され得る符号化辞書をメタデータとして含んでもよい。

第２レベルは、スタックトレースのスタックセグメントをセグメントシグネチャに置き換えることによって、圧縮されたスタックトレースに別レベルの圧縮を加えることを必要としてもよい。第２レベルの圧縮を加えるステップについては、図４〜図６を参照して以下にさらに詳細に説明する。

Ｃ．データ構造の例
分類シグネチャは、１つ以上のオブジェクト型を介してメモリで表されてもよい。具体的には、いくつかの実施形態は、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトを用いてスレッドクラスの分類シグネチャ（すなわち、トレースシグネチャ）を表し、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトを用いてスレッドセグメントの分類シグネチャ（すなわち、セグメントシグネチャ）を表し、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトを用いてスタックセグメント内の線形接続されたスタックフレームに含まれる各要素を表し、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトを用いてスレッドクラスまたはスレッドセグメントの強度統計データをカプセル化して追跡してもよい。

ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクト、ＳｅｇｍｅｎｔＩｎｆｏオブジェクト、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクト、およびＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトを定義するクラス／インタフェース定義の例を以下に示す。

上記定義から分かるように、各ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクト、ＳｅｇｍｅｎｔＩｎｆｏオブジェクト、およびＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、一意の識別子（すなわち、ＩＤ）と、名称と、同じ型（たとえば、同じスレッドクラス、同じスレッドセグメント、同じ型のスタックフレーム）のオブジェクトが最新のスレッドダンプにおいて観測された回数（すなわち、ｎｕｍＯｆＯｃｃｕｒ）を追跡するカウンタと、同じ型のオブジェクトがすべてのスレッドダンプにおいて観測された回数を追跡する別のカウンタとを含む。

ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトは、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトのリストと、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトとを含み得る。この点については、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏが二分木からなる組に対応し得るのに対して、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトのリストは、二分木を構成するノードに対応する。ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトは、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトが表すスレッドクラスに関する強度統計データ（たとえば、フィルタ状態）を記録してもよい。

ＳｅｇｍｅｎｔＩｎｆｏオブジェクトは、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのリストと、第１の子であるＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、ｆｉｒｓｔＳｅｇｍｅｎｔ）と、第２の子であるＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、ｓｅｃｏｎｄＳｅｇｍｅｎｔ）と、結合（coalescing）（すなわち、親である）ＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、ｃｏａｌｅｓｃｉｎｇＳｅｇｍｅｎｔ）と、前節の兄弟であるＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、前節点）のリストと、次節の兄弟であるＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、次節点）のリストと、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトとを含み得る。この点については、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトは、スタックセグメントに対応し得る。ＳｅｇｍｅｎｔＩｎｆｏオブジェクトが葉ノードに対応する場合、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのリストは、スタックセグメントに含まれる線形接続されたスタックフレームに対応してもよい。ＳｅｇｍｅｎｔＩｎｆｏオブジェクトが分岐点に隣接する場合、兄弟であるＳｅｇｍｅｎｔＩｎｆｏオブジェクトは、分岐点の反対側のスタックセグメントに対応し得るのに対して、結合ＳｅｇｍｅｎｔＩｎｆｏオブジェクトは、当該スタックセグメントおよび兄弟スタックセグメントを含む親スタックセグメントに対応し得る。ＳｅｇｍｅｎｔＩｎｆｏオブジェクトが葉ノードに対応しない場合、子であるＳｅｇｍｅｎｔＩｎｆｏオブジェクトは、スタックセグメントにおいて分岐点が発見された時に作成されたスタックセグメントのサブセグメントに対応し得る。ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトは、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトが表すスレッドセグメントに関する強度統計データを記録してもよい。

いくつかの実施形態は、一緒に観測されるＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのリストを１つのＳｅｇｍｅｎｔＩｎｆｏノードに関連付けることによって、スタックトレースのスタックセグメントを分類してもよい。すなわち、ＳｅｇｍｅｎｔＩｎｆｏノードは、スタックセグメントの各ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトの結合ノードである。各ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、１つの結合ＳｅｇｍｅｎｔＩｎｆｏノードを有してもよい。ＳｅｇｍｅｎｔＩｎｆｏノードの線形接続されたＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトに沿った箇所のどこかで分岐点が検出された場合、いくつかの実施形態は、２つの新しいＳｅｇｍｅｎｔＩｎｆｏノードを作成し、線形接続されたＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトを、新しいＳｅｇｍｅｎｔＩｎｆｏノードの２つの線形接続されたＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのセットに分割してもよい。次に、この２つのＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトを分岐点を経由して接続することができる。

新しいＳｅｇｍｅｎｔＩｎｆｏノードの各々は、セグメントの一部においてＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトの結合ノードになる。特定の実施形態は、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのｃｏａｌｅｓｃｉｎｇＳｅｇｍｅｎｔを、各ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトが適切な結合ＳｅｇｍｅｎｔＩｎｆｏノードを参照するように、対応付けて更新できる。この２つの新しいＳｅｇｍｅｎｔＩｎｆｏノードは、左兄弟ノードと右兄弟ノードとして表される。また、この２つの新しいＳｅｇｍｅｎｔＩｎｆｏノードは、元のＳｅｇｍｅｎｔＩｎｆｏノードの子ノードにもなり、当該元のＳｅｇｍｅｎｔＩｎｆｏノードは、これら２つの新しいＳｅｇｍｅｎｔＩｎｆｏノードの親になる。親であるＳｅｇｍｅｎｔＩｎｆｏノードは、２つの新しいＳｅｇｍｅｎｔＩｎｆｏノードの結合ノードになり得る。

発見された分岐点に応答してスタックセグメントを分割する処理によって、ＳｅｇｍｅｎｔＩｎｆｏノードから構成される二分木構造ができ得る。この分割処理は、スレッドクラス（すなわち、スタックトレースのクラス）のスレッドサブクラスへの分岐として見られ得る。いくつかの実施形態は、スタックセグメントに含まれる個々のスタックフレームの強度が時間の経過に伴い発散するにつれ、スタックセグメントをより小さなスタックセグメントに分割し続けることができる。これによって、スレッドクラス階層構造をドリルダウンして、スレッドクラスの強度がスレッドサブクラスの強度にどのように比例し得るかを観測することが可能になる。

いくつかの実施形態では、二分木の内部にあるＳｅｇｍｅｎｔＩｎｆｏノードは、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトがすべて線形接続されているわけではない親ノードである。なぜならば、分岐点を経由して接続されているスタックフレームもあるからである。対照的に、葉であるＳｅｇｍｅｎｔＩｎｆｏノードのＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、線形接続されている可能性がある。ＳｅｇｍｅｎｔＩｎｆｏノード内で、線形接続または分岐点で接続されたＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、下側にＳｔａｃｋＦｒａｍｅＩｎｆｏ、上側にＳｔａｃｋＦｒａｍｅＩｎｆｏを有するスタックとして方向付けられ得る。慣習により、左の兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードに含まれる上側のＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、右の兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードに含まれる下側のＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトに、分岐点を経由して接続され得る。

各ＳｅｇｍｅｎｔＩｎｆｏノードは、ＳｅｇｍｅｎｔＩｎｆｏノードが表すスレッド（サブ）クラスの強度統計データを追跡するためのＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトを含んでもよい。ＳｅｇｍｅｎｔＩｎｆｏノードを２つの新しい子であるＳｅｇｍｅｎｔＩｎｆｏノードに分割する際、いくつかの実施形態は、ＳｅｇｍｅｎｔＩｎｆｏノードのＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトをクローン作成して２つの新しいＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトを作成し、子であるＳｅｇｍｅｎｔＩｎｆｏノードの各々に１つのＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトをセットすることができる。

いくつかの実施形態は、分割処理を通して親であるＳｅｇｍｅｎｔＩｎｆｏノードのフィルタ状態を新しい子であるＳｅｇｍｅｎｔＩｎｆｏノードに複製する機能を提供する。そうすることで、いくつかの実施形態は、親であるＳｅｇｍｅｎｔＩｎｆｏノードと兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードとの間の強度統計データの比を常時追跡することができる。具体的には、子であるＳｅｇｍｅｎｔＩｎｆｏノードの強度統計データは、当初、親であるＳｅｇｍｅｎｔＩｎｆｏノードの強度統計データと同じである。しかしながら、新しい標本が取得されると、子であるＳｅｇｍｅｎｔＩｎｆｏノードの強度統計データは、親であるノードの強度統計データから、および、その他の子であるＳｅｇｍｅｎｔＩｎｆｏノードの強度統計データから発散し始めるだろう。新しいスタックセグメントのフィルタ状態は別々に更新されるので、新しいスタックセグメントのフィルタ状態は、互いから、および、元のスタックセグメントのフィルタ状態からはずれ始めるだろう。

場合によっては、親であるＳｅｇｍｅｎｔＩｎｆｏノードと兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードとの間の強度統計データは、時間の経過に伴い一定の比に収束し得る。いくつかの実施形態は、親子および兄弟関係をＳｅｇｍｅｎｔＩｎｆｏノード間で当てはめて、多変量状態推定手法の場合の相関モデルを定義することができる。具体的には、この処理が定常である場合、関係するＳｅｇｍｅｎｔＩｎｆｏノード間の強度統計データの比は、定常状態に収束するだろう。具体的には、処理が厳密な意味または広い意味で定常である場合、関係するＳｅｇｍｅｎｔＩｎｆｏノード間の強度統計データの同時確率分布の１次モーメントおよび２次モーメント（関係するＳｅｇｍｅｎｔＩｎｆｏノードの平均、分散、自己共分散、および相互共分散を含み得る）は、時間の経過とともに変化することはないだろう。したがって、親であるＳｅｇｍｅｎｔＩｎｆｏノードと兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードとの間の強度統計データの比は、時間の経過に伴い収束すると予想され得る。したがって、分岐点を経由する兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードの強度統計データを常時追跡し、親であるＳｅｇｍｅｎｔＩｎｆｏノードと兄弟であるＳｅｇｍｅｎｔＩｎｆｏノードとの間の強度統計データの比が時間の経過に伴い収束すると判断することによって、いくつかの実施形態は、当該比を用いて、多変量状態推定手法の場合の相関モデルを定義することができる。結果として得られるモデルは、アノマリ検出法と予測を生成することに用いることができる。

ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、１つ以上の前節のＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトおよび／または１つ以上の次節のＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクト（すなわち、前節点および次節点）と、結合ＳｅｇｍｅｎｔＩｎｆｏオブジェクト（すなわち、ｃｏａｌｅｓｃｉｎｇＳｅｇｍｅｎｔ）と、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクト（すなわち、ｃｌａｓｓＭｅｔｈｏｄＬｉｎｅＮｕｍｂｅｒ）が参照するコードを識別する情報とを含み得る。ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトが分岐点に隣接しない場合、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、１つの前節点であるスタックフレームと１つの次節点であるスタックフレームとに線形接続することができる。ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、含んでいるＳｅｇｍｅｎｔＩｎｆｏオブジェクトを、メンバ変数ｃｏａｌｅｓｃｉｎｇＳｅｇｍｅｎｔによって参照することができる。

最新のスレッドダンプを処理する時が来ると、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクト、ＳｅｇｍｅｎｔＩｎｆｏオブジェクト、およびＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトごとのメンバ変数ｎｕｍＯｆＯｃｃｕｒは、０にリセットされ得る。スレッドダンプから得られた各スタックトレースは、スタックトレースの下から上に構文解析されてもよい。第１レベルのハフマン符号化法を適用して当該スタックトレースを圧縮した後、スタックトレースの各行は、ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトに構文解析されてもよい。ＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのリストをＳｅｇｍｅｎｔＩｎｆｏオブジェクトのリストに構文解析した後、いくつかの実施形態は、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトの一致するリストを含むＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトにＳｅｇｍｅｎｔＩｎｆｏオブジェクトのリストを照合しようと試みてもよい。このようなＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトが存在しない場合、いくつかの実施形態は、ＳｅｇｍｅｎｔＩｎｆｏオブジェクトのリストを表すための新しいＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトを登録してもよい。その後、次に、いくつかの実施形態は、一致する／新しいＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトのｎｕｍＯｆＯｃｃｕｒメンバ変数およびｔｏｔａｌＮｕｍＯｆＯｃｃｕｒメンバ変数、ならびに当該一致する／新しいＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトに含まれる各ＳｅｇｍｅｎｔＩｎｆｏオブジェクトおよびＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトを更新してもよい。なお、ＳｅｇｍｅｎｔＩｎｆｏノードが葉レベルのノードである場合、当該ノードのｎｕｍＯｆＯｃｃｕｒメンバ変数は、ＳｅｇｍｅｎｔＩｎｆｏノードに含まれる各ＳｔａｃｋＦｒａｍｅＩｎｆｏ要素のｎｕｍＯｆＯｃｃｕｒメンバ変数と同等である。

次に、いくつかの実施形態は、関連するＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトにカプセル化された強度の統計的測定値を更新できる。具体的には、いくつかの実施形態は、含んでいるＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトまたはＳｅｇｍｅｎｔＩｎｆｏオブジェクトのｎｕｍＯｆＯｃｃｕｒメンバ変数にｒａｗＭｅａｓｕｒｅをセットすることによって、各ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトに含まれるｒａｗＭｅａｓｕｒｅメンバ変数を更新してもよい。なお、いくつかの実施形態では、ｒａｗＭｅａｓｕｒｅは、Ｎ個のスレッドダンプごとに更新されればよく、この場合、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのｒａｗＭｅａｓｕｒｅは、Ｎで除算された対応するｎｕｍＯｆＯｃｃｕｒにセットされる。いくつかの実施形態では、このような実施形態は、関連するＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトまたは関連するＳｅｇｍｅｎｔＩｎｆｏオブジェクトのｎｕｍＯｆＯｃｃｕｒメンバ変数がゼロでない場合にのみ、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのｒａｗＭｅａｓｕｒｅメンバ変数を更新してもよい。ｎｕｍＯｆＯｃｃｕｒメンバ変数がゼロでない場合、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのｒａｗＭｅａｓｕｒｅは、Ｎで除算されたｎｕｍＯｆＯｃｃｕｒの値にセットされる。ここで、Ｎは、ｒａｗＭｅａｓｕｒｅが最後に更新されてからのスレッドダンプの数である。このような実施形態では、メソッドは、ｎｕｍＯｆＯｃｃｕｒがゼロであるときのケースを、使用可能な測定値がないかのように扱う。この点については、使用可能な測定値がない場合、ｒａｗＭｅａｓｕｒｅは更新されない。言い換えると、このような実施形態は、ｒａｗＭｅａｓｕｒｅ「Ｎ」が最後に更新されてからのスレッドダンプの数を追跡する。スレッド強度の測定値は、不規則な時系列に対応してもよい。なお、不規則な間隔のための指数フィルタ（たとえば、上述したホルトの二重指数およびウィンターの３重指数フィルタ）は、ｒａｗＭｅａｓｕｒｅを効果的にフィルタリングし、季節変動が除去された（de-seasonalized）測定値および季節因子を、不規則な間隔で行われた一連の測定から得ることができる。

なお、各ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトは、次の統計的測定値の各々に適用されている５つの指数フィルタのセットによって生成された時系列データを含み得る：スレッド強度の生測定値、スレッド強度が増加または減少する率、この率の加速または減速、スレッド強度の季節因子、および残差成分。ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクト内では、変数用の５つの指数フィルタのセットの状態、フィルタ定数、（標本間の不規則な間隔のために調整する）フィルタパラメータ調整重み因子、およびフィルタパラメータは、当該時系列データによって表され得る。

Ｄ．分類シグネチャの生成の例
図３は、いくつかの実施形態に係る、一定期間にわたる仮想マシン３００のスレッドダンプの例を示す図である。図１の標本抽出間隔が１００ミリ秒〜１秒であるランタイムプロファイリングとは対照的に、図３の制御システムが採用する標本抽出間隔は、標本抽出のオーバヘッドを低減するために、さらに長くてもよい（たとえば、２０秒〜１分の間）。図３に示すように、２〜３つの標本抽出間隔内で、仮想マシン３００内で動作中のプロセスは、スレッド３０２、３０４、３０６、３０８、３１０、および３１２を生成する。スレッド３０２〜３１２の各々は、動作中に別のコールスタックに関連付けられるので、スレッドダンプが出力されたときにスタックトレースを出力することができる。図３は、スレッドダンプＮ、スレッドダンプＮ＋１、およびスレッドダンプＮ＋２という、全部で３つの出力されるスレッドダンプを表す。

図３は、３つの連続したスレッドダンプにおいて（Ａ，Ｂ，Ｄ）、（Ａ，Ｂ，Ｄ）、（Ａ，Ｃ）、（Ａ，Ｂ，Ｅ）の順序で観測される３つの異なる型のスタックトレースを示す。スタックトレース（Ａ，Ｂ，Ｄ）は、２回観測される。スレッドダンプＮが出力される前に、スレッド３０２が生成されて動作を開始する。スレッドダンプＮが出力されると、スレッド３０２に関して、スタックトレース（Ａ，Ｂ，Ｄ）が観測される。なお、スタックセグメントＡ、スタックセグメントＢ、およびスタックセグメントＤはまだ識別されていないが、説明を簡単にするため、図３に示す例の初めから終わりまでスタックセグメントの名前を使用する。スレッドダンプＮが出力された後に１つの標本抽出間隔が経過すると、スレッド３０２が終了し、スレッド３０６および３０８が生成されている間にスレッド３０４が生成されて、標本抽出されることなく終了する。スレッドダンプＮ＋１が出力されると、スレッド３０８がスタックトレース（Ａ，Ｂ，Ｄ）を出すのに対して、スレッド３１０は、スタックトレース（Ａ，Ｃ）を出す。スレッドダンプＮ＋１が出力された後に別の標本抽出間隔が経過すると、スレッド３０６および３０８が終了し、スレッド３１０が生成されて、標本抽出されることなく終了し、スレッド３１２が生成される。スレッドダンプＮ＋２が出力されると、スレッド３１２は、スタックトレース（Ａ，Ｂ，Ｅ）を出す。図３から分かるように、（Ａ，Ｂ，Ｄ）スレッド型は、観測される最初の型のスレッドであり、（Ａ，Ｂ，Ｄ）スレッド型の強度は、（Ａ，Ｃ）または（Ａ，Ｂ，Ｅ）スレッド型よりも大きい。

スレッドダンプＮの後、制御システムは、１つのＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）ノードをスタックトレース（Ａ，Ｂ，Ｄ）の分類シグネチャとして登録できる。次に、制御システムは、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ａ，Ｂ，Ｄ）オブジェクトをＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）ノードに関連付けて、このノードによってカプセル化された状態を更新してもよい。

SegmentInfo(A,B,D).numOfOccur = 1.
SegmentInfo(A,B,D).totalNumOfOccur = 1.
図４は、スタックトレース（Ａ，Ｂ，Ｄ）に応答して登録された１つの分類シグネチャ４５０を含む分類シグネチャ４００のセットを示す図である。図４から分かるように、分類シグネチャ４５０は、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）に対応する１つのノード４０２を含む。ＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）は、スタックトレースのすべてのスタックフレームａ１〜ｄ３の結合ノードとして示されている。

スレッドダンプＮ＋１においてスタックトレース（Ａ，Ｂ，Ｄ）が再び観測された場合、制御システムは、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）ノードを、以下のように更新してもよい。

SegmentInfo(A,B,D).numOfOccur = 1.
SegmentInfo(A,B,D).totalNumOfOccur = 2.
スレッドダンプＮ＋１においてスタックトレース（Ａ，Ｃ）が初めて観測された場合、制御システムは、スタックセグメント（Ａ，Ｂ，Ｄ）内のスタックフレームのセット全体はもはや線形接続されていないと判断する。ここで、「Ａ」で表されるスタックフレームのセットのうちの最後のスタックフレーム（たとえば、スタックトレースの上から下へと進む）と、「Ｂ，Ｄ」で表されるスタックフレームのセットのうちの最初のスタックフレームとの間に分岐点が存在する。なぜならば、どのようなスタックトレースにおいても、最後のスタックフレームに続く次のスタックフレームは、（１）（Ｂ，Ｄ）のうちの最初のスタックフレーム、または（２）「Ｃ」で表されるスタックフレームのセットのうちの最初のスタックフレームであるからである。したがって、制御システムは、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ａ）およびＳｅｇｍｅｎｔＩｎｆｏ（Ｂ，Ｄ）を作成してこれら２つのノードをＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）の子ノードに割り当てることによって、スタックセグメント（Ａ，Ｂ，Ｄ）をスタックセグメント（Ａ）とスタックセグメント（Ｂ，Ｄ）とに分割してもよい。スタックトレース（Ａ，Ｃ）については、制御システムは、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ｃ）を作成することによってスタックセグメント（Ｃ）を初期化し、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ）およびＳｅｇｍｅｎｔＩｎｆｏ（Ｃ）をスタックトレース（Ａ，Ｃ）の分類シグネチャとして含む順序組を登録してもよい。

いくつかの実施形態では、制御システムは、下記のように、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ａ，Ｂ，Ｄ）オブジェクトをクローン作成して、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ａ）およびＳｅｇｍｅｎｔＩｎｆｏ（Ｂ，Ｄ）のＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ａ）オブジェクトおよびＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｂ，Ｄ）オブジェクトをそれぞれ作成し、ＳｅｇｍｅｎｔＩｎｆｏ（Ｃ）の新しいＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｃ）を作成してもよい。

SeasonalTrendInfo(A) <-SeasonalTrendInfo(A,B,D)
SeasonalTrendInfo(B,D) <-SeasonalTrendInfo(A,B,D)
SeasonalTrendInfo(C) <- new SeasonalTrendInfo
また、制御システムは、上記ＳｅｇｍｅｎｔＩｎｆｏノードを、以下のように更新してもよい。

SegmentInfo(A).numOfOccur = 2
SegmentInfo(A).totalNumOfOccur = 3

SegmentInfo(C).numOfOccur = 1
SegmentInfo(C).totalNumOfOccur = 1
図５は、分類シグネチャ４５０と、スタックトレース（Ａ，Ｃ）を初めて観測したことに応答して生成された新しい分類シグネチャ５５０とを含む、分類シグネチャ５００のセットを示す図である。図５から分かるように、ここで、分類シグネチャ４５０は、ノード４０２、ノード５０２、およびノード５０４という３つのノードを含む。ノード４０２は、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ，Ｂ，Ｄ）に対応し、これは、ノード５０２およびノード５０４の結合ノードである。ノード５０２は、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ）に対応し、スタックフレームａ１〜ａ３を結合する。ノード５０４は、ＳｅｇｍｅｎｔＩｎｆｏ（Ｂ，Ｄ）に対応し、スタックフレームｂ１〜ｄ３を結合する。分類シグネチャ５５０は、スタックフレームａ１〜ａ３を結合するものとして示されるＳｅｇｍｅｎｔＩｎｆｏ（Ａ）に対応するノード５０６、および、スタックフレームｃ１〜ｃ３を結合するものとして示されるＳｅｇｍｅｎｔＩｎｆｏ（Ｃ）に対応するノード５０８という２つのノードを含む。

スレッドダンプＮ＋２においてスタックトレース（Ａ，Ｂ，Ｅ）が初めて観測された場合、制御システムは、スタックセグメント（Ｂ，Ｄ）内のスタックフレームのセット全体はもはや線形接続されていないと判断する。ここで、「Ｂ」で表されるスタックフレームのセットのうちの最後のスタックフレームと「Ｄ」で表されるスタックフレームのセットのうちの最初のスタックフレームとの間に分岐点が存在する。なぜならば、どのようなスタックトレースにおいても、最後のスタックフレームに続く次のスタックフレームは、（１）（Ｄ）のうちの最初のスタックフレーム、または（２）「Ｅ」で表されるスタックフレームのセットのうちの最初のスタックフレームであるからである。したがって、制御システムは、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ｂ）およびＳｅｇｍｅｎｔＩｎｆｏ（Ｄ）を作成して、これら２つのノードをＳｅｇｍｅｎｔＩｎｆｏ（Ｂ，Ｄ）の子ノードに割り当てることによって、スタックセグメント（Ｂ，Ｄ）をスタックセグメント（Ｂ）とスタックセグメント（Ｄ）とに分割してもよい。スタックトレース（Ａ，Ｂ，Ｅ）については、制御システムは、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ｅ）を作成することによってスタックセグメント「Ｅ」を初期化し、ＳｅｇｍｅｎｔＩｎｆｏ（Ａ）、ＳｅｇｍｅｎｔＩｎｆｏ（Ｂ）、およびＳｅｇｍｅｎｔＩｎｆｏ（Ｅ）をスタックトレース（Ａ，Ｂ，Ｅ）の分類シグネチャとして含む順序組を登録してもよい。

いくつかの実施形態では、制御システムは、下記のように、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｂ，Ｄ）オブジェクトをクローン作成して、ノードＳｅｇｍｅｎｔＩｎｆｏ（Ｂ）およびＳｅｇｍｅｎｔＩｎｆｏ（Ｄ）のＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｂ）オブジェクトおよびＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｄ）オブジェクトをそれぞれ作成し、ＳｅｇｍｅｎｔＩｎｆｏ（Ｅ）の新しいＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏ（Ｅ）を作成してもよい。

SeasonalTrendInfo(B) <-SeasonalTrendInfo(B,D)
SeasonalTrendInfo(D) <-SeasonalTrendInfo(B,D)
SeasonalTrendInfo(E) <- new SeasonalTrendInfo
また、制御システムは、上記ＳｅｇｍｅｎｔＩｎｆｏノードを、以下のように更新してもよい。

SegmentInfo(A).numOfOccur = 1
SegmentInfo(A).totalNumOfOccur = 4

SegmentInfo(B).numOfOccur = 1
SegmentInfo(B).totalNumOfOccur = 3

SegmentInfo(E).numOfOccur = 1
SegmentInfo(E).totalNumOfOccur = 1
図６は、分類シグネチャ４５０および５５０と、スタックトレース（Ａ，Ｂ，Ｅ）に応答して生成された新しい分類シグネチャ６５０とを含む、分類シグネチャ６００を示す図である。図６から分かるように、ここで、分類シグネチャ４５０は、ノード４０２、ノード５０２、ノード５０４、ノード６０２、およびノード６０４という５つのノードを含む。ノード５０４は、ＳｅｇｍｅｎｔＩｎｆｏ（Ｂ，Ｄ）に対応し、これは、ノード６０２とノード６０４との結合ノードである。ノード６０２は、ＳｅｇｍｅｎｔＩｎｆｏ（Ｂ）に対応し、スタックフレームｂ１〜ｂ３を結合する。ノード６０４は、ＳｅｇｍｅｎｔＩｎｆｏ（Ｄ）に対応し、これは、スタックフレームｄ１〜ｄ３の結合ノードである。分類シグネチャ５５０は変更されていない。分類シグネチャ６５０は、スタックフレームａ１〜ａ３を結合するものとして示されるＳｅｇｍｅｎｔＩｎｆｏ（Ａ）に対応するノード６０６、スタックフレームｂ１〜ｂ３を結合するものとして示されるＳｅｇｍｅｎｔＩｎｆｏ（Ｂ）に対応するノード６０８、およびスタックフレームｅ１〜ｅ３を結合するものとして示されるＳｅｇｍｅｎｔＩｎｆｏ（Ｅ）に対応するノード６１０という３つのノードを含む。

図６に示すように、スタックトレース（Ａ，Ｂ，Ｄ）の分類シグネチャは、分類シグネチャ４５０の根にある１つのＳｅｇｍｅｎｔＩｎｆｏノードから構成され得る。すなわち、強度が最も高いスタックトレースであるスタックトレース（Ａ，Ｂ，Ｄ）は、最もコンパクトな表現を有する。一方では、スタックトレース（Ａ，Ｃ）には、２つの順序ノード（Ａ）および（Ｃ）を有する２番目に短い分類シグネチャが割り当てられている。最後に検出されたスタックトレース（Ａ，Ｂ，Ｅ）には、３つの順序ノード（Ａ）、（Ｂ）、および（Ｅ）を有する３番目に短い分類シグネチャが割り当てられている。図４〜図６に示すように、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトは、ＳｅｇｍｅｎｔＩｎｆｏノードからなる組に対応してもよく、１つのＳｅｇｍｅｎｔＩｎｆｏノードは、その他のＳｅｇｍｅｎｔＩｎｆｏノードおよび／またはその他のＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのセットからなる二分木（またはバイナリである部分木）を参照してもよい。ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクト、ＳｅｇｍｅｎｔＩｎｆｏノード、およびＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトは、合わせて、生成文法を構成してもよい。

Thread1 -> (A,B,D)
Thread2 ->(A)(C)
Thread3 ->(A)(B)(E)
(A,B,D) ->(A)(B,D)
(B,D) ->(B)(D)

A -> a1,a2,a3
B -> b1,b2,b3
C -> c1,c2,c3
D -> d1,d2,d3
E -> e1,e2,e3
上記から分かるように、個々のスタックフレームａｉ、ｂｉ、ｃｉ、ｄｉ、ｅｉが文法の終端であるのに対して、ＳｅｇｍｅｎｔＩｎｆｏノードは、非終端である。いくつかの実施形態は、スタックトレースのスタックフレームを、スタックトレースの下から上に（下記の表記法において左から右の方向に）構文解析できる。

a1,a2,a3,b1,b2,b3,d1,d2,d3
(A),b1,b2,b3,d1,d2,d3 生成規則(A)->a1,a2,a3を使用
(A),(B),d1,d2,d3 生成規則(B)->b1,b2,b3を使用
(A),(B),(D) 生成規則(D) -> d1,d2,d3を使用
(A),(B,D) 生成規則(B,D) -> (B)(D)を使用
(A,B,D) 生成規則(A,B,D) -> (A),(B,D)を使用
Thread1 生成規則Thread1 -> (A,B,D)を使用
上記から分かるように、いくつかの実施形態は、上向き構文解析によってスタックフレームを解析できる。上向き構文解析は、シフト還元構文解析または左から右への「ＬＲ」構文解析と同様であり得る。この解析には、木の葉から根に向かって解析を進めていくことによってスタックトレースの解析木を構成するために、スタックフレームおよびＳｅｇｍｅｎｔＩｎｆｏノードをシフト還元することが必要になり得る。いくつかの実施形態は、スレッドのスタックトレースの先の出現についての解析木を合成し、別の出現のスレッドのスタックトレースを、同じ解析木に還元する（すなわち、シフト還元構文解析、左から右に読む「ＬＲ」構文解析）ことによって解析する。分類木の各ノードは、スタックトレースのクラスのコンパクトラベルで有り得、分類木の根は、スレッドのクラスのコンパクトラベルで有り得る。

図７は、いくつかの実施形態に係る、スレッドダンプに応答して１つ以上のスレッド分類シグネチャを生成および／または変更するためのプロセスのフローチャート７００である。いくつかの実施形態では、フローチャート７００に示すプロセスは、１つ以上のプロセッサを有するコンピュータシステム（たとえば、図１７のコンピュータシステム１７００）によって実施されてもよい。１つ以上のプロセッサが、コンピュータ読み取り可能な媒体に格納されたコンピュータコードに基づいてステップを実行できる。図７に説明するステップは、その他のステップの有無を問わず、任意の順序で実行できる。

フローチャート７００は、ステップ７０２から始まる。ステップ７０２において、実施形態は、マルチスレッドプログラムの実行中にスレッドダンプを行う。具体的には、いくつかの実施形態は、マルチスレッドプログラムが動作するソフトウェア実行環境を監視する１つ以上の監視プロセスに対応してもよい。ソフトウェア実行環境は、当該マルチスレッドプログラムを含む複数のマルチスレッドプロセスをサポートしてもよい。場合によっては、ソフトウェア実行環境は、スレッドダンプの出力をサポートする仮想マシンであってもよい。いくつかの実施形態では、１つ以上の監視プロセスが、マルチスレッドプログラムと並んで仮想マシン内で動作してもよい。いくつかの実施形態では、１つ以上の監視プロセスは、仮想マシンとは別に、同じセットのマシン上でまたは異なるセットのマシン上で動作してもよい。１つ以上の監視プロセスは、仮想マシンのスレッドダンプを定期的に開始してもよい。特定のスレッドダンプについては、当該特定のスレッドダンプが出力される時にマルチスレッドプログラムに代わって（たとえば、当該マルチスレッドプログラムによって生成される）動作しているスレッドごとにスタックトレースが取得されてもよい。

ステップ７０４において、実施形態は、スレッドダンプ中に実行中であったスレッドごとにスタックトレースを受信する。特定のスレッドのスタックトレースは、スレッドのコールスタックを記述した１行以上のテキストに対応してもよい。スタックトレース内の各行は、スレッドのコールスタック上の特定のスタックフレームに対応し、当該スタックフレームに関するコードブロックを記述してもよい。いくつかの実施形態では、スタックフレームは、ソースコードファイルと、コードブロックを指し示す行番号と、コードブロックに関するクラス名および／またはメソッド名とを含んでもよい。

判断７０６において、実施形態は、別のスタックトレースを解析する必要があるかどうかを判断する。必要がない場合、フローチャートは、ステップ７１６で終了する。具体的には、スレッドダンプのスタックトレースのすべてが１つ以上の監視プロセスによって解析されると、いくつかの実施形態は、１つ以上のオブジェクトによってメモリにカプセル化された強度統計データを更新してもよい。たとえば、スレッドダンプからどのような種類のスタックトレースが得られたかに基づいて、１つ以上のＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのメンバ変数（たとえば、ｒａｗＭｅａｓｕｒｅ、ｒａｗＤｅｓｅａｓｏｎａｌｉｚｅｄＭｅａｓｕｒｅ、ｓｍｏｏｔｈｅｄＷｅｅｋｄａｙＳｅａｓｏｎａｌＦａｃｔｏｒ、および／またはｓｍｏｏｔｈｅｄＷｅｅｋｅｎｄＳｅａｓｏｎａｌＦａｃｔｏｒ）が更新されてもよい。

別のスタックトレースを解析する必要があるかどうかを判断する必要がある場合、ステップ７０８において、実施形態は、存在するトレースシグネチャが、スタックトレースが含むスタックフレームのシーケンスを表すかどうかを判断する。具体的には、いくつかの実施形態は、前のスレッドダンプから受信したスタックフレームに基づいて作成された分類シグネチャの存在するセットを生成文法として使用して、スタックフレームのシーケンスが存在するシグネチャのうちの１つによって表され得るかどうかを判断してもよい。これは、スタックトレースの一部が葉ＳｅｇｍｅｎｔＩｎｆｏノードに折り畳まれ、ＳｅｇｍｅｎｔＩｎｆｏノード自体は結合ノードに折り畳まれる、１つ以上のシフト還元動作を必要としてもよい。分類シグネチャとして登録される順序組がシフト還元動作によってできた場合、その分類シグネチャが、スタックトレースが含むスタックフレームのシーケンスを表す。

判断７１０において、このようなトレース（すなわち、分類）シグネチャが存在する場合、フローチャートは、ステップ７１４に進む。存在しない場合、ステップ７１２において、実施形態は、スタックトレースが含むスタックフレームのシーケンスを表す新しいトレースシグネチャを生成する。すなわち、線形接続されていると考えられていたスタックフレームのセット内に分岐点が発見される。次に、いくつかの実施形態は、１つ以上のＳｅｇｍｅｎｔＩｎｆｏノードを生成し、１つ以上の二分木を変更し、および／または１つ以上の順序組を変更して、スタックトレースが含む（前に）線形接続されたスタックフレームのセットを表す新しい分類シグネチャを生成してもよい。新しい分類シグネチャを生成する手法については、図８を参照して以下にさらに詳細に説明する。

ステップ７１４において、実施形態は、判断７０６に戻る前に、トレースシグネチャに関するカウンタをインクリメントする。具体的には、スタックトレース、スタックセグメント、およびスタックフレームが受信および発見されるときに、それらの数をその型によって追跡するために、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクト、ＳｅｇｍｅｎｔＩｎｆｏオブジェクト、および／またはＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトのメンバ（たとえば、ｎｕｍＯｆＯｃｃｕｒおよび／またはｔｏｔａｌＮｕｍＯｆＯｃｃｕｒ）である特定のカウンタがインクリメントされてもよい。

図８は、いくつかの実施形態に係る、分岐点を検出することに応答してスレッド分類シグネチャを生成または変更するためのプロセスのフローチャート８００である。いくつかの実施形態では、フローチャート８００に示すプロセスは、１つ以上のプロセッサを有するコンピュータシステム（たとえば、図１７のコンピュータシステム１７００）によって実施されてもよい。１つ以上のプロセッサが、コンピュータ読み取り可能な媒体に格納されたコンピュータコードに基づいてステップを実行できる。図８に説明するステップは、その他のステップの有無を問わず、任意の順序で実行できる。

フローチャート８００は、ステップ８０２から始まる。ステップ８０２において、実施形態は、１つ以上のＳｅｇｍｅｎｔＩｎｆｏノードが前に生成されているかどうかを判断する。生成されている場合、フローチャートは、ステップ８０４に進む。生成されていない場合、フローチャートは、ステップ８１４に進む。現在解析中のスタックトレースが、データセットについて受信された最初のスタックトレースでない限り、分類シグネチャのセットは、前のスタックトレースのために前に生成された、ＳｅｇｍｅｎｔＩｎｆｏノードを含む１つ以上の分類シグネチャを含んでいる可能性がある。同じプロセスから受信したスタックトレースの型はスタックセグメントを互いに共有している可能性があるので、初めて受信されたどの型のスタックトレースも、分岐点の発見につながる可能性がある。

ステップ８０４において、実施形態は、前に生成されたノードによって表されないスタックトレースが含むスタックフレームのシーケンスに含まれる１つ以上のスタックフレームのサブシーケンスを決定する。具体的には、いくつかの実施形態は、スタックトレースが含むスタックフレームのシーケンスを一連のシフト還元動作によって圧縮しようとしながら、存在する分類シグネチャおよびＳｅｇｍｅｎｔＩｎｆｏノードを調べてもよい。還元できないシーケンスのスタックフレームのサブシーケンスは、いずれも、新しい型のスタックセグメントであると判断されてもよい。この場合、いくつかの実施形態は、新しい型のスタックセグメントを表すＳｅｇｍｅｎｔＩｎｆｏノードが生成される必要があると判断してもよい。

ステップ８０６において、実施形態は、当該１つ以上のスタックフレームのサブシーケンスを表すための、１つ以上の追加ノードを生成してもよい。具体的には、新しい型のスタックセグメントに含まれるスタックフレームごとに新しいＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトが生成されてもよい。新しい型のスタックセグメントに対応する新しいＳｅｇｍｅｎｔＩｎｆｏノードが生成されてもよく、新しいＳｅｇｍｅｎｔＩｎｆｏノードは、新しいＳｔａｃｋＦｒａｍｅＩｎｆｏオブジェクトの各々を参照する。

ステップ８０８において、実施形態は、前に生成された１つ以上の組に含まれる、前に生成された１つ以上の二分木に、当該１つ以上の追加ノードのうちの少なくとも１つを合体させる。新しく発見された分岐点を考慮に入れるために、１つ以上の存在する分類シグネチャの１つ以上の二分木を変更および／または展開してもよい。存在する二分木の葉ＳｅｇｍｅｎｔＩｎｆｏノードによって表されるスタックセグメントが新しい分岐点によって分割される場合、その葉ノードは、２つの新しい葉ＳｅｇｍｅｎｔＩｎｆｏノードの結合ノードになってもよい。

ステップ８１０において、実施形態は、１つ以上の追加の二分木を生成する。１つ以上の二分木の少なくとも１つ以上は、１つ以上の追加のノードの少なくとも１つを含む。ほとんどの場合、１つ以上の追加の二分木は、１つのノードを有する単レベルの木であるだろう。新たに生成された二分木のうちの１つが、ステップ８０６において生成された新しいＳｅｇｍｅｎｔＩｎｆｏノードを含んでもよい。

ステップ８１２において、実施形態は、スタックトレースを表すための、当該１つ以上の追加の二分木を含む追加の組を生成する。この追加の組は、新たに発見された型のスタックトレースを表す分類シグネチャに対応してもよい。いくつかの組は、１つのノードを含み、かつ、ノードのリストに似た、単レベルの二分木の順序集合であってもよい。他の組は、１つの多レベルの二分木に対応してもよい。さらに別の組は、単レベルの二分木と多レベルの二分木との組合せを含んでもよい。一般に、より多くの型のスタックトレースが発見されるにつれ、生成される後続の分類シグネチャは、より長い順序組に対応し得る。しかしながら、共通型のスタックトレースのほうが最初に遭遇する可能性が高いので、長い分類シグネチャほど、あまり頻繁に発生しないスタックトレースを表す傾向にある。これによって、確実に、割合の高いスタックトレースほど、短い分類シグネチャに圧縮されることになるだろう。ステップ８１２の後、フローチャートは、ステップ８２０で終了する。

ステップ８１４において、実施形態は、スタックトレースを表すための、１つのノードを含む１つの二分木を含む組を生成する。ＳｅｇｍｅｎｔＩｎｆｏノードが見つからないため、現在解析中のスタックトレースが最初のＳｅｇｍｅｎｔＩｎｆｏノードであると思われる。その結果、いくつかの実施形態は、１つのＳｅｇｍｅｎｔＩｎｆｏノードしか有さない１つの二分木に対応する分類シグネチャを生成してもよい。ステップ８１４の後、フローチャートは、ステップ８２０で終了する。今後、異なる型のスタックトレースに遭遇すると、二分木は、新しく遭遇した分岐点を表すために、新しいＳｅｇｍｅｎｔＩｎｆｏノードを用いて展開されてもよい。

ＩＶ．ヒープ使用量の不規則な間隔での測定
いくつかの実施形態は、制御システムに時系列データのヒープ割当て（すなわち、ヒープ使用量）を監視させて、トレンドを推定したり、将来の仮想マシン内のメモリ使用量を予測したりしてもよい。季節トレンドを検出して記憶容量要件を予測することによって、いくつかの実施形態は、共有システムメモリを仮想マシン間で動的に再割り当てすることができ、リソース割り当てを柔軟にすることができる。容量要件の予測には、ヒープの増加率の推定が必要である場合がある。標本の正確さを確実にするために、フルガベージコレクション（ＧＣ）サイクルの間にヒープ割当てを測定してもよい。ＧＣサイクルは、不規則な間隔で発生する。ヒープ増加率の推定には、ランダム間隔による分割が必要である場合があり、断続的に気まぐれにゼロに近づく不規則な間隔により、複雑になっている。増加率の測定値におけるノイズは、コーシー分布をもたらす２つのガウス分布の割合であり、ガウス分布は、フィルタリングすることが難しい。多数のデータ点では、１つのデータ点よりも、平均および標準偏差を正確に推定できない、という意味では、コーシー分布の平均および標準偏差は未定義である。標本のプールが大きくなると、時間近接間隔による分割に対応する大きな絶対値を有する標本点に遭遇する可能性が上昇し得る。

なお、フルＧＣサイクルの不規則性によって標本抽出間隔が不規則であるヒープサイズの測定値とは異なり、スレッド強度測定値は、一定の間隔で標本抽出され、時間近接間隔を回避できる。たとえそうであっても、本明細書において説明するヒープ割当てをトレンド把握するための手法と同じ手法を、スレッド強度およびスタックセグメント強度の測定を季節トレンド把握および予測することに適用できる。いくつかの実施形態では、この手法は、スレッドのＣＰＵスケジューリングおよびフルＧＣサイクルの妨害による不定のレイテンシに合わせることができる。また、この手法は、スタックセグメントを分類するために必要な不定の計算時間による不定の標本抽出間隔にも合わせることができる。特定のスレッドまたはスタックセグメントがスレッドダンプにおいて観測されていない場合では、いくつかの実施形態は、関連するＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトまたは関連するＳｅｇｍｅｎｔＩｎｆｏオブジェクトのｎｕｍＯｆＯｃｃｕｒメンバ変数をゼロのままにしてもよい。ゼロは、特定のスレッドまたはスタックセグメントについての測定値が利用可能ではないことを示し得る。このような実施形態は、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのｒａｗＭｅａｓｕｒｅ変数を更新しなくてもよい。このような実施形態は、関連するＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトまたは関連するＳｅｇｍｅｎｔＩｎｆｏオブジェクトのｎｕｍＯｆＯｃｃｕｒメンバ変数がゼロではない場合にのみ、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトのｒａｗＭｅａｓｕｒｅメンバ変数を更新してもよい。このような実施形態は、ｒａｗＭｅａｓｕｒｅが最後に更新されてからスレッドダンプの数「Ｎ」を追跡してもよい。スレッド強度測定値は、不規則な間隔を有する時系列に対応してもよい。

１９５７年および１９６０年に発表されたホルト・ウィンタース３重指数フィルタは、季節トレンド把握および予測のために用いることができる。Ｃ．Ｃ．ホルト（Ｃ．Ｃ．Ｈｏｌｔ）による「Forecasting Trends and Seasonal by Exponentially Weighted Averages（指数移動平均によるトレンドおよび季節の予測）」（海軍研究事務所覚書、第５２号、１９５７年）が引用によって本明細書に援用される。Ｐ．Ｒ．ウィンタース（Ｐ．Ｒ．Ｗｉｎｔｅｒｓ）による「Forecasting Sales by Exponentially Weighted Moving Averages（指数加重移動平均による販売予測）」（ＭａｎａｇｅｍｅｎｔＳｃｉｅｎｃｅ第６巻、第３号３２４頁〜３４２頁、１９６０年）が引用によって本明細書に援用されている。ライト（Ｗｒｉｇｈｔ）は、不規則な間隔に対応するために１９８６年にホルト・ウィンタース法を拡張させた。Ｄ．Ｊ．ライト（Ｄ．Ｊ．Ｗｒｉｇｈｔ）による「Forecasting data published at irregular time intervals using an extension of Holt's method（ホルト法の拡張を用いた、不規則な時間間隔で公開されるデータの予測）」、（ＭａｎａｇｅｍｅｎｔＳｃｉｅｎｃｅ第３２巻、第４号４９９頁〜５１０頁、１９８６年）が引用によって本明細書に援用されている。２００８年に、ハンザック（Ｈａｎｚａｋ）が時間近接間隔の調整因子を提唱した。Ｔ．ハンザック（Ｔ．Ｈａｎｚａｋ）による「Improved Holt Method for Irregular Time Series（不規則な時系列のために改良されたホルト法）」（世界科学データシステム（ＷＤＳ）２００８年予稿集（ＷＤＳ’０８Ｐｒｏｃｅｅｄｉｎｇｓ）第１部、６２頁〜６７頁、２００８年）が引用によって本明細書に援用されている。

率推定におけるランダムな時間近接間隔によってさらに高くなったノイズの相対強度を補償する時間近接間隔の調整因子は、メモリリークまたはデッドロックによって生じた輻輳の間に時間間隔が単調に減少した場合、変化率の推定を誤って鈍らせてしまう可能性がある。フルＧＣアルゴリズムの非線形または多項式時間計算量によって、輻輳が酷くなるにつれて、スレッドのランタイム間隔が小さくなってしまう可能性がある。メモリリークの場合、時間間隔が短くなると、ランタイムが短くなり得るが、測定時間は長くなり得る。なぜならば、フルＧＣがより頻繁に実行されることによって、仮想マシンがより長い間フリーズし得るからである。フルＧＣの間に仮想マシンがフリーズした場合、新しいリクエストは、仮想マシン外部の待ち行列に入れられていく可能性がある。後続のランタイムの間、バックログがヒープ使用量の変化率を加速させる可能性がある。いくつかの実施形態では、ハンザックの時間近接間隔の調整因子がヒープ割当てのトレンド把握および予測のために用いられて、加速するヒープ増加率が追跡される。

本発明の実施形態では、ヒープ使用量の季節トレンド把握および予測にホルト・ウィンタース３重指数フィルタを適用して、柔軟なメモリ割り当てを効果的に実現することができる。規則的な時系列からの予測を要求するために適用され得る標準ホルト・ウィンタース３重指数フィルタは、不規則な時間近接間隔を有するランダム間隔で利用できるよう特別に調整することができる。本発明の実施形態は、不規則な間隔に対してライトの公式を適用し、ヒープ割当てのトレンド把握および予測のための時間近接間隔に対してハンザックの調整因子を適用することができる。フルＧＣによって生じた不規則な間隔に適したフィルタの構造の非自明な選択が行われ得る。ホルト・ウィンター・ライト・ハンザックフィルタの構造を第一原理から導出し、フルＧＣサイクルによって作り出された時系列に一致する適応を体系的に考案することができる。

いくつかの実施形態では、ヒープメモリ使用量およびスレッド強度などのリソース利用量の測定値を監視および予測するために、指数平滑移動平均線を求める式を当てはめて時系列データ、局所的な線形トレンド、季節トレンド、予測の誤差残差、および予測の絶対偏差を平滑化する。いくつかの実施形態では、この式は、１９５６年に提唱されたブラウンの指数フィルタと、１９５７年に提唱されたホルトの２重指数フィルタと、１９６０年に提唱されたウィンタースの３重指数フィルタと、１９８６年に提唱されたライトの不規則な間隔のための拡張と、２００８年に提唱されたハンザックの時間近接間隔の調整因子と、外れ値検出およびクリッピングとに基づき得る。下記の刊行物は、引用によって本明細書に援用されている。Ｒ．Ｇ．ブラウン（Ｒ．Ｇ．Ｂｒｏｗｎ）による「Exponential Smoothing for Predicting Demand（需要予測のための指数平滑法）」（ケンブリッジ、アーサー・Ｄ・リトル株式会社（Arthur D. Little Inc.）、１９５６年）、１５頁、Ｃ．Ｃ．ホルトによる「Forecasting Trends and Seasonal by Exponentially Weighted Averages（指数移動平均によるトレンドおよび季節の予測）」（海軍研究事務所覚書、第５２号、１９５７年）、Ｐ．Ｒ．ウィンタースによる「Forecasting Sales by Exponentially Weighted Moving Averages（指数加重移動平均による販売予測）」（ＭａｎａｇｅｍｅｎｔＳｃｉｅｎｃｅ第６巻、第３号３２４頁〜３４２頁、１９６０年）、Ｄ．Ｊ．ライトによる「Forecasting data published at irregular time intervals using an extension of Holt's method（ホルト法の拡張を用いた、不規則な時間間隔で公開されるデータの予測）」（ＭａｎａｇｅｍｅｎｔＳｃｉｅｎｃｅ第３２巻、第４号４９９頁〜５１０頁、１９８６年）、Ｔ．ハンザックによる「Improved Holt Method for Irregular Time Series（不規則な時系列のために改良されたホルト法）」（世界科学データシステム（ＷＤＳ）２００８年予稿集（ＷＤＳ’０８Ｐｒｏｃｅｅｄｉｎｇｓ）第１部、６２頁〜６７頁、２００８年）、Ｓ．マウン（Ｓ．Ｍａｕｎｇ）、Ｓ．Ｗ．バトラー（Ｓ．Ｗ．Ｂｕｔｌｅｒ）、およびＳ．Ａ．ヘンク（Ｓ．Ａ．Ｈｅｎｃｋ）による「Method and Apparatus for process Endpoint Prediction based on Actual Thickness Measurements（実際の厚み測定値に基づくエンドポイント予測を処理するための方法および装置）」（米国特許第５５０３７０７号、１９９６年）。

Ｖ．スレッド強度とヒープ使用量との相関付け
様々な実施形態は、マルチスレッドアプリケーションによって生成された様々なスレッドのクラスの強度統計データとヒープ使用量統計データとの間でトレンドを相関させることによってアプリケーション内のヒープをため込んでいるスタックトレース（すなわち、スレッドのクラス）を特定するための手法を提供する。そうすることで、いくつかの実施形態は、ヒープ使用量統計データに基づいて、１つ以上のマルチスレッドアプリケーションがソフトウェア実行環境内で実行中の期間内で、高いヒープ使用量が大きい傾向にある季節（すなわち、ヒープ使用量が高い季節）を特定してもよい。上に説明したように、次に、いくつかの実施形態は、ヒープ使用量が高い季節と同じ期間にソフトウェア実行環境から取得したスレッドダンプの解析によって、複数のスレッドのクラスの強度統計データを特定および収集してもよい。次に、いくつかの実施形態は、特定されたクラスのスレッドの強度統計データとヒープ使用量が高いトレンドとの相関度合いによってスレッドのクラスをランク付けすることによって、特定されたクラスのスレッドの中から「ヒープをため込んでいる」スレッドのクラス（すなわち、ヒープをため込んでいるスタックトレース）を特定してもよい。

いくつかの実施形態は、このようなスレッドのクラスを、ヒープをため込んでいると言ってもよい。なぜならば、このようなスレッドが実行しているコードは、ヒープメモリ使用量の点で非効率である確率が高いからである。言い換えると、これらのスレッドが実行する間違いの多いコードおよび／または最適化されていないコードは、スレッドが大量のヒープメモリをため込んでしまう原因となり得、ヒープ使用量が高いトレンドの大きな一因となる。

なお、このようなメモリホットスポットは、クラウドベースのサービスを本番環境で長い間動作させるという観点から、重要である。したがって、このようなホットスポットの連続検出および軽減を可能にすることによって、いくつかの実施形態は、クラウドサービスの作動効率に直接影響を与えてもよい。また、このような実施形態は、このようなアプリケーションをプロファイルするためにメモリプロファイラツールを使用することよりも有利であり得る。なぜならば、このようなツールは、アプリケーションに過度のオーバヘッドを加え得るからである。したがって、メモリプロファイラツールは、本番環境で実行中のアプリケーションを常時プロファイリングするには実用的ではないだろう。

Ａ．コードにおける非効率なヒープ使用量
非効率なメモリ使用の一般的な原因の１つは、スレッドのスタックフレームにおいて定義されたローカル変数によるものである。一般に、実行中のスレッドがオブジェクトをインスタンス化した場合、そのオブジェクトは、ヒープメモリを、オブジェクトを（直接または間接的に）参照するスタックフレームの数がヒープメモリが次のガベージコレクションにおいて解放されるゼロになるまで、占有する。したがって、長い間稼働したままであるスタックフレームから大きなオブジェクトを参照するローカル変数は、ヒープメモリ使用量の大きな一因に意図せずになってしまう可能性がある。なぜならば、このようなローカル変数は、オブジェクトをガベージコレクションさせないからである。

いくつかの実施形態は、総ヒープ使用量「Ｇ」バイトの端数「Ｐ」が、スレッドのクラス「Ｃ」に起因し得ると想定する。さらに、いくつかの実施形態は、このスレッドのクラス「Ｃ」間の平均ヒープ使用量（すなわち、スレッドあたりのヒープ使用量）が「М」バイトであると想定してもよい。この場合、「Ｔ_Ｃ」が、スレッドのクラス「Ｃ」の予想スレッド数を示すとする。下記の関係によって、「Ｔ_Ｃ」が得られる。「Ｔ_Ｃ」は、統計的モデルにおいてスレッド強度として定義される。

ヒープをため込んでいるスレッドのクラスを特定することに応答して、特定の実施形態は、開発者、パフォーマンスエンジニア、およびその他の関係者に当該スレッドのクラスを伝えてもよい（たとえば、通知またはアラートによって）。その結果、このような型のスレッドに関連するコードは、詳細なコードレビューおよびコードプロファイリングの対象になり得る。場合によっては、特定の関連するスタックフレームが検査され得る。たとえば、調査は、ヒープをため込んでいるスレッドのスタックトレースに含まれるスタックフレームを検査するために、ヒープ使用量が季節ピークに近いときの間にヒープダンプを出力することを必要としてもよい。このスタックフレームは、高いヒープ使用量の一因となっているオブジェクト（たとえば、大量のヒープメモリを占有するオブジェクト）を参照するローカル変数を含み得る。この種類のコード検査および最適化は、目視によるコードレビュー、自動コードレビュー、特定されたスレッドのプロファイリング、ＪＩＴ（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）コンパイラ最適化、動的バイトコード注入、またはこれらの手法の組合せによって行われる。いくつかの実施形態では、ヒープをため込んでいるスレッドのクラスがその他の自動コード最適化ツールに伝えられ、これらのツールのコード最適化機能が利用されてもよい。

いくつかの実施形態は、アプリケーションコードを自動的に設計し直すまたは書き換えて、アプリケーションコードのメモリ使用をより効率的なものにしてもよい。たとえば、いくつかの実施形態は、アプリケーションの挙動または正当性を変えないで、大きなオブジェクトをローカル変数がなるべく早く解放するように、コードを自動的に書き換えることができる。場合によっては、これは、ヒープをため込んでいるスレッドに含まれるコードパスの綿密な解析を必要としてもよい。

たとえば、下記のコードを考える。
fileOS.write(buffer.toString().getBytes());
いくつかの実施形態は、ヒープをため込んでいるスレッドのスタックフレームに含まれるローカル変数によってｂｕｆｆｅｒ、ｂｕｆｆｅｒ．ｔｏＳｔｒｉｎｇ（）、およびｂｕｆｆｅｒ．ｔｏＳｔｒｉｎｇ（）．ｇｅｔＢｙｔｅｓ（）という３つのオブジェクトが保持されているという理由で、上記コードがメモリ使用量に関して非効率であると判断され得る。具体的には、当該ローカル変数は、ファイルシステムコールにおいてスレッドがブロック状態である間にこれらの３つのオブジェクトがガベージコレクションされないようにする。

いくつかの実施形態は、ファイルシステムコールにおいてスレッドがブロック状態である間にｂｕｆｆｅｒおよびｂｕｆｆｅｒ．ｔｏＳｔｒｉｎｇ（）という少なくとも２つのオブジェクトがガベージコレクションされるように、コードを下記のように修正できる。

いくつかの実施形態は、中断を伴わない方法を用いて、ヒープをため込んでいるスタックトレースのスタックフレームを検査できる。

Ｂ．平日期間および週末期間の季節因子の初期化
ヒープをため込んでいるスタックトレースを特定するために、いくつかの実施形態は、（１）実行環境のヒープ使用量統計データの季節トレンドを推定することによってヒープ使用量が高い季節を特定し、（２）１つ以上のスレッドのクラスの各々について、スレッドのクラスのスレッド強度統計データの季節トレンドを推定してもよい。規則的間隔または不規則な間隔のヒープ使用量統計データの季節トレンドおよびスレッド強度統計データの季節トレンドを決定するためのいくつかの手法が、特許出願第１４／１０９，５７８号、第１４／１０９，５４６号、および第１４／７０５，３０４号に記載されている。これらの出願は、あらゆる目的のために、引用により本明細書に援用する。

統計データの季節トレンドを決定するために、この季節トレンドが対応付けられる期間および間隔が定義されてもよい。具体的には、１つの期間は複数の重複しない間隔に分割することができる。期間の各間隔は、１つの季節指数に関連付けられ得る。たとえば、期間が１日であり、間隔が１時間である場合、この期間を含むために２４個の季節指数があるはずである。別の例として、期間が１年であり、間隔が１月である場合、１２個の季節指数があるはずである。

いくつかの実施形態は、平日、週末、および祝祭日を別々の期間としてモデル化することができる。平日期間と週末期間とが分けられている場合、５つの連続した平日期間の後に１つの週末期間が処理されるように、５サイクルの平日期間に対して１サイクルの週末期間を交互配置することができる。したがって、当該連続した平日期間の頻度は、２４時間ごとに１つの平日期間であり、週末期間の頻度は、７日ごとに１つの週末期間である。個々の祝祭日（たとえば、クリスマス祭日および元日）が別々の期間としてモデル化される実施形態では、特定の祝祭日期間の頻度は、１年に１回である。

季節指数は、乗法季節因子、または、季節指数に関連付けられた間隔に適用される追加季節期間であり得る。たとえば、乗法季節因子を用いて季節指数を表す実施形態では、「午前９時〜午前１０時」という間隔が１．３という季節因子に関連付けられる場合、午前９時〜午前１０時という間隔の間に標本抽出された測定値は、いずれも３０％高くなるように調整される（すなわち、１．３を乗算される）。季節指数が追加季節期間によって表される実施形態では、追加季節期間が測定値に加えられる。

季節は、間隔のセットをある基準によって分類する。たとえば、１年という期間を考えると、１月、２月、３月、４月、５月、６月、７月、８月、９月、１０月、１１月、および１２月という１２個の間隔は、下記のように４つの北部気象季節に分類できる。

１２月、１月、および２月は、冬の季節として分類される。
３月、４月、および５月は、春の季節として分類される。

６月、７月、および８月は、夏の季節として分類される。
９月、１０月、および１１月は、秋の季節として分類される。

いくつかの実施形態は、平日期間を９６個の１５分間隔に分割してもよい。この点については、９６個の季節指数が導出される。ここで、９６個の平日季節指数（すなわち、平日因子）の各々は、９６個の平日間隔のうちの異なる１つに対応付けられる。同様に、いくつかの実施形態は、週末期間を１９２個の１５分間隔に分割してもよい。これによって、１９２個の季節指数が導出され、１９２個の週末季節指数（すなわち、週末因子）の各々は、１９２個の週末間隔のうちの異なる１つに対応付けられる。

平日期間の季節パターンと週末期間の季節パターンとを分けるために、特定の実施形態は、多期間トレンド把握フィルタを平日期間に適用することと、このようなフィルタを週末期間に適用することとを分けて行ってもよい。次に、いくつかの実施形態は、１という季節因子が平日期間および週末期間に共通の基準レベルを表すように、平日因子および週末因子をくりこんでもよい。その結果、１よりも大きい季節因子は、季節因子が適用される期間の間の、平均よりも高いヒープ使用量を表してもよい。一方では、１よりも小さい別の季節因子は、当該別の季節因子が適用される別の期間の間の、平均よりも低いヒープ使用量を表してもよい。

いくつかの実施形態では、多期間トレンド把握の手法を展開して、祝祭日（たとえば、労働者の日、クリスマス祭日、元日など）を別々の期間として分けることができる。ここで、祝祭日の期間は、１２か月に１回という頻度で繰り返す。一方では、平日期間は、２４時間に１回という頻度で繰り返し、週末期間は、７日に１回という頻度で繰り返す。このような実施形態では、１という季節因子が平日期間、週末期間、および祝祭日期間に共通の基準レベルを表すように、祝祭日期間の季節因子、平日期間の季節因子、および週末期間の季節因子のすべては、ともにくりこまれてもよい。

期間（たとえば、平日期間、週末期間、または祝祭日期間／１年という期間など）を考えると、Ｐが、所与の測定データセット（たとえば、特定の期間にまたがるヒープ使用量の測定値の時系列）に含まれる期間のサイクル数を示し、Ｋが、当該所与のデータセットに含まれる期間の数に含まれる間隔の数を示す。Ｌが１つの期間における季節指数の数を示す場合、Ｋ＝Ｐ×Ｌとなる。たとえば、データセット内に少なくとも３年分のデータがあり、１つの期間が１年に対応し、１つの間隔が１月に対応する場合、この期間のサイクルの数Ｐは、３つあり、月単位の間隔の数は、３６個ある。

具体的には、特定の間隔の季節因子は、データセット全体に対するその間隔の平均ヒープ使用量（データセット全体（たとえば、まる一週間にまたがるデータセット）におけるすべての同じ間隔（たとえば、すべての午前９時〜午前１０時の間隔）の平均ヒープ使用量、およびデータセット全体の期間の平均ヒープ使用量を平均することによって算出される。）の割合に等しくてもよい。

Ｃ．くりこみ
上述したように、いくつかの実施形態は、「１」という季節因子が平日期間および週末期間に共通の基準レベルを表すように、平日季節因子および週末季節因子をくりこんでもよい。

一般に、特定の実施形態は、すべての期間にわたる季節因子の加重平均を計算し、季節因子の各々を加重平均で除算することによってくりこみを行ってもよい。異なる長さの複数の期間の季節指数を必要とする下記の例を考える。ここで、各期間は、１５分間隔に分割されている。

平日の季節指数：Ｄ_ｉ、ｉ＝１_，２_，…９６
週末の季節指数：Ｅ_ｉ、ｉ＝１_，２_，…_，１９２
１０個の祝祭日の季節指数：Ｈ_ｋ，ｉ、ｉ＝１_，２_，…_，９６；ｋ＝１_，２_，…１０
特定の年において、２５３日の平日（祝祭日を除く）と、５０．５日の週末と、１０日の祝祭日があるとする。２５３＋５０．５×２＋１０＝３６４日である。この例において、いくつかの実施形態は、下記の式を用いて、季節因子の加重平均「Ａ」を算出してもよい。ここで、重みは、１年における各期間（たとえば、平日期間、週末期間、および１０個の祝祭日期間）のサイクルの数に比例する。

いくつかの実施形態は、各季節因子Ｄ_ｉ、Ｅ_ｉ、およびＨ_ｋ，ｉをＡで除算することによって、期間ごとの新しいくりこみ季節因子を導出できる。

平日季節因子および週末季節因子のくりこみの後、１という季節因子は、平日因子および週末因子に共通の基準レベルを表すはずである。

Ｄ．平滑化スプラインフィット
上述したように、いくつかの実施形態は、複数の期間にわたって平滑化スプラインをフィットさせて、１つの期間のサイクル間（たとえば、２つの平日期間の間）または２つの隣接する期間のサイクル間（たとえば、平日期間と週末との間）の遷移を平滑にしてもよい。具体的には、スプラインをフィットさせることには、１つ以上の期間の季節指数を連結してこれらの期間の間の遷移を円滑にすることが必要になり得る。

一般に、月曜日から火曜日、火曜日から水曜日、水曜日から木曜日、および木曜日から金曜日への遷移において平日サイクルを繰り返す時など、特定の実施形態（たとえば、フィルタ）が期間Ａ_ｉの１つサイクルの終わりに到達し、期間Ａ_ｉの新しいサイクルを開始する時、このような実施形態は、季節指数Ａ_ｉの３つのシーケンスを連結し、平滑化スプラインを全体シーケンスの端から端までフィットさせることができる。次に、いくつかの実施形態は、平滑化後のシーケンスの中間セグメントを取って、新しい平滑化後の季節指数Ａ_ｉを表してもよい。

金曜日から土曜日に遷移する時など、特定の実施形態（たとえば、フィルタ）が期間Ａ_ｉの１つのサイクルの終わりに到達し、隣接する期間Ｂ_ｉの新しいサイクルを開始する時、いくつかの実施形態は、季節指数Ａ_ｉの１つのシーケンスと、季節指数Ｂ_ｉの１シーケンスと、期間Ｂ_ｉに続く期間の季節指数Ｃ_ｉのシーケンスとを連結して、平滑化スプラインを全体シーケンスの端から端までフィットさせてもよい。次に、いくつかの実施形態は、平滑化後のシーケンスの中間セグメントを取って、新しい平滑化後の季節指数Ｂ_ｉを表してもよい。また、いくつかの実施形態は、平滑化後のシーケンスの第１セグメントを取って、平滑化後の季節指数Ａ_ｉを表してもよい。

日曜日から月曜日に遷移する時など、特定の実施形態（たとえば、フィルタ）が期間Ｂ_ｉの１つのサイクルの終わりに到達し、隣接する期間Ｃ_ｉの新しいサイクルを開始するとき、いくつかの実施形態は、期間Ｂ_ｉに先行する期間の季節指数Ａ_ｉの１つのシーケンスと、季節指数Ｂ_ｉの１つのシーケンスと、季節指数Ｃ_ｉの１つのシーケンスとを連結して、平滑化スプラインを全体シーケンスの端から端までフィットさせることができる。次に、いくつかの実施形態は、平滑化後のシーケンスの中間セグメントを取って、新しい平滑化後の季節指数Ｂ_ｉを表してもよい。また、いくつかの実施形態は、平滑化後のシーケンスの第３セグメントを取って、新しい平滑化後の季節指数Ｃ_ｉを表してもよい。

クラウドサービスに関して、週末および祝祭日の間の負荷サイクルは、平日の間の負荷サイクルとは異なる場合が多い。従来の季節トレンド把握による解決法では、通常、季節指数の１つの期間だけが表されるだろう。週末の季節指数を通常の平日の季節指数と分けるために、このような従来の解決法は、期間の範囲をまる１週間、または、まる１か月に延ばすことに応じて異なるだろう。これに加えて、このような従来の解決法は、祝祭日を別々に扱うだろう。

ヒープをため込んでいるスタックトレースを特定するためのステップに戻ると、平日季節因子を平滑化するために、いくつかの実施形態は、平日因子の３つのシーケンスを連結することによって、季節因子の配列を構成することができる。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、当該配列を生成してもよい。

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、０．３という平滑化パラメータを用いてＲ言語のｓｍｏｏｔｈ．ｓｐｌｉｎｅ関数を呼び出して、当該因子を平滑化してもよい。

extendedWeekdayIndices <- 1:(3 * 96)
f <- smooth.spline(extendedWeekdayIndices, factors, spar = 0.3)
次に、いくつかの実施形態は、配列内の中間シーケンス（すなわち、中間の９６個の平日因子）を、平滑化後の平日因子として指定してもよい。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、当該平滑化後の平日因子を取得してもよい。

sandwichWeekdayIndices <- (96 + 1):(96 * 2)
smoothedWeekdaySeasonalFactor <- predict(f, sandwichWeekdayIndices)$y
平日因子を平滑化する方法と同様のやり方で、いくつかの実施形態は、スプラインを適用して週末因子を平滑化してもよい。具体的には、いくつかの実施形態は、平日因子の２つのシーケンスの間に週末因子のシーケンスを連結することによって、季節因子の配列を構成することができる。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、この配列を生成してもよい。

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekendSeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子と週末因子との配列を平滑化してもよい。たとえば、いくつかの実施形態は、０．３という平滑化パラメータを用いてＲ言語のｓｍｏｏｔｈ．ｓｐｌｉｎｅ関数を呼び出して、これらの因子を平滑化してもよい。

extendedWeekendIndices <- 1:(2 * 96 + 192)
f <- smooth.spline(extendedWeekendIndices, factors, spar = 0.3)
次に、いくつかの実施形態は、配列内の中間シーケンス（すなわち、週末因子である、配列内の中間の１９２個の季節因子）を、平滑化後の週末因子として指定してもよい。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、平滑化後の週末因子を取得してもよい。

sandwichWeekendIndices <- (96 + 1):(96 + 192)
smoothedWeekendSeasonalFactor <- predict(f, sandwichWeekendIndices)$y
なお、いくつかの実施形態は、平日の間に観測された季節パターンを週末の間に観測された季節パターンから切り離すために、９６個の平日季節指数と１９２個の週末季節指数とを別々に表してもよい。いくつかの実施形態では、ヒープ使用量統計データの時系列を逐次フィルタリングするには、ヒープ使用量の測定値のための指数フィルタと、季節因子のための指数フィルタと、線形トレンドのための指数フィルタと、加速トレンドのための指数フィルタと、残差のための指数フィルタとを含む、指数フィルタの５つのセットが必要になり得る。

上述したように、標本の正確さを確実にするために、不規則な間隔で発生するフルガベージコレクション（ＧＣ）サイクルの間に、ヒープ割当てが測定されてもよい。ヒープ使用量が特に高い状況では、絶え間ないガベージコレクションにより、標本抽出間隔は、気まぐれにゼロに近くなってしまうだろう。予測には変化率の推定が必要であるので、この不規則な間隔が気まぐれにゼロに近づくと、変化率は、平均および標準偏差が未定義であるコーシー分布の確率変数になる可能性がある。したがって、いくつかの実施形態は、ホルトの２重指数フィルタ、ウィンタースの３重指数フィルタ、ライトの不規則な間隔のための拡張、ハンザックの時間近接間隔の調整因子、外れ値の検出および外れ値のカットオフの適応型スケーリングの適応を伴うクリッピングを採用して、フルＧＣに関連付けて決定された統計データの季節トレンドを決定するためにコーシー分布問題を克服してもよい。いくつかの実施形態では、この指数フィルタの５つのセットを時系列に対して逐次適用して、平日因子および週末因子を推定することができる。

各期間の終わりの後、いくつかの実施形態は、スプラインを適用して季節因子を平滑化してもよい。たとえば、別の平日期間に先行する平日期間の終わりに到達（すなわち、月曜日から火曜日に、火曜日から水曜日に、水曜日から木曜日に、または木曜日から金曜日に遷移）した場合、いくつかの実施形態は、平日因子の３つのシーケンスを連結することによって、季節因子の配列を構成することができる。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、当該配列を生成してもよい。

sandwichWeekdayIndices <- (96 + 1):(96 * 2)
smoothedWeekdaySeasonalFactor <- predict(f, sandwichWeekdayIndices)$y
別の場合では、週末期間に先行する平日期間の終わりに到達（すなわち、金曜日から土曜日に遷移）した場合、いくつかの実施形態は、週末季節因子のシーケンスを平日季節因子の２つのシーケンスの間に連結することによって、季節因子の配列を構成できる。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、当該配列を生成してもよい。

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekendSeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子および週末因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、０．３という平滑化パラメータを用いてＲ言語のｓｍｏｏｔｈ．ｓｐｌｉｎｅ関数を呼び出して、当該因子を平滑化してもよい。

extendedWeekendIndices <- 1:(2 * 96 + 192)
f <- smooth.spline(extendedWeekendIndices, factors, spar = 0.3)
次に、いくつかの実施形態は、配列内の左側シーケンス（すなわち、平日因子である、配列内の最初の９６個の季節因子）を、平滑化後の平日因子として指定してもよい。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、平滑化後の平日因子を取得してもよい。

leftsideWeekendIndices <- 1:96
smoothedWeekdaySeasonalFactor <- predict(f, leftsideWeekendIndices)$y
別の場合では、週末期間の終わりに到達（すなわち、日曜日から月曜日に遷移）した場合、いくつかの実施形態は、週末季節因子のシーケンスを平日季節因子の２つのシーケンスの間に連結することによって、季節因子の配列を構成することができる。たとえば、いくつかの実施形態下記のＲプログラミング言語のコードを実行することによって、当該配列を生成してもよい。

sandwichWeekendIndices <- (96 + 1):(96 + 192)
smoothedWeekendSeasonalFactor <- predict(f, sandwichWeekendIndices)$y
また、いくつかの実施形態は、配列内の右側シーケンス（すなわち、平日因子である、配列内の最後の９６個の季節因子）を、平滑化後の平日因子として指定してもよい。たとえば、いくつかの実施形態は、下記のＲプログラミング言語のコードを実行することによって、平滑化後の平日因子を取得してもよい。

rightsideWeekendIndices <- (96 + 192+ 1):( 2 * 96 + 192)
smoothedWeekdaySeasonalFactor <- predict(f, rightsideWeekendIndices)$y
なお、いくつかの実施形態は、シーケンシャルフィルタが（１）期間の１つのサイクルの終わりに到達して、同じ期間の新しいサイクルを開始する（たとえば、シーケンシャルフィルタが月曜日の終わりに到達する）、または、（２）期間の１つのサイクルの終わりに到達して、隣接する期間の新しいサイクルを開始する（たとえば、シーケンシャルフィルタが金曜日の終わりに到達する）たびに、上述のくりこみおよび平滑化スプラインフィットを実行してもよい。

Ｅ．季節サイクルの検定
いくつかの実施形態は、データセットの１つ以上の候補期間に季節サイクルが存在するかどうかを検定して、この期間の季節指数の別のシーケンスが表されるべきかどうかを判断できる。一般に、データセットが特定の期間の季節サイクルを示しているかどうかを判断するために、いくつかの実施形態は、下記のステップを実行してもよい。

Ｑが１つの期間における季節指数の数を示し、Ｐが１つの期間にあるサイクルの数を示し、Ｋが１つの期間のサイクル中にある間隔の数を示し、Ｋ＝Ｐ×Ｑが成り立つとする。

いくつかの実施形態は、１つの期間のサイクルの各間隔における平均測定値を算出できる。そうするために、いくつかの実施形態は、これらの間隔を０から（Ｋ−１）まで列挙し、以下の式を用いて、期間の各間隔の平均測定値を算出してもよい。

次に、いくつかの実施形態は、この期間の各サイクルの平均測定値を算出できる。そうするために、いくつかの実施形態は、この期間のサイクルを０から（Ｐ−１）まで列挙し、以下の式を用いて、期間の各サイクルの平均測定値を算出してもよい。

次に、いくつかの実施形態は、帰無仮説検定を適用して、期間に季節サイクルが存在するかどうかを見つけることができる。この点については、検定される帰無仮説は、直近のサイクル「ｕ」の季節指数と先行のサイクル「ｖ」の季節指数との間の相関係数ｒ_ｕ，_ｖがゼロであるという想定に対応してもよい。具体的には、いくつかの実施形態は、下記の式を用いて、相関係数ｒ_ｕ，_ｖを決定してもよい。

いくつかの実施形態は、様々な手法を採用して、相関係数ｒ_ｕ，_ｖがサイクル「ｕ」と「ｖ」との間に共通の季節サイクルがあることを、有意水準を上回って示すのに十分な大きさであるかどうかを判断してもよい。たとえば、いくつかの実施形態は、スチューデントのｔ検定、順列検定、またはフィッシャー変換を採用してもよい。

仮説を検定するために、いくつかの実施形態は、１つ以上の検定統計量を定義してもよい。検定統計量は、パラメータを変数とする関数であってもよい。この場合、相関係数ｒ_ｕ，_ｖが検定される。下記の検定統計量ｔは、自由度が「ｎ−２」のスチューデントのｔ分布を有し、ｒ_ｕ，_ｖを変数とする関数である。いくつかの実施形態は、帰無仮説ｒ_ｕ，_ｖ＝０を定義する。これは、１つの期間のサイクル間で季節指数が相関関係にないことを想定する。いくつかの実施形態は、対立仮説を受け入れることによって、帰無仮説（すなわち、ｒ_ｕ，_ｖ＝０）を棄却するための証拠を探してもよい。

Ｆ（ｔ）が、確率分布を示すとする。有意水準が０．１であるとすると、Ｆ（ｔ）＝０．９が成り立つような確率変数ｔの値をｔ_{０．９，（ｎ−２）}が示すとする。対立仮説は、偏った条件である。

この条件が真である場合、対立仮説は採択される。これは、年のサイクル「ｕ」と「ｖ」との間に共通の季節サイクルがあることを示す。直近のサイクルとそれより前のサイクルとの間に共通する季節サイクルがある場合、いくつかの実施形態は、サイクルの季節指数ごとの季節因子の計算に取りかかってもよい。いくつかの実施形態は、上記式を適用して、後述するように、ソフトウェア実行環境によるヒープ使用量の年間季節サイクルの存在を検出してもよい。

Ｆ．ヒープ使用量の年間季節サイクルの検出
ソフトウェア実行環境の複数年のヒープ使用量統計データを解析する際、いくつかの実施形態は、それぞれ異なる時間尺度で２つ以上の季節トレンドを検出してもよい。たとえば、このような実施形態は、ヒープ使用量統計データの複数年分の時系列、年ごとの季節トレンド、および１日の季節トレンドを検出してもよい。１年の季節トレンド、および１日の季節トレンドは、多季節トレンドに重ねられる。したがって、いくつかの実施形態は、１年の季節トレンドを解析するために適切な時間尺度を取り入れてもよい。この時間尺度は、１年に対応する期間と、１か月に対応する間隔とを有する。このように、１年という期間が１２個の１か月という長さの間隔に分割されてもよい。

データセットが年間季節サイクルを示すかどうかを判断するために、いくつかの実施形態は、まず、データセットに含まれる月次指数の乗法因子を決定してもよい。

具体的な場合では、Ｐが、データセットにある年の数（すなわち、１年間のサイクル数）を示すとする。これに加えて、Ｑが、データセットにある月の数（すなわち、サイクル数内の間隔の数）を示すとする。したがって、Ｑ＝１２×Ｐが成り立つ。Ｋが、データセットにある平日または週末の数を示すとする。これらの平日または週末の列挙を表すために、指数ｋの範囲は、０から（Ｋ−１）までとする。Ｎ_ｋがｋ番目の平日または週末における標本の数を示すとする。下記の式を用いて、いくつかの実施形態は、下記の式を適用して、データセットに含まれる各平日または週末の平均ヒープ使用量を算出できる。

いくつかの実施形態は、関数Ｈを次のように定義できる。Ｈ：（年×整数）→指数。これは、年の指数と、その年のある平日または週末の指数に対応する整数とを含む順次対を対応付ける。下記の式を用いて、次に、いくつかの実施形態は、毎年の平均ヒープ使用量を、その年の平日または週末の平均ヒープ使用量から算出してもよい。

いくつかの実施形態は、関数Ｇを次のように定義できる。Ｇ：（月×整数）→指数。これは、月の指数と、その月のある平日または週末の指数に対応する整数とを含む順次対を対応付ける。下記の式を用いて、いくつかの実施形態は、期間の各月間隔の平均ヒープ使用量を、その月の平日または週末の平均ヒープ使用量から算出してもよい。

月次指数の乗法因子を判断した後、いくつかの実施形態は、帰無仮説検定を適用して、年間季節サイクルがあるかどうかを見つけることができる。この点については、検定される帰無仮説は、直近の年「ｕ」の月次指数とその前の年「ｖ」の月次指数との間の相関係数ｒ_ｕ，_ｖがゼロであるという想定に対応してもよい。具体的には、いくつかの実施形態は、下記の式を用いて、相関係数ｒ_ｕ，_ｖを決定してもよい。

いくつかの実施形態は、様々な手法を採用して、相関係数ｒ_ｕ，_ｖが年「ｕ」と「ｖ」との間に共通の季節サイクルがあることを、有意水準を上回って示すのに十分な大きさであるかどうかを判断してもよい。たとえば、いくつかの実施形態は、スチューデントのｔ検定、順列検定、またはフィッシャー変換を採用してもよい。

帰無仮説が真（すなわち、ｒ_ｕ，_ｖ＝０）である場合、下記の検定統計量ｔは、自由度が「ｎ−２」のスチューデントのｔ分布を有する。

対立仮説を採択する条件では、年「ｕ」と「ｖ」との間に共通の季節サイクルがあることが示される。

Ｇ．年間ヒープ使用量が高い季節の決定
直近の年とそれより前の年との間に共通の季節サイクルがあると判断された場合、いくつかの実施形態は、下記の式を採用することによって、月次季節指数０〜１１によって列挙された月ごとの季節因子を計算できる。

なお、上記再帰法には、未束縛変数ｓが必要である。未束縛変数ｓは、繋がりを断つために使用され得る。いくつかの実施形態では、デフォルトで、ｓ＝１である。

特定の実施形態では、季節指数の閉包Ｖは、年間ヒープ使用量が高い季節を分類する。閾値Ｔは、季節因子の範囲の８５パーセントなど、パーセントに設定され得る。たとえば、１年という期間における１２個の月々の季節指数の季節因子は、下記の表の通りであるとする。

乗法季節因子の範囲は、（１．３４−０．７６）であり、０．５８である。したがって、季節因子の範囲の８５パーセントは、（０．７６＋０．８５×０．５８）であり、１．２５３である。この８５パーセントを閾値Ｔに与えると、Ｔ＝１．２５である。その結果、このような実施形態は、５月、６月、および７月を、年間ヒープ使用量が高い季節として分類するだろう。

いくつかの実施形態は、１年という期間の直近のサイクルにまたがるデータセットのセグメントを選択できる。たとえば、２０１３年、２０１４年、２０１５年、および２０１６年というサイクルの中から、このような実施形態は、２０１５年〜２０１６年を含んだデータのセグメントを選択してもよい。選択されたデータセグメントは、年間ヒープ使用量が高い季節内の２週間分以上のヒープ使用量統計データにまたがり得る。たとえば、季節因子が下記の表の通りである場合、データセグメントは、２０１５年１１月、２０１５年１２月、および２０１６年１月から選択することができる。

Ｈ．フィルタ定数および時間帯オフセットを求めるための回帰
いくつかの実施形態は、時間帯オフセットの推定を含めることができる。時間帯オフセットが利用できない場合、いくつかの実施形態は、データセットのセグメントに対して非線形回帰を行って時間帯オフセットを推定し、この時間帯オフセットを用いてデータをフィルタリングすることができる。時間帯オフセットの推定を提供することによって、いくつかの実施形態は、期間の間の遷移における季節指数の推定を向上させることができる。

具体的には、いくつかの実施形態は、ｍｅａｓｕｒｅＦｉｌｔｅｒＣｏｎｓｔａｎｔ α、ｒａｔｅＦｉｌｔｅｒＣｏｎｓｔａｎｔ β、ａｃｃｅｌｅｒａｔｉｏｎＦｉｌｔｅｒＣｏｎｓｔａｎｔ κ、ｓｅａｓｏｎａｌＦａｃｔｏｒＦｉｌｔｅｒＣｏｎｓｔａｎｔ γ、ｅｒｒｏｒＲｅｓｉｄｕａｌＦｉｌｔｅｒＣｏｎｓｔａｎｔ δ、およびｔｉｍｅＺｏｎｅＯｆｆｓｅｔｔｚというフィルタ定数（すなわち、独立変数である回帰パラメータ）を用いて非線形回帰を行い、１ステップ予測の残差の平均二乗誤差（ＭＳＥ）および／または平均絶対偏差（ＭＡＤ）を最小化できる。いくつかの実施形態では、タイムスタンプは、回帰において、時間帯オフセットｔｚだけずらされてもよい。いくつかの実施形態は、最適化ルーチン（たとえば、Ｒプログラミング言語が提供する最適ルーチン）を用いて、非線形多変量回帰を適用してもよい。いくつかの実施形態は、このような実施形態が採用する下記の式に示すα、β、κ、γ、δ、およびｔｚの最適値を用いて、平日季節因子および週末季節因子を導出してもよい。

いくつかの実施形態は、期間のサイクル間または２つの隣接する期間の間の遷移ができるだけ正確になるように、時間帯オフセットを回帰パラメータとして含む。

Ｉ．相関度合いによるスレッドのクラスのランク付け
年間ヒープ使用量が高い季節が決定されると、いくつかの実施形態は、最近（たとえば、直近）の年間ヒープ使用量が高い季節に含まれる日ごと／週ごとの季節サイクルを表す平日因子／週末因子を算出および／または取得してもよい。なお、データセットのこのセグメントにおける（すなわち、年間ヒープ使用量が高い季節の間の）日ごと／週ごとの季節サイクルは、ほか（すなわち、年間ヒープ使用量が高い季節以外）の時よりも顕著であるだろう。したがって、１つ以上のスレッドのクラスのヒープ使用量における季節トレンドと強度統計データにおける季節トレンドとの相関度合いの判断は、データセットのこのセグメントに基づき得る。言い換えると、相関分析のために、いくつかの実施形態は、直近の年間ヒープ使用量が高い季節に含まれる間隔と同じ間隔を用いて、様々なスレッドのクラスの季節トレンドを導出できる。

なお、特定のスレッドのクラスの強度統計データの季節トレンドを決定するために、いくつかの実施形態は、上述したような、ヒープ使用量における季節トレンドを決定するために使用された手法を採用してもよい。すなわち、スレッド強度統計データおよびヒープ使用量統計データの季節トレンド把握には、平日期間および週末期間に同じ数の季節指数（たとえば、１つの平日期間に対して９６個の季節指数、１つの週末期間に対して１９２個の季節指数）を使用することが必要になってもよい。

１つ以上のスレッドのクラスのヒープ使用量の季節トレンドおよび強度統計データの季節トレンドが決定されると、次に、いくつかの実施形態は、１つ以上のスレッドのクラスの各々について、スレッドのクラスのヒープ使用量の季節トレンドと強度統計データの季節トレンドとの相関度合いを計算してもよい。具体的には、９６個の季節因子または１９２個の季節因子のシーケンスについての相関度合いが計算されてもよい。なお、季節トレンド間の相関度合いを計算することは、ヒープ使用量測定値のシーケンスとスレッド強度測定値のシーケンスとの相関度合いを計算することよりも効率的であろう。なぜならば、測定値のシーケンスの方がかなり長いと思われるからである。

Ｈが、ヒープ使用量のＮ個の季節因子のシーケンスを示すとする。Ｔが、スレッドのクラスのスレッド強度のＮ個の季節因子のシーケンスを示すとする。季節因子のこの２つのシーケンスの相関係数は、下記に定義する相関係数（Ｈ，Ｔ）によって得られる。

いくつかの実施形態は、直近の年間ヒープ使用量が高い季節に含まれるヒープ使用量統計データの回帰を実施することによって、ヒープ使用量の平日季節因子および週末季節因子を導出してもよい。データセットのこのセグメントの時間間隔を、（ｔ１，ｔ２）で示す。スレッドのクラスの強度統計データの季節因子とヒープ使用量の季節因子との相関を解析するために、いくつかの実施形態は、スレッドのクラスに関連するＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏに含まれる季節因子時系列における同じ時間間隔（ｔ１，ｔ２）から、季節因子を得ることができる。具体的には、季節因子時系列は、関連するＳｅａｓｏｎａｌＴｒｅｎｄｉｎｇＩｎｆｏオブジェクトに含まれるｓｍｏｏｔｈｅｄＷｅｅｋｄａｙＳｅａｓｏｎａｌＦａｃｔｏｒメンバ変数およびｓｍｏｏｔｈｅｄＷｅｅｋｅｎｄＳｅａｓｏｎａｌＦａｃｔｏｒメンバ変数に格納され得る。

いくつかの実施形態は、スレッドのクラスのすべてのＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトを反復し、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトの各々に含まれるＳｅｇｍｅｎｔＩｎｆｏオブジェクトを再帰的に横断して、ＴｈｒｅａｄＣｌａｓｓｉｆｉｃａｔｉｏｎＩｎｆｏオブジェクトおよびＳｅｇｍｅｎｔＩｎｆｏオブジェクト内に含まれるＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトを収集できる。上記の式を用いてスレッドのクラスの各々とヒープ使用量との相関係数（Ｈ，Ｔ）を計算する際、いくつかの実施形態は、ＳｅａｓｏｎａｌＴｒｅｎｄＩｎｆｏオブジェクトの各々に含まれる平日因子または週末因子を取り出すことができる。スレッドのクラスごとの相関度合いが算出されると、いくつかの実施形態は、スレッドのクラスをヒープ使用量季節トレンドとの相関度合いによってランク付けしてもよい。次に、最高位にランク付けされたスレッドのクラスが、ヒープをため込んでいるスレッドのクラスとして分類されてもよい。次に、いくつかの実施形態は、ヒープをため込んでいるスレッドのクラスに関連するコードおよびスタックトレースを解析して、手動または自動で修正および／または向上させることがきる非効率なメモリ使用量を特定してもよい。

なお、いくつかの実施形態を拡張して、平日期間および週末期間以外の期間（たとえば、四半期末の期間）に基づいて相関係数を決定することができる。

図９は、いくつかの実施形態に係る、ソフトウェア実行環境内の高いヒープ使用量の一因となっていると思われるコードを特定するためのプロセスのフローチャート９００である。いくつかの実施形態では、フローチャート９００に示すプロセスは、１つ以上のプロセッサを有するコンピュータシステム（たとえば、図１７のコンピュータシステム１７００）によって実施されてもよい。１つ以上のプロセッサが、コンピュータ読み取り可能な媒体に格納されたコンピュータコードに基づいてステップを実行できる。図９に説明するステップは、その他のステップの有無を問わず、任意の順序で実行できる。

フローチャート９００は、ステップ９０２から始まる。ステップ９０２において、実施形態は、１つ以上のプロセスによるヒープ使用量が閾値を上回っている時間の長さを判断する。当該時間の長さは、年間ヒープ使用量が高い季節に対応してもよく、閾値は、１つ以上の期間（たとえば、平日期間および週末期間）全体に対する、間隔（たとえば、１５分間隔）に割り当てられた季節因子の範囲の割合に対応してもよい。いくつかの実施形態では、閾値は、割合を選ぶことによって設定され得る。割合が選ばれると、閾値は、季節因子の範囲と割合との積と最小季節因子の和によって表されてもよい。たとえば、選んだ割合が８５パーセントであり、最小季節因子が０．７６であり、最大季節因子が１．３４である場合、閾値は、（０．７６＋０．８５×（１．３４−０．７６））によって表され得、１．２５３である。その結果、１．２５を上回る乗法季節因子を有する間隔はいずれも、ヒープ使用量が閾値を上回っている時間の長さの一部であると判断されるだろう。

ステップ９０４において、実施形態は、当該時間の長さの間の１つ以上のプロセスのヒープ情報を決定する。ヒープ情報は、この時間の長さの間の異なる時点においてソフトウェア実行環境内で１つ以上のプロセスが使用しているヒープメモリの量に対応してもよい。たとえば、ヒープ情報は、不規則な間隔（たとえば、フルＧＣの間）でソフトウェア実行環境から得られるヒープ使用量の測定値に基づいてもよい。これに加えて、ソフトウェア実行環境は、１台以上の仮想マシン（たとえば、ＪＶＭ）を含む本番環境に対応してもよく、１つ以上のプロセスは、１つ以上のクラウドサービスをサポートし得る。

ステップ９０６において、実施形態は、当該時間の長さの間の１つ以上のプロセスのスレッド情報を決定する。いくつかの実施形態では、スレッド情報は、解析されたスレッドダンプから判断された１つ以上のスレッドのクラスの各々について、複数の間隔の各々のスレッド強度季節因子を含んでもよい。

いくつかの実施形態では、ヒープ情報は、複数の間隔の各々のヒープ使用量季節因子を含んでもよい。具体的には、この時間の長さは、第１長さを有する第１期間（たとえば、平日期間）の１つ以上のサイクルと、第２長さを有する第２期間（たとえば、週末期間）の１つ以上のサイクルとをまたがってもよい。各期間は、複数の間隔に分割されてもよい。たとえば、平日期間は、９６個の１５分間隔に分割されてもよく、週末期間は、１９２個の１５分間隔に分割されてもよい。

なお、複数の間隔の各々は、期間のうちの１つの期間の特定の季節（すなわち、季節指数）に対応付けられてもよい。季節指数ごとに、いくつかの実施形態は、ヒープ使用量季節因子を決定し、特定されたスレッドのクラスごとに、スレッド強度季節因子を決定してもよい。これによって、各間隔は、１つのヒープ使用量季節因子と複数のスレッド強度季節因子（スレッドのクラスごとに１つ）とに関連付けられる。たとえば、３つの異なるスレッドのクラスが発見されたと想定すると、９６個のヒープ使用量季節因子と２８８個のスレッド強度季節因子（３つのスレッドのクラスの各々について９６個のスレッド強度季節因子）とを平日期間が有してもよく、週末期間は、１９２個のヒープ使用量季節因子と５７６個のスレッド強度季節因子とを有してもよい。

ステップ９０８において、実施形態は、ヒープ情報をスレッド情報と相関させて、閾値を上回るヒープ使用量に対応する１つ以上のプロセスの１行以上のコードを特定する。ヒープ情報をスレッド情報と相関させるステップについては、図１０を参照して以下にさらに詳細に説明する。

ステップ９１０において、１行以上のコードを特定することに応答して、実施形態は、当該１行以上のコードに関連する１つ以上のアクションを開始する。たとえば、実施形態は、関係者またはコード最適化ツールに送られる、１行以上のコードに関連するアラートを生成してもよい。これに応答して、特定されたコードの行は、調査および／または最適化されてもよい。これに代えて、いくつかの実施形態は、この１行以上のコードを最適化して、ヒープメモリをより効率良く利用してもよい。

図１０は、いくつかの実施形態に係る、様々なスレッドのクラスと高いヒープ使用量との相関度合いを算出するためのプロセスのフローチャート１０００である。いくつかの実施形態では、フローチャート１０００に示すプロセスは、１つ以上のプロセッサを有するコンピュータシステム（たとえば、図１７のコンピュータシステム１７００）によって実施されてもよい。１つ以上のプロセッサが、コンピュータ読み取り可能な媒体に格納されたコンピュータコードに基づいてステップを実行できる。図１０に説明するステップは、その他のステップの有無を問わず、任意の順序で実行できる。

フローチャート１０００は、ステップ１００２から始まる。ステップ１００２において、実施形態は、１つ以上のプロセスの１つ以上のスレッドダンプを取得する。上述したように、制御システムが、定期的に、ソフトウェア実行環境に、ソフトウェア実行環境内で実行中の１つ以上のプロセスが生成したスレッドの１つ以上のスタックトレースを含むスレッドダンプを出力させてもよい。

ステップ１００４において、実施形態は、１つ以上のスレッドダンプから１つ以上のスレッドを受信し、受信したスレッドに対応するスタックトレースに基づいて当該受信したスレッドの各々を分類することによって、１つ以上のスレッドのクラスを取得する。スレッドダンプのすべてが受信されて処理されると、実施形態は、ステップ１００６〜ステップ１０１６において１つ以上のスレッドのクラスの各々を解析してスレッドのクラスの各々と高いヒープ使用量との相関度合いを判定してもよい。

判断１００６において、実施形態は、１つ以上のスレッドのクラスの中に別のスレッドのクラスがあるかどうかを判断し、高いヒープ使用量との相関度合いを判断する。当該別のスレッドのクラスがある場合、実施形態は、ステップ１００８に進んでもよい。ない場合、実施形態は、ステップ１０１８に進んでもよい。

任意ステップ１００８において、実施形態は、複数の間隔のヒープ使用量季節因子の平均を算出する。ステップ１０１０において、実施形態は、スレッドのクラスおよび複数の間隔のスレッド強度季節因子の平均を算出する。任意ステップ１０１２において、実施形態は、複数の間隔のヒープ使用量季節因子の分散を算出する。ステップ１０１４において、実施形態は、スレッドのクラスおよび複数の間隔のスレッド強度季節因子の分散を算出する。ステップ１０１６において、実施形態は、スレッドのクラスと閾値を上回るヒープ使用量との相関度合いを算出する。

ステップ１０１８において、実施形態は、１つ以上のスレッドのクラスから、閾値を上回るヒープ使用量に対する相関度合いが最も高い所与のスレッドのクラスを選択する。具体的には、スレッドのクラスごとの相関度合いが算出されると、いくつかの実施形態は、スレッドのクラスをヒープ使用量季節トレンドとの相関度合いによってランク付けしてもよい。次に、最高位にランク付けされたスレッドのクラスが、当該所与のスレッドのクラスとして選択されてもよい。

ステップ１０２０において、実施形態は、当該所与のスレッドのクラスに基づいて、高いヒープ使用量の大きな一因と思われる１行以上のコードを特定する。具体的には、次に、いくつかの実施形態は、スタックトレースが指定するファイル名および行を解析して、ヒープをため込んでいるスレッドのクラスに関連するコードの行を特定してもよい。なお、当該所与のスレッドのクラスに属する１つ以上のプロセスの各スレッドが、当該１行以上のコードを実行する。

ＶＩ．予測の際の弱外生性および分散の不均一性の克服
上述したように、標本の正確さを確実にするために、不規則な間隔で発生するフルガベージコレクション（ＧＣ）サイクルの間にヒープ割当てを測定してもよい。ヒープ使用量が特に高い状況では、絶え間ないガベージコレクションにより、標本抽出間隔は、気まぐれにゼロに近づいてしまうだろう。その結果、ヒープ割当ての測定に基づく時系列データは、弱外生性および分散の不均一性を示すだろう。弱外生性では、残差を生成するプロセスが、フルＧＣ標本の時間間隔を生成するプロセスに多少依存する。分散の不均一性では、残差の分散が、時間を通じて一定でない。

従来、線形トレンドの常最小二乗回帰を生成することは、外生的かつ等分散的なプロセスによって予測変数および応答変数が生成されることを想定する。しかしながら、フルＧＣ中に測定された値に基づくデータセットに関して、予測変数（すなわち、不規則な間隔）および応答変数（すなわち、フルＧＣ中に測定されたヒープ使用量）は、独立していない。なぜならば、ヒープ使用量が増加すると、フルＧＣが出力される頻度も増加するからである。いくつかの実施形態は、ロバスト回帰法および耐性回帰法を用いてデータセットの弱外生性および分散の不均一性を克服してもよい。

特定の実施形態は、ロバスト最小二乗回帰を利用して、このようなデータセットにおいて示される弱外生性および分散の不均一性を克服してもよい。具体的には、いくつかの実施形態は、（１）測定値の時系列を、季節変動が除去された測定成分（すなわち、季節変動が除去された成分）と季節因子成分（すなわち、季節エフェクタ）とに分解し、（２）季節変動が除去された測定成分にロバスト線形回帰を適用し、（３）季節因子成分に平滑化スプライン・フィルタを適用し、（４）線形回帰線および平滑化後の季節因子を、季節線形トレンドモデルに再構成してもよい。

最小刈込み二乗法（ＬＴＳ：Least-Trimmed Squares）推定量は、外れ値の影響を受けないロバスト回帰法である。Ｎ個の標本のセットを考えると、ＬＴＳ推定量は、標本のうち最大二乗残差に対応する５０％を外れ値としてトリムすることによって、最小二乗残差方５０％の和を最小化する。ＬＴＳ推定量は、Ｎ個すべての標本の常最小二乗回帰の反復を１回実行して残差をソートして、最小Ｎ／２の残差（すなわち、トリム標本）を選択する。次に、ＬＴＳ推定量は、当該トリム標本を更新することによって反復的に回帰を再実行して、二乗残差の平均を下げる。しかしながら、後述する特定の実施形態と比較して、ＬＴＳアルゴリズムの時間計算量は、比較的高くなるだろう。

汎用型重み付き最小二乗法（ＷＬＳ：Weighted Least-Squares）推定量は、各標本の二乗誤差残差を、標本の分散に反比例する重みによって乗算するロバスト回帰法である。ＷＬＳ推定量を採用するかどうかは、データの事前知識によって決定される重みによって決まり得る。たとえば、事前知識は、（１）異なる標本点を測定するために使用される異なる道具の正確さ、（２）同じ時刻に対応する重複した測定値間の分散、または、（３）最近接グループの測定値間の分散、を指定してもよい。事前知識によって重みを決定できなかった場合、ＷＬＳ推定量は、常最小二乗回帰を１回反復して残差を推定し、残差の逆数を重みとして使用して回帰を反復的に再実行し、線形モデルの安定した推定を出力してもよい。しかしながら、後述する特定の実施形態と比較して、ＷＬＳアルゴリズムの時間計算量は、比較的高い。

次に、いくつかの実施形態は、下記の式を用いて、季節変動が除去された生（raw）増加率を求めてもよい。

次に、いくつかの実施形態は、式を用いて、移動平均を更新してもよい。

いくつかの実施形態は、レートフィルタパラメータを用いてデータ点をトリムする。データ点のトリムは、標本点の密度を全時間領域にわたって一様にするのに役立つため、線形回帰アルゴリズムのロバストネスが向上する。フルＧＣサイクル中のソフトウェア実行環境におけるヒープ使用量の測定値を表すデータ点に関して、互いに近接するデータ点は、フルＧＣがより頻繁に実行される、ヒープ使用量がより高い時期（たとえば、負荷スパイクの間）に対応するだろう。

いくつかの実施形態は、レートフィルタパラメータを閾値と比較して、レートフィルタパラメータが閾値よりも小さい場合、ロバスト線形回帰から対応するデータ点を除外する（すなわち、トリムする）。いくつかの実施形態は、レートフィルタパラメータの中央値または平均を閾値として使用できる。具体的には、互いに近接するデータ点は、負荷の急増または外れ値を表している可能性があるため、いくつかの実施形態は、このようなデータ点をトリムすることができる。その結果、いくつかの実施形態は、時間軸に沿ってデータ点の密度を一様にすることにより、弱外生性状態を緩和してもよい。これによって、不規則な時間間隔と残差との相関が低くなる。

いくつかの実施形態は、下記の式を用いて、予測測定値の誤差残差を生成してもよい。

下記の例示的なコード（Ｒプログラミング言語で書かれた）は、標本のトリムサブセットおよび標本の重みがどのように計算され得るかを示す。下記の例示的なコードに示すように、いくつかの実施形態は、Ｒ関数「ｒｌｍ」を用いてもよい。Ｒ関数「ｒｌｍ」によって、特定の実施形態は、重み付き最小二乗回帰を生成するための標本のトリムサブセットおよび標本の重みを指定することが可能になる。なお、例示的なコードにおけるｒａｔｅＦｉｌｔｅｒＰａｒａｍｅｔｅｒ、ｓｅａｓｏｎａｌＦａｃｔｏｒ、ａｂｓｏｌｕｔｅＥｒｒｏｒＲｅｓｉｄｕａｌ、ｍｅａｓｕｒｅ、および時間ベクトルは、同じ時間領域を有する時系列である。

ヒープ使用量の外れ値および短期急増の線形回帰に対する影響を低減するために、いくつかの実施形態は、データ点の密度を一様にする手法を、ずれている標本値に対してより小さい重みを割り当てる手法と組み合わせてもよい。そうすることで、いくつかの実施形態は、線形回帰のロバストネスを高めることができるだろう。これによって、（たとえば、ヒープ使用量における）長期トレンドをとらえることが容易になるだろう。なお、これらの２つの手法を合わせて利用することによって、線形回帰線をデータによりよくフィットさせることができ、一般に回帰を何度か反復することを必要とする従来のＬＴＳ推定量またはＷＬＳ推定量よりも効率がよくなるだろう。

回帰のロバストネスをさらに向上させるために、いくつかの実施形態は、さらに、遷移状態を特定して、遷移状態にある標本点を取り除き、外れ値（たとえば、メモリリーク、メモリ不足イベント、または、非常に高い増加率に遭遇しているソフトウェア実行環境に対応するデータセグメント）であるランツーラン（run-to-run）セグメントを取り除いてもよい。

図１２は、本番環境におけるヒープ使用量を求めるための異なる線形回帰法によって導出された３つのトレンドグラフを示す図である。青色のトレンド線１２０５は、各標本点に等しい重みを割り当てる標準的な線形回帰アルゴリズムによって導出することができる。茶色のトレンド線１２１０は、従来のロバスト回帰アルゴリズムによって導出することができる。赤線１２１５は、上記の本実施形態が提供する回帰を表し、茶色のトレンド線の近くに位置する。

図１３は、従来の回帰法がどのように誤った結果をもたらすのかを例示する追加グラフを示す図である。グラフに示すように、従来の回帰法を表す茶色のトレンド線１３０５は、密度が高い標本点の２つの集落にほぼ合っている。対照的に、赤線１２１５は、標本点における傾向を正確に追跡し、ソフトウェア実行環境におけるヒープ使用量の長期予測ができている。

図１４は、いくつかの実施形態に係る、信号の予測を生成するためのプロセスのフローチャート１４００である。いくつかの実施形態では、フローチャート１４００に示すプロセスは、１つ以上のプロセッサを有するコンピュータシステム（たとえば、図１７のコンピュータシステム１７００）によって実施されてもよい。１つ以上のプロセッサが、コンピュータ読み取り可能な媒体に格納されたコンピュータコードに基づいてステップを実行できる。図１４に説明するステップは、その他のステップの有無を問わず、任意の順序で実行できる。

フローチャート１４００は、ステップ１４０２から始まる。ステップ１４０２において、実施形態は、タイムスパンの間に標本抽出された複数の測定値を含む信号を、１つ以上のプロセスが実行中の環境から受信する。いくつかの実施形態では、この複数の測定値が、１つ以上の実行中のプロセスを含むソフトウェア実行環境（たとえば、本番環境）内のヒープ使用量を監視中の制御システムによって測定されたヒープ使用量であってもよい。

ステップ１４０４において、実施形態は、信号から、季節変動が除去された成分および季節エフェクタを取り出す（ステップ１４０４）。いくつかの実施形態では、季節エフェクタは、データセットに割り当てられた期間の間隔ごとに特定された季節因子に対応してもよい。いくつかの実施形態では、季節変動が除去された成分は、季節因子を当該信号に適用することによって得られてもよい。

ステップ１４０６において、実施形態は、１つ以上のスプライン関数を季節エフェクタに適用して第１モデルを生成する。この点については、いくつかの実施形態は、標本の近接群の合成積を表す期待値から大きくはずれた標本値に、比較的小さい重みを与えてもよい。

ステップ１４０８において、実施形態は、季節変動が除去された成分に線形回帰法を適用して第２モデルを生成してもよい。具体的には、高いヒープ使用の間に経験する比較的短い間隔を補償するために、いくつかの実施形態は、短い間隔の間に抽出された標本に比較的小さい重みを与えるようにフィルタパラメータを調整してもよい。いくつかの実施形態は、レートフィルタパラメータを用いて、データセットに含まれるデータ点をトリムしてもよい。データ点のトリムは、標本点の密度を全時間領域にわたって一様にするのに役立つため、線形回帰アルゴリズムのロバストネスが向上する。

ステップ１４１０において、実施形態は、第１モデルおよび第２モデルに基づいて、信号の予測を生成する。いくつかの実施形態では、信号の予測は、ステップ１４０６および１４０８において説明した手法を用いて作られた回帰線に対応してもよい。具体的には、生成された予測は、信号によりよくフィットするだろう。

ステップ１４１２において、実施形態は、当該予測の少なくとも一部に基づいて、この環境に関連する１つ以上のアクションを開始する。たとえば、ヒープ使用量が将来増えると予測が示す場合、いくつかの実施形態は、追加リソース（たとえば、メモリ、ＲＡＭ）をソフトウェア実行環境に割り当ててもよい。

図１５は、実施形態を実現するための分散システム１５００の略図である。図示した実施形態において、分散システム１５００は、１つ以上のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８を備える。１つ以上のクライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８は、１つ以上のネットワーク（複数可）１５１０で、ウェブブラウザ、プロプライエタリ・クライアント（たとえば、Oracle Forms）などのクライアントアプリケーションを実行および操作するように構成される。サーバ１５１２は、ネットワーク１５１０を介して、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８と通信可能に接続されてもよい。

様々な実施形態において、サーバ１５１２は、１つ以上のサービスまたはソフトウェアアプリケーションを実行するようになされてもよい。特定の実施形態では、サーバ１５１２は、非仮想環境および仮想環境を含み得るその他のサービスまたはソフトウェアアプリケーションも提供してもよい。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８のユーザに対して、ウェブベースのサービスもしくはクラウドサービスとして提供されてもよく、または、ＳａａＳ（Software as a Service）モデル下で提供されてもよい。クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８を操作するユーザは、１つ以上のクライアントアプリケーションを利用してサーバ１５１２とやり取りして、これらの構成要素が提供するサービスを利用できる。

図１５に示す構成では、システム１５００のソフトウェアコンポーネント１５１８、１５２０、および１５２２がサーバ１５１２上に実装されたものとして示される。その他の実施形態では、システム１５００の構成要素のうちの１つ以上および／またはこれらの構成要素が提供するサービスのうちの１つ以上も、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８のうちの１つ以上によって実現されてもよい。次に、クライアントコンピューティングデバイスを操作しているユーザは、１つ以上のクライアントアプリケーションを利用して、これらの構成要素が提供するサービスを使用してもよい。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せで実現されてもよい。様々な異なるシステム構成が可能であり、これらは、分散システム１５００とは異なってもよいことを理解されたい。よって、図１５に示す実施形態は、実施例のシステムを実現するための分散システムの一例であって、限定を意図したものではない。

クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および／または１５０８は、様々な種類のコンピューティングシステムを含んでもよい。たとえば、クライアントコンピューティングデバイスは、ＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓＭｏｂｉｌｅ（登録商標）などのソフトウェアおよび／またはｉＯＳ、ＷｉｎｄｏｗｓＰｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ１０、ＰａｌｍＯＳなどのいろいろなモバイルオペレーティングシステムを実行する手のひらサイズのポータブルデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、携帯電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、ＰＤＡ（Personal Digital Assistant））またはウェアラブルデバイス（たとえば、ＧｏｏｇｌｅＧｌａｓｓ（登録商標）ヘッドマウントディスプレイ）を含んでもよい。デバイスは、様々なインターネット関連アプリ、電子メール、ショートメッセージサービス（SMS）アプリケーションなど、様々なアプリケーションをサポートしてもよく、様々な他の通信プロトコルを使用してもよい。また、クライアントコンピューティングデバイスは、例として、様々なバージョンのＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）、ＡｐｐｌｅＭａｃｉｎｔｏｓｈ（登録商標）、および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムを実行するパーソナルコンピュータおよび／またはラップトップコンピュータを含む、汎用パーソナルコンピュータを含んでもよい。クライアントコンピューティングデバイスは、これらに限定されないが、たとえば、ＧｏｏｇｌｅＣｈｒｏｍｅＯＳなどいろいろなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを含む各種市販のＵＮＩＸ（登録商標）またはＵＮＩＸに似たオペレーティングシステムを実行するワークステーションコンピュータであり得る。また、クライアントコンピューティングデバイスは、シン・クライアントコンピュータ、インターネット対応のゲーミングシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャ入力装置付きまたは無しのＭｉｃｒｏｓｏｆｔＸｂｏｘのゲーミングコンソール）、および／またはパーソナルメッセージングデバイスなど、ネットワーク（複数可）１５１０で通信可能な電子機器を含んでもよい。

図１５の分散システム１５００は、４台のクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスがサーバ１５１２と対話を行ってもよい。

分散システム１５００におけるネットワーク（複数可）１５１０は、これらに限定されないが、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）、ＳＮＡ（Systems Network Architecture）、ＩＰＸ（Internet Packet Exchange）、ＡｐｐｌｅＴａｌｋなどを含む利用可能なプロトコルを使用したデータ通信をサポートできる、当業者にとってなじみのある任意の種類のネットワークであってもよい。単に一例として、ネットワーク（複数可）１５１０は、ＬＡＮ（Local Area Network）、Ｅｔｈｅｒｎｅｔ（登録商標）に基づいたネットワーク、トークンリング、ワイドエリアネットワーク、インターネット、ＶＰＮ（Virtual Private Network）、イントラネット、エクストラネット、ＰＳＴＮ（Public Switched Telephone Network）、赤外線ネットワーク、ワイヤレスネットワーク（たとえば、ＩＥＥＥ（Institute of Electrical and Electronics）８０２．１１スイートのプロトコル、Ｂｌｕｅｔｏｏｔｈ（登録商標）、および／またはその他のワイヤレスプロトコルのうちのいずれかの下で動作するネットワーク）、および／もしくはこれらの任意の組合せを含む仮想ネットワーク、ならびに／または他のネットワークであり得る。

サーバ１５１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例として、ＰＣ（Personal Computer）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジ・サーバ、メインフレーム・コンピュータ、ラックマウント式サーバなどを含む）、サーバファーム、サーバ・クラスタ、またはその他の適切な配置および／もしくは組合せから構成されてもよい。サーバ１５１２は、仮想オペレーティングシステムを実行している１つ以上の仮想マシン、または仮想化を必要とする他のコンピューティングアーキテクチャを含み得る。論理記憶装置の１つ以上のフレキシブルプールを仮想化して、サーバ用の仮想記憶装置を維持することができる。仮想ネットワークは、ＳＤＮ（Software-Defined Networking）を用いて、サーバ１５１２によって制御され得る。様々な実施形態では、サーバ１５１２は、上記の開示において説明した１つ以上のサービスまたはソフトウェアアプリケーションを実行するようになされてもよい。たとえば、サーバ１５１２は、本開示の実施形態に従って、上述した処理を行うためのサーバに対応してもよい。

サーバ１５１２は、上述のオペレーティングシステムのいずれか、および任意の市販のサーバオペレーティングシステムを実行してもよい。また、サーバ１５１２は、ＨＴＴＰ（Hypertext Transport Protocol）サーバ、ＦＴＰ（File Transfer Protocol）サーバ、ＣＧＩ（Common Gateway Interface）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含む、各種の追加のサーバアプリケーションおよび／またはミッドティア・アプリケーションを実行してもよい。例示的なデータベースサーバとして、Ｏｒａｃｌｅ、Ｍｉｃｒｏｓｏｆｔ、Ｓｙｂａｓｅ、ＩＢＭ（International Business Machines）などが販売するデータベースサーバが挙げられるが、これらに限定されない。

いくつかの実装形態では、サーバ１５１２は、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８のユーザから受信したデータフィードおよび／またはイベント更新を分析するおよび１つにまとめるための１つ以上のアプリケーションを含んでもよい。例として、データフィードおよび／またはイベント更新は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新、または１つ以上のサードパーティ情報ソースおよび連続したデータストリームから受信されるリアルタイム更新を含んでもよいが、これらに限定されない。データフィードおよび／またはイベント更新は、センサーデータアプリケーション、チッカー（financial ticker）、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量監視などに関するリアルタイムイベントを含み得る。また、サーバ１５１２は、クライアントコンピューティングデバイス１５０２、１５０４、１５０６、および１５０８の１つ以上の表示装置を介してデータフィードおよび／またはリアルタイムイベントを表示するための１つ以上のアプリケーションを含んでもよい。

また、分散システム１５００は、１つ以上のデータベース１５１４および１５１６を含んでもよい。これらのデータベースは、ユーザインタラクション情報、使用パターン情報、適合規則情報、および本開示の実施形態が使用するその他の情報などの情報を格納するためのメカニズムを提供してもよい。データベース１５１４および１５１６は、いろいろな場所に存在してもよい。一例として、データベース１５１４および１５１６のうちの１つ以上は、サーバ１５１２にローカルな（および／または存在する）非一時的な記憶媒体上に存在してもよい。これに代えて、データベース１５１４および１５１６は、サーバ１５１２から遠隔の場所に存在し、ネットワークベースの接続または専用の接続を通してサーバ１５１２と通信していてもよい。一組の実施形態において、データベース１５１４および１５１６は、ＳＡＮ（Storage-Area Network）に存在してもよい。同様に、サーバ１５１２に起因する機能を実行するための必要なファイルは、いずれも、サーバ１５１２上のローカルな場所および／またはサーバ１５１２から遠隔の場所に適宜格納されてもよい。一組の実施形態において、データベース１５１４および１５１６は、Ｏｒａｃｌｅが提供するデータベースなど、ＳＱＬフォーマットのコマンドに応答してデータを格納、更新、および取り出すようになされたリレーショナルデータベースを含んでもよい。

いくつかの実施形態では、クラウド環境は、１つ以上のサービスを提供してもよい。図１６は、本開示の実施形態に係る、クラウドサービスとしてサービスが提供され得るシステム環境１６００の１つ以上のコンポーネントの簡略ブロック図である。図１６に示す実施形態において、システム環境１６００は、１つ以上のクライアントコンピューティングデバイス１６０４、１６０６、および１６０８を含む。１つ以上のクライアントコンピューティングデバイス１６０４、１６０６、および１６０８は、ユーザによって、クラウドサービスを提供するクラウドインフラストラクチャシステム１６０２と対話するために使用されもよい。クラウドインフラストラクチャシステム１６０２は、サーバ１６１２に関して上述したものを含み得る１つ以上のコンピュータおよび／またはサーバを備えてもよい。

図１６に示すクラウドインフラストラクチャシステム１６０２が、図示された構成要素以外の構成要素を有し得ることを理解されたい。さらに、図１６に示す実施形態は、本開示の実施形態を組み込み得るクラウドインフラストラクチャシステムの一例に過ぎない。他のいくつかの実施形態において、クラウドインフラストラクチャシステム１６０２は、図に示すコンポーネントよりも多いまたは少ない数のコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの構成または配置が異なっていてもよい。

クライアントコンピューティングデバイス１６０４、１６０６、および１６０８は、上述したものと同様のデバイスであってもよい。クライアントコンピューティングデバイス１６０４、１６０６、および１６０は、ウェブブラウザ、プロプライエタリ・クライアントアプリケーション（たとえば、Oracle Forms）、または他のアプリケーションなど、クライアントアプリケーションを操作するように構成されてもよい。クライアントアプリケーションは、クライアントコンピューティングデバイスのユーザによって、クラウドインフラストラクチャシステム１６０２と対話を行ってクラウドインフラストラクチャシステム１６０２が提供するサービスを利用するために使用されてもよい。例示的なシステム環境１６００は、３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサ付きデバイスなど、他のデバイスなどがクラウドインフラストラクチャシステム１６０２と対話を行ってもよい。

ネットワーク（複数可）１６１０は、クライアントコンピューティングデバイス１６０４、１６０６、および１６０８とクラウドインフラストラクチャシステム１６０２との間のデータの通信およびやり取りを容易にしてもよい。各ネットワークは、ネットワーク（複数可）１６１０に関して上述したプロトコルを含む各種市販のプロトコルのいずれかを用いたデータ通信をサポートできる、当業者にとってなじみのある任意の種類のネットワークであってもよい。

特定の実施形態では、クラウドインフラストラクチャシステム１６０２が提供するサービスは、クラウドインフラストラクチャシステムのユーザが要求すれば利用可能になるサービスのホストを含んでもよい。これらに限定されないが、オンラインのデータストレージおよびバックアップソリューション、ウェブベースの電子メールサービス、ホストされたオフィススイートドキュメント連携サービス、データベース処理、管理されたテクニカルサポートサービスなどを含む様々な他のサービスが提供されてもよい。クラウドインフラストラクチャシステムが提供するサービスは、動的にスケール変更してそのユーザのニーズを満たすことができる。

特定の実施形態では、クラウドインフラストラクチャシステム１６０２が提供するサービスを具体的にインスタンス化したものは、本明細書において、「サービスインスタンス」と称される場合がある。一般に、インターネットなどの通信ネットワークを介してユーザが利用できるようになる、クラウドサービスプロバイダのシステムからのいずれのサービスも、「クラウドサービス」と称される。通常、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客所有のオンプレミス・サーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストしてもよく、ユーザは、インターネットなどの通信ネットワークを介して、要求に基づいてアプリケーションを注文および使用すればよい。

いくつかの例において、コンピュータネットワークのクラウドインフラストラクチャにおけるサービスは、ストレージ、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーションへの保護されたコンピュータネットワークアクセス、もしくはクラウドベンダーがユーザに提供するその他のサービス、または、当技術分野で周知の上記以外のその他のサービスを含んでもよい。たとえば、サービスは、インターネットを通した、クラウド上のリモートストレージへのパスワード保護されたアクセスを含み得る。別の例として、サービスは、ネットワークで結ばれた開発者が私的に利用するための、ウェブサービスベースのホストされたリレーショナルデータベースおよびスクリプト言語のミドルウェアエンジンを含み得る。別の例として、サービスは、クラウドベンダーのウェブサイト上にホストされた電子メールソフトウェア・アプリケーションへのアクセスを含み得る。

特定の実施形態では、クラウドインフラストラクチャシステム１６０２は、顧客にセルフサービスで、サブスクリプション方式で、伸縮自在にスケーラブルに、確実に、かつ高い可用性を有するセキュアな方法で届けられるアプリケーションのスイート、ミドルウェア、およびデータベースサービス提供物を含んでもよい。このようなクラウドインフラストラクチャシステムの例が、本願の譲受人が提供するオラクルパブリッククラウド（Oracle Public Cloud）である。

また、クラウドインフラストラクチャシステム１６０２は、「ビッグデータ」に関する演算および分析サービスを提供してもよい。用語「ビッグデータ」は、一般に、大量のデータを可視化する、トレンドを検出する、および／またはこのデータとやり取りするためにアナリストおよび研究者によって格納および操作され得る、極めて大きなデータセットを指す。このビッグデータおよび関連アプリケーションは、多くのレベルおよび異なる規模で、インフラストラクチャシステムによってホストおよび／または操作され得る。このようなデータを提示するために、またはこのデータに対する外力またはデータが表すものをシミュレーションするために、並列にリンクされた何十、何百、または何千ものプロセッサがこのデータに作用し得る。これらのデータセットは、データベースにおいて、または構造化モデルに応じて編成された構造化データのような構造化データ、および／または非構造化データ（たとえば、Ｅメール、画像、データＢＬＯＢ（binary large objects）、ウェブページ、複雑なイベント処理）を必要とし得る。より多くの（または、より少ない）コンピューティングリソースを比較的素早く目標に集めるための実施形態の機能を活用することによって、企業、政府関係機関、研究機関、私人、同じ意見を持った個人同士のグループもしくは組織、または他のエンティティからの要求に基づいて、大きなデータセットに対してタスクを実行するために、クラウドインフラストラクチャシステムをより役立てることができる。

様々な実施形態において、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステム１６０２が提供するサービスへの顧客のサブスクリプションを自動的にプロビジョニング、管理、および追跡するようになされてもよい。クラウドインフラストラクチャシステム１６０２は、それぞれ異なるデプロイメントモデルを介してクラウドサービスを提供してもよい。たとえば、サービスは、クラウドサービス（たとえば、オラクルコーポレーション所有）を販売する組織がクラウドインフラストラクチャシステム１６０２を所有し、このサービスが一般大衆またはそれぞれ異なる産業企業に利用可能になる、パブリッククラウドモデル下で提供されてもよい。別の例として、クラウドインフラストラクチャシステム１６０２が１つの組織のためだけに動かされ、クラウドインフラストラクチャシステム１６０２が組織内の１つ以上のエンティティ用のサービスを提供し得るプライベートクラウドモデル下で、サービスが提供されてもよい。また、クラウドサービスは、クラウドインフラストラクチャシステム１６０２およびクラウドインフラストラクチャシステム１６０２が提供するサービスが関連コミュニティ内のいくつかの組織によって共有されるコミュニティクラウドモデル下で提供されてもよい。クラウドサービスは、２つ以上の異なるモデルの組み合せであるハイブリッドクラウドモデル下で提供されてもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１６０２が提供するサービスは、ＳａａＳ（Software as a Service）カテゴリ、ＰａａＳ（Platform as a Service）カテゴリ、ＩａａＳ（Infrastructure as a Service）カテゴリ下で提供される１つ以上のサービス、またはハイブリッドサービスを含むその他のカテゴリのサービスを含んでもよい。顧客は、サブスクリプションの注文によって、クラウドインフラストラクチャシステム１６０２が提供する１つ以上のサービスを注文してもよい。次に、クラウドインフラストラクチャシステム１６０２は、処理を実行して、顧客のサブスクリプションの注文にあるサービスを提供する。

いくつかの実施形態では、クラウドインフラストラクチャシステム１６０２が提供するサービスは、アプリケーションサービス、プラットフォームサービス、およびインフラストラクチャサービスを含んでもよいが、これらに限定されない。いくつかの例において、アプリケーションサービスは、ＳａａＳサービスを介してクラウドインフラストラクチャシステムによって提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに該当するクラウドサービスを提供するように構成されてもよい。たとえば、ＳａａＳプラットフォームは、オンデマンドアプリケーションのスイートを構築して統合開発／デプロイメントプラットフォームに届けるための機能を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。ＳａａＳプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で実行されるアプリケーションを利用できる。顧客は、アプリケーションサービスを、ライセンスおよびサポートを別に購入する必要なしに、入手できる。様々な異なるＳａａＳサービスが提供されてもよい。例として、大きな組織のための販売実績管理、企業統合、および事業の柔軟性に対するソリューションを提供するサービスなどが挙げられるが、これに限定されない。

いくつかの実施形態では、プラットフォームサービスは、ＰａａＳプラットフォームを介してクラウドインフラストラクチャシステム１６０２によって提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに該当するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスとして、存在するアプリケーションを組織（Ｏｒａｃｌｅなど）が共有の共通アーキテクチャ上に１つにまとめることを可能にするサービス、およびプラットフォームが提供する共有サービスを活用する新しいアプリケーションを作る機能などが挙げられるが、これらに限定されない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基礎となるソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステム１６０２が提供するＰａａＳサービスを、ライセンスおよびサポートを別に購入する必要なしに、入手できる。プラットフォームサービスとして、ＪＣＳ（Oracle Java Cloud Service）、ＤＢＣＳ（Oracle Database Cloud Service）、およびその他が挙げられるが、これらに限定されない。

ＰａａＳプラットフォームが提供するサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムがサポートするプログラミング言語およびツールを採用することができ、また、デブロイされたサービスを管理することができる。いくつかの実施形態では、クラウドインフラストラクチャシステムが提供するプラットフォームサービスは、データベース・クラウドサービス、ミドルウェアクラウドサービス（たとえば、ＯｒａｃｌｅＦｕｓｉｏｎＭｉｄｄｌｅｗａｒｅサービス）、およびＪａｖａクラウドサービスを含んでもよい。一実施形態において、データベース・クラウドサービスは、組織がデータベースリソースをプールすることと、データベース・クラウドの形でＤａｔａｂａｓｅａｓａＳｅｒｖｉｃｅを顧客に提供することとを可能にする共有サービスデプロイメントモデルをサポートしてもよい。クラウドインフラストラクチャシステムにおいて、ミドルウェアクラウドサービスは、顧客が様々なビジネスアプリケーションを開発およびデプロイするためのプラットフォームを提供してもよく、Ｊａｖａクラウドサービスは、顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームを提供してもよい。

クラウドインフラストラクチャシステムでは、ＩａａＳプラットフォームによって様々な異なるインフラストラクチャサービスが提供されてもよい。インフラストラクチャサービスによって、ストレージ、ネットワークなど基礎となるコンピューティングリソース、および、ＳａａＳプラットフォームおよびＰａａＳプラットフォームが提供するサービスを利用している顧客のためのその他の基本的なコンピューティングリソースの管理および制御が容易になる。

また、特定の実施形態では、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステムの顧客に様々なサービスを提供するために使用されるリソースを提供するためのインフラストラクチャ・リソース１６３０を含んでもよい。一実施形態において、インフラストラクチャ・リソース１６３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームが提供するサービスおよびその他のリソースを実行するための、サーバなどのハードウェアと、ストレージと、ネットワーキング・リソースとを予め統合した最適な組合せを含んでもよい。

いくつかの実施形態では、クラウドインフラストラクチャシステム１６０２におけるリソースは、複数のユーザによって共有され、要求に応じて動的に再割り当てされてもよい。これに加えて、リソースは、それぞれ異なるタイムゾーンのユーザに割り当てられてもよい。たとえば、クラウドインフラストラクチャシステム１６０２は、第１のタイムゾーンにいる第１セットのユーザがクラウドインフラストラクチャシステムのリソースを指定された時間数利用することを可能にした後、異なるタイムゾーンに位置する別のセットのユーザに同じリソースを再割り当てすることを可能にし、リソースの利用が最大限に活用できるようになる。

特定の実施形態では、クラウドインフラストラクチャシステム１６０２によるサービスの提供を可能にするための、クラウドインフラストラクチャシステム１６０２のそれぞれ異なる構成要素またはモジュールによって共有されるいくつかの内部共有サービス１６３２が提供されてもよい。これらの内部共有サービスは、セキュリティ／素性サービス、統合サービス、企業リポジトリサービス、企業マネージャサービス、ウイルススキャン／ホワイトリストサービス、可用性の高いバックアップ／リカバリサービス、クラウドサポートを可能にするためのサービス、Ｅメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されない。

特定の実施形態では、クラウドインフラストラクチャシステム１６０２は、クラウドインフラストラクチャシステムにおけるクラウドサービス（たとえば、ＳａａＳサービス、ＰａａＳサービス、およびＩａａＳサービス）の包括的な管理を提供してもよい。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１６０２が受信した顧客のサブスクリプションなどをプロビジョニング、管理、および追跡するための機能などを含んでもよい。

一実施形態において、図１６に示すように、クラウド管理機能は、オーダー管理モジュール１６２０、オーダーオーケストレーションモジュール１６２２、オーダープロビジョニングモジュール１６２４、オーダー管理／監視モジュール１６２６、および素性管理モジュール１６２８など、１つ以上のモジュールによって提供されてもよい。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含んでもよく、または、これらを使用して提供されてもよい。１つ以上のコンピュータおよび／またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバ・クラスタ、またはその他の適切な配置および／もしくは組合せであり得る。

例示的な動作では、ステップ１６３４において、クライアントコンピューティングデバイス１６０４、１６０６、または１６０８などのクライアントデバイスを使用している顧客は、クラウドインフラストラクチャシステム１６０２が提供する１つ以上のサービスを要求し、クラウドインフラストラクチャシステム１６０２が提供する１つ以上のサービスのサブスクリプションを注文することによって、クラウドインフラストラクチャシステム１６０２と対話してもよい。特定の実施形態において、顧客は、クラウドユーザインタフェース（ＵＩ：ＵｓｅｒＩｎｔｅｒｆａｃｅ）１６１２、クラウドＵＩ１６１４、および／またはクラウドＵＩ１６１６などのクラウドＵＩにアクセスし、これらのＵＩを介してサブスクリプションの注文を行ってもよい。顧客が注文をすることに応答してクラウドインフラストラクチャシステム１６０２が受信するオーダー情報は、この顧客を特定する情報、および、クラウドインフラストラクチャシステム１６０２が提供する、顧客がサブスクリプションをする目的の１つ以上のサービスを含んでもよい。

ステップ１６３６において、顧客から受けたオーダー情報を、オーダーデータベース１６１８に格納してもよい。これが、新しいオーダーである場合、オーダーについての新しい記録を作成してもよい。一実施形態において、オーダーデータベース１６１８は、クラウドインフラストラクチャシステム１６１８によって操作され、他のシステム要素と共に操作されるいくつかのデータベースのうちの１つであり得る。

ステップ１６３８において、オーダー情報がオーダー管理モジュール１６２０に転送されてもよい。オーダー管理モジュール１６２０は、注文の確認、確認後の注文の登録など、注文に関する課金機能および会計機能を実行するように構成されてもよい。

ステップ１６４０において、注文に関する情報がオーダーオーケストレーションモジュール１６２２に伝送されてもよい。オーダーオーケストレーションモジュール１６２２は、顧客が行った注文に関するサービスおよびリソースのプロビジョニングをオーケストレーションするように構成される。場合によっては、オーダーオーケストレーションモジュール１６２２は、オーダープロビジョニングモジュール１６２４のサービスをプロビジョニングのために使用してもよい。特定の実施形態において、オーダーオーケストレーションモジュール１６２２は、各オーダーに対応付けられたビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、オーダーがプロビジョニングに取り掛かるべきかどうかを判断する。

図１６に表した実施形態に示すように、ステップ１６４２において、新しいサブスクリプションの注文を受けると、オーダーオーケストレーションモジュール１６２２は、サブスクリプションの注文を満たすために必要なリソースを割り当て、かつ、リソースを構成する要求を、オーダープロビジョニングモジュール１６２４に送信する。オーダープロビジョニングモジュール１６２４は、顧客が申し込んだサービスのためのリソースの割り当てを有効にする。オーダープロビジョニングモジュール１６２４は、クラウドインフラストラクチャシステム１６００が提供するクラウドサービスと、要求されたサービスを提供するためのリソースをプロビジョニングするために使用される物理実施層との間に抽象度を設ける。これによって、サービスおよびリソースがオンザフライで実際にプロビジョニングされたかどうか、または予めプロビジョニングされて要求された場合にのみ割り当てられたかどうかなどの実装の詳細からオーダーオーケストレーションモジュール１６２２を切り離すことが可能になる。

ステップ１６４４において、サービスおよびリソースがプロビジョニングされると、要求されたサービスが使える用意が整ったことを示す通知がサブスクリプションをしている顧客に送られてもよい。ある場合において、要求されたサービスを顧客が使用し始めることを可能にする情報（たとえば、リンク）が、顧客に送られてもよい。

ステップ１６４６において、顧客のサブスクリプションの注文が、オーダー管理／監視モジュール１６２６よって管理および追跡されてもよい。場合によっては、オーダー管理／監視モジュール１６２６は、顧客のサブスクリプションしているサービスの使用に関する使用統計データを収集するように構成されてもよい。たとえば、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムの稼働時間およびシステムの休止時間などについての統計データが収集されてもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１６００は、素性管理モジュール１６２８を備えてもよい。素性管理モジュール１６２８は、クラウドインフラストラクチャシステム１６００におけるアクセス管理およびアクセス認可サービスなどの素性サービスを提供するように構成される。いくつかの実施形態では、素性管理モジュール１６２８は、クラウドインフラストラクチャシステム１６０２が提供するサービスを利用したい顧客についての情報を制御／管理してもよい。このような情報は、このような顧客の素性を認証する情報、および、様々なシステムリソース（たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してそれらの顧客がどのような操作を行うことが承認されているのかを記述する情報を含み得る。また、素性管理モジュール１６２８は、各顧客についての記述情報の管理、およびその記述情報が誰によってどのようにアクセスおよび変更され得るかについての管理を含んでもよい。

図１７は、本開示の実施形態を実施するために使用され得る例示的なコンピュータシステム１７００を示す図である。いくつかの実施形態では、コンピュータシステム１７００は、上述した様々なサーバおよびコンピュータシステムのうちのいずれかを実現するために使用されてもよい。図１７に示すように、コンピュータシステム１７００は、バス・サブシステム１７０２を介していくつかの周辺サブシステムと通信する処理装置１７０４を含んだ様々なサブシステムを含む。これらの周辺サブシステムは、処理高速化装置１７０６と、Ｉ／Ｏサブシステム１７０８と、ストレージサブシステム１７１８と、通信サブシステム１７２４とを含んでもよい。ストレージサブシステム１７１８は、有形のコンピュータ読み取り可能な記憶媒体１７２２と、システムメモリ１７１０とを含んでもよい。

バス・サブシステム１７０２は、コンピュータシステム１７００の様々な構成要素およびサブシステムを互いに意図した通りに通信させるためのメカニズムを提供する。バス・サブシステム１７０２は、１つのバスとして図示されているが、バス・サブシステムの別の実施形態は、複数のバスを利用してもよい。バス・サブシステム１７０２は、各種のバスアーキテクチャを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかの種類のバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびＰＣＩ（Peripheral Component Interconnect）バスを含んでもよく、これらは、ＩＥＥＥＰ１３８６．１標準規格に準拠して製造されるＭｅｚｚａｎｉｎｅバスなどとして実現され得る。

処理サブシステム１７０４は、コンピュータシステム１７００の動作を制御し、１つ以上の処理装置１７３２、１７３４などを備えてもよい。処理装置は、シングルコア・プロセッサまたはマルチコア・プロセッサを含む１つ以上のプロセッサ、プロセッサの１つ以上のコア、またはそれらの組合せを含んでもよい。いくつかの実施形態では、処理サブシステム１７０４は、グラフィックスプロセッサ、デジタル・シグナル・プロセッサ（ＤＳＰ）など、１つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム１７０４の処理装置の一部またはすべては、特定用途向け集積回路（ＡＳＩＣ）、またはフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、カスタム回路を使用して実現され得る。

いくつかの実施形態では、処理サブシステム１７０４に含まれる処理装置は、システムメモリ１７１０に、または、コンピュータ読み取り可能な記憶媒体１７２２上に格納された命令を実行できる。様々な実施形態において、処理装置は、いろいろなプログラムまたはコード命令を実行し、複数の同時に動作しているプログラムまたはプロセスを維持できる。いつでも、実行されるプログラムコードの一部またはすべては、システムメモリ１７１０に、および／または、１つ以上の記憶装置上を可能性として含むコンピュータ読み取り可能な記憶媒体１７２２上に存在し得る。適したプログラミングを通して、処理サブシステム１７０４は、様々な機能を提供できる。

特定の実施形態において、カスタマイズされた処理を実行するための、または、コンピュータシステム１７００によって実行される全体的な処理を高速化させるために処理サブシステム１７０４によって実行される処理のうちのいくつかの負荷を軽減させるための処理高速化装置１７０６が提供されてもよい。

Ｉ／Ｏサブシステム１７０８は、コンピュータシステム１７００に情報を入力するためのデバイスおよびメカニズムならびに／またはコンピュータシステム１７００を介して情報を出力するためのデバイスおよびメカニズムを含んでもよい。一般に、用語「入力装置」の使用は、コンピュータシステム１７００に情報を入力するためのあらゆる種類のデバイスおよびメカニズムを含む意図がある。ユーザインタフェース入力装置は、たとえば、キーボード、マウスもしくはトラックボールなどのポインティングデバイス、タッチパッドもしくはディスプレイに組み込まれたタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、ボイスコマンド認識システムを有する音声入力装置、マイクロホン、および他の種類の入力装置を含んでもよい。また、ユーザインタフェース入力装置は、ユーザが入力装置を制御およびそれとやり取りすることを可能にするＭｉｃｒｏｓｏｆｔＫｉｎｅｃｔ（登録商標）モーションセンサ、ＭｉｃｒｏｓｏｆｔＸｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャコマンドおよび音声コマンドを用いた入力を受け付けるためのインタフェースを提供するデバイスなど、動き検知デバイスおよび／またはジェスチャ認識デバイスを含んでもよい。また、ユーザインタフェース入力装置は、ユーザの目の行動（たとえば、写真を撮影しているおよび／またはメニュー選択を行っている間の「まばたき」）を検出し、目の仕草（eye gesture）を入力装置（たとえば、ＧｏｏｇｌｅＧｌａｓｓ（登録商標））への入力として変形させるＧｏｏｇｌｅＧｌａｓｓ（登録商標）まばたき検出装置などのアイジェスチャ認識デバイスを含んでもよい。これに加えて、ユーザインタフェース入力装置は、ユーザがボイスコマンドによって音声認識システム（たとえば、Ｓｉｒｉ（登録商標）ナビゲータ）とやり取りすることを可能にする音声認識検知デバイスを含んでもよい。

ユーザインタフェース入力装置のその他の例として、３次元（３Ｄ）マウス、ジョイスティックもしくはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびに、スピーカ、デジタルカメラ、デジタルカムコーダー、ポータブルメディアプレーヤ、ウェブカム、イメージスキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザー測距器、および視線追跡装置などのオーディオ／ビジュアル装置が挙げられるが、これらに限定されない。これに加えて、ユーザインタフェース入力装置は、たとえば、コンピュータ断層撮影法、磁気共鳴画像、陽電子放出断層撮影装置、超音波検査デバイスなど、医用画像入力装置を含んでもよい。また、ユーザインタフェース入力装置は、たとえば、ＭＩＤＩキーボード、デジタル楽器などのオーディオ入力装置を含んでもよい。

ユーザインタフェース出力装置は、表示サブシステム、インジケーターライト、または音声出力装置などの非視覚的表示装置などを含んでもよい。表示サブシステムは、ブラウン管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使用するものなどのフラットパネル表示装置、投影装置、タッチスクリーンなどであってもよい。一般に、用語「出力装置」の使用は、コンピュータシステム１７００からユーザまたは他のコンピュータに情報を出力するためのあらゆる種類のデバイスおよびメカニズムを含むことを意図する。たとえば、ユーザインタフェース出力装置は、モニタ、プリンタ、スピーカ、ヘッドホン、自動車ナビゲーションシステム、作図装置、音声出力装置、およびモデムなど、文字、図形、および音声／映像情報を視覚的に伝えるいろいろな表示装置を含み得るが、これらに限定されない。

ストレージサブシステム１７１８は、コンピュータシステム１７００が使用する情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム１７１８は、いくつかの実施形態の機能を提供する基本プログラミング構成およびデータ構成を格納するための有形の非一時的なコンピュータ読み取り可能な記憶媒体を提供する。処理サブシステム１７０４によって実行されると上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）がストレージサブシステム１７１８に格納されてもよい。ソフトウェアは、処理サブシステム１７０４の１つ以上の処理装置によって実行されてもよい。また、ストレージサブシステム１７１８は、本開示に従って使用されるデータを格納するためのリポジトリを提供してもよい。

ストレージサブシステム１７１８は、揮発性メモリ素子および不揮発性メモリ素子を含む、１つ以上の非一時的なメモリ素子を含んでもよい。図１７に示すように、ストレージサブシステム１７１８は、システムメモリ１７１０と、コンピュータ読み取り可能な記憶媒体１７２２とを備える。システムメモリ１７１０は、プログラムを実行中に命令およびデータを格納するための揮発性のメインＲＡＭ（Random Access Memory）、および、固定の命令が格納される不揮発性ＲＯＭ（Read Only Memory）またはフラッシュメモリを含む、いくつかのメモリを含んでもよい。いくつかの実装形態において、起動中などで、コンピュータシステム１７００内の要素間で情報を転送することを助ける基本ルーチンを含んだＢＩＯＳ（Basic Input/Output System）は、通常、ＲＯＭに格納されてもよい。ＲＡＭは、通常、処理サブシステム１７０４が現在操作および実行していているデータおよび／またはプログラムモジュールを含む。いくつかの実装形態において、システムメモリ１７１０は、ＳＲＡＭ（Static Random Access Memory）またはＤＲＡＭ（Dynamic Random Access Memory）など、複数の異なる種類のメモリを含んでもよい。

一例として、限定ではないが、図１７に示すように、システムメモリ１７１０は、クライアントアプリケーション、ウェブブラウザ、ミッドティア・アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ：Relational Database Management Systems）などを含み得るアプリケーションプログラム１７１２と、プログラムデータ１７１４と、オペレーティングシステム１７１６とを格納してもよい。一例として、オペレーティングシステム１７１６は、様々なバージョンのＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）、ＡｐｐｌｅＭａｃｉｎｔｏｓｈ（登録商標）、および／もしくはＬｉｎｕｘオペレーティングシステム、いろいろな市販のＵＮＩＸ（登録商標）もしくはＵＮＩＸに似たオペレーティングシステム（いろいろなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、ＧｏｏｇｌｅＣｈｒｏｍｅ（登録商標）ＯＳなどを含むが、これらに限定されない）、ならびに／またはｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標）Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標）ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ＯＳ、およびＰａｌｍ（登録商標）ＯＳオペレーティングシステムなど、モバイルオペレーティングシステムを含んでもよい。

コンピュータ読み取り可能な記憶媒体１７２２は、いくつかの実施形態の機能を提供するプログラミング構成およびデータ構成を格納してもよい。処理サブシステム１７０４によって実行されると上述した機能をプロセッサに提供するソフトウェア（プログラム、コードモジュール、命令）がストレージサブシステム１７１８に格納されてもよい。一例として、コンピュータ読み取り可能な記憶媒体１７２２は、ハードディスクドライブなどの不揮発性メモリ、磁気ディスクドライブ、ＣＤＲＯＭ、ＤＶＤ、Ｂｌｕ−Ｒａｙ（登録商標）ディスクなどの光ディスクドライブまたは他の光学媒体を含んでもよい。コンピュータ読み取り可能な記憶媒体１７２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリーカード、ＵＳＢ（Universal Serial Bus）フラッシュドライブ、ＳＤ（Secure Digital）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、これらに限定されない。また、コンピュータ読み取り可能な記憶媒体１７２２は、フラッシュメモリベースのＳＳＤ（Solid-State Drives）、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなど、不揮発性メモリに基づくＳＳＤ（Solid-State Drives）と、ソリッドステートＲＡＭ、動的ＲＡＭ、静的ＲＡＭ、ＤＲＡＭベースのＳＳＤなど、揮発性メモリに基づくＳＳＤと、ＭＲＡＭ（Magnetoresistive RAM）ＳＳＤと、ＤＲＡＭとフラッシュメモリベースのＳＳＤとの組合せを使用するハイブリッドＳＳＤとを含んでもよい。コンピュータ読み取り可能な媒体１７２２は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、およびその他のコンピュータシステム１７００用データの不揮発性ストレージを提供してもよい。

また、特定の実施形態において、ストレージサブシステム１７００は、コンピュータ読み取り可能な記憶媒体１７２２にさらに接続できるコンピュータ読み取り可能な記憶媒体リーダ１７２０を含んでもよい。あるいは、システムメモリ１７１０と合わせて、または、必要に応じてシステムメモリ１７１０と組み合わせて、コンピュータ読み取り可能な記憶媒体１７２２は、遠隔の記憶装置、ローカル記憶装置、固定記憶装置、および／またはリム―バブル記憶装置、ならびにコンピュータ読み取り可能な情報を格納するための記憶媒体を包括的に表してもよい。

特定の実施形態において、コンピュータシステム１７００は、１台以上の仮想マシンを実行するためのサポートを提供してもよい。コンピュータシステム１７００は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行してもよい。各仮想マシンには、メモリ、コンピュータ（たとえば、プロセッサ、コア）、Ｉ／Ｏ、およびネットワーキング・リソースが割り当てられてもよい。各仮想マシンは、通常、それ自体のオペレーティングシステムを実行する。このオペレーティングシステムは、コンピュータシステム１７００が実行する他の仮想マシンによって実行されるオペレーティングシステムと同じまたは異なってもよい。よって、コンピュータシステム１７００によって複数のオペレーティングシステムが同時に実行される可能性がある。各仮想マシンは、一般に、その他の仮想マシンとは別に実行される。

通信サブシステム１７２４は、他のコンピュータシステムおよびネットワークへのインタフェースを提供する。通信サブシステム１７２４は、コンピュータシステム１７００からデータを受信し、コンピュータシステム１７００から他のシステムにデータを送信するためのインタフェースとして機能する。たとえば、通信サブシステム１７２４は、１つ以上のクライアントコンピューティングデバイスと情報を送受信するためにコンピュータシステム１７００がインターネットを介してクライアントコンピューティングデバイスとの通信チャネルを確立することを可能にしてもよい。

通信サブシステム１７２４は、有線通信プロトコルおよび／またはワイヤレス通信プロトコルをサポートしてもよい。たとえば、特定の実施形態において、通信サブシステム１７２４は、（たとえば、携帯電話技術、３Ｇ、４Ｇ、もしくはＥＤＧＥ（Enhanced Data Rates For Global Evolution）などの次世代データネットワークテクノロジー、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー標準規格）、他の移動体通信技術、またはそれらの任意の組合せを使用する）ワイヤレス音声ネットワークもしくは／またはデータネットワークにアクセスするためのＲＦ（Radio Frequency）トランシーバコンポーネント、ＧＰＳ（Global Positioning System）レシーバコンポーネント、および／または他の構成要素を含み得る。いくつかの実施形態では、通信サブシステム１７２４は、ワイヤレスインタフェースに加えて、またはワイヤレスインタフェースの代わりに、有線ネットワーク接続性（たとえば、Ｅｔｈｅｒｎｅｔ）を提供できる。

通信サブシステム１７２４は、データを様々な形で送受信できる。たとえば、いくつかの実施形態では、通信サブシステム１７２４は、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベント更新１７３０などの形で入力通信文を受信してもよい。たとえば、通信サブシステム１７２４は、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新、ＲｉｃｈＳｉｔｅＳｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／または１つ以上のサードパーティ情報ソースからのリアルタイム更新など、ソーシャルメディアネットワークおよび／またはその他のコミュニケーションサービスのユーザからのデータフィード１７２６をリアルタイムで受信（または送信）するように構成されてもよい。

特定の実施形態では、通信サブシステム１７２４は、連続したデータストリームの形でデータを受信するように構成されてもよい。連続したデータストリームは、リアルタイムイベントのイベントストリーム１７２８および／またはイベント更新１７３０を含んでもよく、実際に明確な終端がない連続ストリームまた無限ストリームであってもよい。連続データを生成するアプリケーションとして、たとえば、センサーデータアプリケーション、チッカー、ネットワークパフォーマンス測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車交通量監視などが挙げられてもよい。

また、通信サブシステム１７２４は、コンピュータシステム１７００に接続された１つ以上のストリーミングデータソースコンピュータと通信中であり得る１つ以上のデータベースに、構造化および／または非構造化データフィード１７２６、イベントストリーム１７２８、イベント更新１７３０などを出力するように構成されてもよい。

コンピュータシステム１７００は、手のひらサイズのポータブルデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、ＧｏｏｇｌｅＧｌａｓｓ（登録商標）ヘッドマウントディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、様々な種類のうちの１つであり得る。

変わり続けるというコンピュータおよびネットワークの性質のため、図１７に示すコンピュータシステム１７００の説明は、具体例にすぎない。図１７に示すシステムよりも多いまたは少ない構成要素を有する多くの他の構成が可能である。本明細書に記載の開示および教示に基づいて、当業者は、様々な実施形態を実現するための他のやり方および／または方法が分かるだろう。

具体的な本開示の実施形態を説明したが、様々な変更例、代替例、代替的な構成、および均等物も本開示の範囲内に包含される。変更例は、開示された特徴の適切な組合せのいずれも含む。本開示の実施形態は、ある特定のデータ処理環境内の動作に制限されず、複数のデータ処理環境内で自由に動作することができる。これに加えて、特定の一連のトランザクションおよびステップを使用して本開示の実施形態を説明したが、本開示の範囲が記載の一連のトランザクションおよびステップに限られないことは、当業者に明らかであるはずである。上述の実施形態の様々な特徴および態様は、個々にまたは共同で使用されてもよい。

さらに、ハードウェアとソフトウェアとの特定の組合せを使用して本開示の実施形態を説明したが、ハードウェアとソフトウェアとの他の組合せも、本開示の範囲内であることを認識されたい。本開示の実施形態は、ハードウェアのみ、もしくは、ソフトウェアのみで実現されてもよく、またはそれらの組合せを使用して実現されてもよい。本明細書に記載の様々なプロセスは、同じプロセッサまたは任意の組合せのそれぞれ異なるプロセッサ上で実現できる。よって、コンポーネントまたはモジュールが特定の動作を実行するように構成されると説明されている箇所では、このような構成は、たとえば、この動作を実行するように電子回路を設計することによって、この動作を実行するようにプログラム可能な電子回路（マイクロプロセッサなど）をプログラムすることによって、またはそれらの任意の組合せによって達成できる。プロセスは、プロセス間通信のための従来技術を含むいろいろな技術を使用して通信できるが、これに限定されず、それぞれ異なるペアプロセスは、異なる技術を使用してもよく、プロセスの同じペアは、異なる技術を別々のタイミングで使用してもよい。

明細書および図面は、厳密ではなく、一例にすぎないと適宜みなされるべきである。しかしながら、添付の特許請求の範囲に記載のより広義の趣旨および範囲から逸脱することなく、追加、減算、削除、および他の変更ならびに変形がそれらに対してなされてもよいということは明白であろう。したがって、具体的な実施形態を説明したが、これらは限定を意図しない。様々な変更例および均等物は、添付の特許請求の範囲内である。

Claims

コンピュータにより実現される方法であって、
１つ以上のコンピュータシステムによって、１つ以上のプロセスによるヒープ使用量が閾値を上回っている時間の長さを判断するステップと、
前記時間の長さの間の前記１つ以上のプロセスのヒープ情報を決定するステップと含み、前記ヒープ情報は、前記時間の長さにおける複数の間隔の各々のヒープ使用量情報を含み、前記方法は、さらに、
前記時間の長さの間の前記１つ以上のプロセスのスレッド情報を決定するステップを含み、前記スレッド情報を決定するステップは、１つ以上のスレッドのクラスを決定するステップを含み、前記スレッド情報は、前記１つ以上のスレッドのクラスの各々について、前記複数の間隔の各々のスレッド強度情報を含み、前記方法は、さらに、
前記ヒープ情報を前記スレッド情報に相関させて、前記閾値を上回るヒープ使用量に対応する前記１つ以上のプロセスの１行以上のコードを特定するステップと、
前記１行以上のコードを特定することに応答して、前記１行以上のコードに関連する１つ以上のアクションを開始するステップとを含む、方法。
前記ヒープ情報は、前記複数の間隔の各々のヒープ使用量季節因子を含み、
前記スレッド情報は、前記１つ以上のスレッドのクラスの各々について、前記複数の間隔の各々のスレッド強度季節因子を含む、請求項１に記載の方法。
前記ヒープ情報を前記スレッド情報に相関させるステップは、
前記１つ以上のスレッドのクラスの各々について、前記複数の間隔のヒープ使用量季節因子と、スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子とに基づいて、前記スレッドのクラスと前記閾値を上回るヒープ使用量との相関度合いを決定するステップと、
前記１つ以上のスレッドのクラスから、前記閾値を上回るヒープ使用量に対する相関度合いが前記１つ以上のスレッドのクラスの中で最も高い所与のスレッドのクラスを選択するステップと、
前記所与のスレッドのクラスに基づいて、前記１行以上のコードを特定するステップとを含む、請求項２に記載の方法。
前記スレッドのクラスと前記閾値を上回るヒープ使用量との前記相関度合いを決定するステップは、
前記複数の間隔のヒープ使用量季節因子の平均を算出するステップと、
前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の平均を算出するステップと、
前記複数の間隔のヒープ使用量季節因子の分散を算出するステップと、
前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の分散を算出するステップと、
前記複数の間隔のヒープ使用量季節因子の平均、前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の平均、前記複数の間隔のヒープ使用量季節因子の分散、ならびに前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の分散に基づいて、前記相関度合いを算出するステップとを含む、請求項３に記載の方法。
前記所与のスレッドのクラスに属する前記１つ以上のプロセスの各スレッドが、前記１行以上のコードを実行する、請求項３に記載の方法。
前記時間の長さは、第１長さを有する期間の１つ以上のサイクルおよび第２長さを有する期間の１つ以上のサイクルにまたがるデータセット内に位置し、
前記第１長さを有する期間は、前記１つ以上のスレッドのクラスの各々の第１種別の平滑化後のヒープ使用量季節因子および第１種別の平滑化後のスレッド強度季節因子に各々が関連する第１の複数の季節に分割され、
前記第２長さを有する期間は、前記１つ以上のスレッドのクラスの各々の第２種別の平滑化後のヒープ使用量季節因子および第２種別の平滑化後のスレッド強度季節因子に各々が関連する第２の複数の季節に分割され、
前記複数の間隔の各々は、前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに対応付けられ、
前記複数の間隔の各々について、間隔の前記ヒープ使用量季節因子は、前記間隔が対応付けられた前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに関連する平滑化後のヒープ使用量季節因子に対応し、
前記複数の間隔の各々、前記１つ以上のスレッドのクラスの各々について、間隔の前記スレッドのクラスの前記スレッド強度季節因子は、前記間隔が対応付けられた前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに関連する前記スレッドのクラスの平滑化後のスレッド強度季節因子に対応する、請求項２に記載の方法。
前記第１種別の平滑化後のヒープ使用量季節因子は、
前記第１の複数の季節の各々について、前記第１の複数の季節のうちの季節の平均ヒープ使用量を、前記第１長さを有する期間の平均ヒープ使用量と比較することによって、前記第１種別のヒープ使用量季節因子を決定し、
前記第１種別のヒープ使用量季節因子の各々について、第１種別のヒープ使用量季節因子を正規化因子で除算して前記第１種別のくりこまれたヒープ使用量季節因子を取得し、
前記第１種別のくりこまれたヒープ使用量季節因子に第１スプライン関数を適用して前記第１種別の平滑化後のヒープ使用量季節因子を取得することによって、決定され、
前記第２種別の平滑化後のヒープ使用量季節因子は、
前記第２の複数の季節の各々について、前記第２の複数の季節のうちの季節の平均ヒープ使用量を、前記第２長さを有する期間の平均ヒープ使用量と比較することによって、前記第２種別のヒープ使用量季節因子を決定し、
前記第２種別のヒープ使用量季節因子の各々について、第２種別のヒープ使用量季節因子を正規化因子で除算して前記第２種別のくりこまれたヒープ使用量季節因子を取得し、
前記第２種別のくりこまれたヒープ使用量季節因子に第２スプライン関数を適用して前記第２種別の平滑化後のヒープ使用量季節因子を取得することによって、決定される、請求項６に記載の方法。
前記１つ以上のスレッドのクラスを決定するステップは、
前記１つ以上のプロセスの１つ以上のスレッドダンプを取得するステップを含み、前記スレッドダンプの各々は、前記１つ以上のプロセスが実行中に異なる時点で出力され、前記１つ以上のスレッドのクラスを決定するステップは、さらに、
前記１つ以上のスレッドダンプの１つ以上のスレッドの各々について、スレッドに対応するスタックトレースに基づいて前記スレッドを分類するステップとを含み、前記スタックトレースは、前記スレッドダンプが出力されたときに前記スレッドが実行するコードを示す、請求項２に記載の方法。
前記スタックトレースに基づいて前記スレッドを分類するステップは、
前記スタックトレースに含まれるスタックフレームの組合せに対応するスレッドのクラスが存在するかどうかを判断するステップと、
前記スタックトレースに含まれるスタックフレームの組合せに対応するスレッドのクラスが存在しないと判断することに応答して、前記スタックトレースに含まれるスタックフレームの組合せに対応する新しいスレッドのクラスを作成するステップと、
前記スタックトレースに含まれるスタックフレームの組合せに対応するスレッドのクラスに関連する１つ以上のカウンタをインクリメントするステップとを含む、請求項８に記載の方法。
前記１つ以上のスレッドのクラスの各々、前記複数の間隔の各々について、間隔の前記スレッド強度情報は、前記間隔を通じて実行中のスレッドのクラスに属するスレッドの平均数を示す、請求項１に記載の方法。
前記１つ以上のアクションは、
前記１行以上のコードに関連するアラートを生成するステップ、または、
前記１行以上のコードを最適化するステップ、の少なくとも一方を含む、請求項１に記載の方法。
前記１行以上のコードを最適化するステップは、使用されるヒープメモリの量を低減するまたは前記ヒープメモリの使用期間を減らすために前記１行以上のコードを修正するステップを含む、請求項１１に記載の方法。
１つ以上のプロセッサと、
前記１つ以上のプロセッサにアクセス可能なメモリとを備え、前記メモリは、１つ以上の命令を格納し、前記１つ以上の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
１つ以上のプロセスによるヒープ使用量が閾値を上回っている時間の長さを判断させ、
前記時間の長さの間の前記１つ以上のプロセスのヒープ情報を決定させ、前記ヒープ情報は、前記時間の長さにおける複数の間隔の各々のヒープ使用量情報を含み、前記１つ以上の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、さらに、
前記時間の長さの間の前記１つ以上のプロセスのスレッド情報を決定させ、前記スレッド情報を決定することは、１つ以上のスレッドのクラスを決定することを含み、前記スレッド情報は、前記１つ以上のスレッドのクラスの各々について、前記複数の間隔の各々のスレッド強度情報を含み、前記１つ以上の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、さらに、
前記ヒープ情報を前記スレッド情報に相関させて、前記閾値を上回るヒープ使用量に対応する前記１つ以上のプロセスの１行以上のコードを特定させ、
前記１行以上のコードを特定することに応答して、前記１行以上のコードに関連する１つ以上のアクションを開始させる、システム。
前記ヒープ情報は、前記複数の間隔の各々のヒープ使用量季節因子を含み、
前記スレッド情報は、前記１つ以上のスレッドのクラスの各々について、前記複数の間隔の各々のスレッド強度季節因子を含む、請求項１３に記載のシステム。
前記ヒープ情報を前記スレッド情報に相関させることは、
前記１つ以上のスレッドのクラスの各々について、前記複数の間隔のヒープ使用量季節因子と、スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子とに基づいて、前記スレッドのクラスと前記閾値を上回るヒープ使用量との相関度合いを決定することと、
前記１つ以上のスレッドのクラスから、前記閾値を上回るヒープ使用量に対する相関度合いが前記１つ以上のスレッドのクラスの中で最も高い所与のスレッドのクラスを選択することと、
前記所与のスレッドのクラスに基づいて、前記１行以上のコードを特定することとを含む、請求項１４に記載のシステム。
前記スレッドのクラスと前記閾値を上回るヒープ使用量との前記相関度合いを決定することは、
前記複数の間隔のヒープ使用量季節因子の平均を算出することと、
前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の平均を算出することと、
前記複数の間隔のヒープ使用量季節因子の分散を算出することと、
前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の分散を算出することと、
前記複数の間隔のヒープ使用量季節因子の平均、前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の平均、前記複数の間隔のヒープ使用量季節因子の分散、ならびに前記スレッドのクラスおよび前記複数の間隔のスレッド強度季節因子の分散に基づいて、前記相関度合いを算出することとを含む、請求項１５に記載のシステム。
前記時間の長さは、第１長さを有する期間の１つ以上のサイクルおよび第２長さを有する期間の１つ以上のサイクルにまたがるデータセット内に位置し、
前記第１長さを有する期間は、前記１つ以上のスレッドのクラスの各々の第１種別の平滑化後のヒープ使用量季節因子および第１種別の平滑化後のスレッド強度季節因子に各々が関連する第１の複数の季節に分割され、
前記第２長さを有する期間は、前記１つ以上のスレッドのクラスの各々の第２種別の平滑化後のヒープ使用量季節因子および第２種別の平滑化後のスレッド強度季節因子に各々が関連する第２の複数の季節に分割され、
前記複数の間隔の各々は、前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに対応付けられ、
前記複数の間隔の各々について、間隔の前記ヒープ使用量季節因子は、前記間隔が対応付けられた前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに関連する平滑化後のヒープ使用量季節因子に対応し、
前記複数の間隔の各々、前記１つ以上のスレッドのクラスの各々について、間隔の前記スレッドのクラスの前記スレッド強度季節因子は、前記間隔が対応付けられた前記第１の複数の季節のうちの１つまたは前記第２の複数の季節のうちの１つに関連する前記スレッドのクラスの平滑化後のスレッド強度季節因子に対応する、請求項１４に記載のシステム。
前記第１種別の平滑化後のヒープ使用量季節因子は、
前記第１の複数の季節の各々について、前記第１の複数の季節のうちの季節の平均ヒープ使用量を、前記第１長さを有する期間の平均ヒープ使用量と比較することによって、前記第１種別のヒープ使用量季節因子を決定し、
前記第１種別のヒープ使用量季節因子の各々について、第１種別のヒープ使用量季節因子を正規化因子で除算して前記第１種別のくりこまれたヒープ使用量季節因子を取得し、
前記第１種別のくりこまれたヒープ使用量季節因子に第１スプライン関数を適用して前記第１種別の平滑化後のヒープ使用量季節因子を取得することによって、決定され、
前記第２種別の平滑化後のヒープ使用量季節因子は、
前記第２の複数の季節の各々について、前記第２の複数の季節のうちの季節の平均ヒープ使用量を、前記第２長さを有する期間の平均ヒープ使用量と比較することによって、前記第２種別のヒープ使用量季節因子を決定し、
前記第２種別のヒープ使用量季節因子の各々について、第２種別のヒープ使用量季節因子を正規化因子で除算して前記第２種別のくりこまれたヒープ使用量季節因子を取得し、
前記第２種別のくりこまれたヒープ使用量季節因子に第２スプライン関数を適用して前記第２種別の平滑化後のヒープ使用量季節因子を取得することによって、決定される、請求項１７に記載のシステム。
前記１つ以上のアクションは、
前記１行以上のコードに関連するアラートを生成すること、または、
前記１行以上のコードを最適化すること、の少なくとも一方を含む、請求項１３に記載のシステム。
１つ以上の命令を格納する非一時的なコンピュータ読み取り可能な媒体であって、前記１つ以上の命令は、１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、
１つ以上のプロセスによるヒープ使用量が閾値を上回っている時間の長さを判断させ、
前記時間の長さの間の前記１つ以上のプロセスのヒープ情報を決定させ、前記ヒープ情報は、前記時間の長さにおける複数の間隔の各々のヒープ使用量情報を含み、前記１つ以上の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、さらに、
前記時間の長さの間の前記１つ以上のプロセスのスレッド情報を決定させ、前記スレッド情報を決定することは、１つ以上のスレッドのクラスを決定することを含み、前記スレッド情報は、前記１つ以上のスレッドのクラスの各々について、前記複数の間隔の各々のスレッド強度情報を含み、前記１つ以上の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに、さらに、
前記ヒープ情報を前記スレッド情報に相関させて、前記閾値を上回るヒープ使用量に対応する前記１つ以上のプロセスの１行以上のコードを特定させ、
前記１行以上のコードを特定することに応答して、前記１行以上のコードに関連する１つ以上のアクションを開始させる、非一時的なコンピュータ読み取り可能な媒体。