図面 (/)

技術 出現した関係におけるスタックセグメント強度の相関

出願人 オラクル・インターナショナル・コーポレイション
発明者 チャン,エリック・エス
出願日 2017年5月8日 (2年10ヶ月経過) 出願番号 2018-558656
公開日 2019年7月18日 (8ヶ月経過) 公開番号 2019-520630
状態 不明
技術分野
  • -
主要キーワード くりこみ 季節調整 滑移動 指数フィルタ トレンド線 計測コード 予測測定値 合成積
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年7月18日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (18)

課題・解決手段

新しく分類されたスタックフレームスタックセグメントの強度統計データを推定するために一連スレッドダンプ標本を逐次解析するための特定の方法を開示する。実施形態は、フィルタ状態に関連付けられたスタックセグメントの1つ以上の線形接続されたスタックフレームに沿った分岐点を検出できる。スタックセグメントの1つ以上の線形接続されたスタックフレームに沿った分岐点を検出すると、いくつかの実施形態は、スタックセグメントを、スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割できる。複数の新しいスタックセグメントは、当該スタックセグメントによって参照される。次に、実施形態は、スタックセグメントのフィルタ状態の少なくとも一部に基づいて、新しいスタックセグメントの各々のフィルタ状態を初期化できる。

概要

背景

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

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

概要

新しく分類されたスタックフレームスタックセグメントの強度統計データを推定するために一連スレッドダンプ標本を逐次解析するための特定の方法を開示する。実施形態は、フィルタ状態に関連付けられたスタックセグメントの1つ以上の線形接続されたスタックフレームに沿った分岐点を検出できる。スタックセグメントの1つ以上の線形接続されたスタックフレームに沿った分岐点を検出すると、いくつかの実施形態は、スタックセグメントを、スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割できる。複数の新しいスタックセグメントは、当該スタックセグメントによって参照される。次に、実施形態は、スタックセグメントのフィルタ状態の少なくとも一部に基づいて、新しいスタックセグメントの各々のフィルタ状態を初期化できる。

目的

プロバイダは、クラウドサービスがSLAに適合していることを確実にするために、自身が提供する

効果

実績

技術文献被引用数
- 件
牽制数
- 件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

コンピュータにより実現される方法であって、コンピュータによって、1つ以上のスタックトレースの少なくとも一部に基づいて、線形接続されたスタックフレームのセットを参照しているスタックセグメントフィルタ状態を決定するステップと、スタックトレースを受信するステップと、前記スタックトレースを受信すると、前記スタックトレースの少なくとも一部に基づいて、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出するステップと、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出すると、前記スタックセグメントを、前記スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割するステップとを含み、前記複数の新しいスタックセグメントは、前記スタックセグメントによって参照され、前記方法は、さらに、前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて、前記複数の新しいスタックセグメントに対応する複数のフィルタ状態を初期化するステップと、1つ以上の後続スタックトレースの少なくとも一部に基づいて、前記スタックセグメントのフィルタ状態および前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態の各々を別々に追跡するステップとを含む、方法。

請求項2

階層関係において、前記複数の新しいスタックセグメントの各々は子ノードであり、前記スタックセグメントは親ノードである、請求項1に記載のコンピュータにより実現される方法。

請求項3

前記スタックセグメントを前記複数の新しいスタックセグメントに分割するステップは、前記線形接続されたスタックフレームのセットのうちの前記分岐点に先行する線形接続されたスタックフレームの第1サブセットを参照する第1の新しいスタックセグメント、および前記線形接続されたスタックフレームのセットのうちの前記分岐点に続く線形接続されたスタックフレームの第2サブセットを参照する第2の新しいスタックセグメントを作成するステップと、前記第1の新しいスタックセグメントを第1の子ノードとして参照し、前記第2の新しいスタックセグメントを第2の子ノードとして参照するように、前記スタックセグメントを変更するステップとを含み、前記第1の新しいスタックセグメントおよび前記第2の新しいスタックセグメントは、前記スタックセグメントを前記親ノードとして参照する、請求項2に記載のコンピュータにより実現される方法。

請求項4

前記1つ以上のスタックトレースの少なくとも一部に基づいて前記スタックセグメントのフィルタ状態を決定するステップは、前記1つ以上のスタックトレースのうちの第1スタックトレースを受信するステップと、前記1つ以上のスタックトレースのうちの前記第1スタックトレースが前記線形接続されたスタックフレームのセットの各々を含むと観測するステップと、前記線形接続されたスタックフレームのセットを参照するように、前記スタックセグメントを作成するステップと、前記1つ以上のスタックトレースのうちの前記第1スタックトレース以外の前記1つ以上のスタックトレースの各々について、前記1つ以上のスタックトレースのうちの前記スタックトレースを受信するステップと、前記1つ以上のスタックトレースのうちの前記スタックトレースが前記線形接続されたスタックフレームのセットの各々を含む、または前記線形接続されたスタックフレームのセットのいずれも含まないと観測するステップと、前記1つ以上のスタックトレースのうちの前記スタックトレースの少なくとも一部に基づいて、前記スタックセグメントのフィルタ状態を更新するステップとを含む、請求項1に記載のコンピュータにより実現される方法。

請求項5

前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態を初期化するステップは、前記スタックセグメントのフィルタ状態を、前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態にコピーするステップを含む、請求項1に記載のコンピュータにより実現される方法。

請求項6

前記複数の新しいスタックセグメントの各々に含まれる前記スタックフレームのサブセットは、線形接続されたままである、請求項1に記載のコンピュータにより実現される方法。

請求項7

少なくとも1つのスタックトレースが第1スタックフレームおよび第2スタックフレームの両方を含むと観測され、前記第1スタックフレームおよび前記第2スタックフレームの一方しか含まないと観測されるスタックトレースがなかった場合、前記第1スタックフレームは、前記第2スタックフレームに線形接続され、別の少なくとも1つのスタックトレースが前記第1スタックフレームおよび前記第2スタックフレームの前記一方しか含まないと観測された場合、前記第1スタックフレームと前記第2スタックフレームは、線形接続されない、請求項1に記載のコンピュータにより実現される方法。

請求項8

前記フィルタ状態は、前記線形接続されたスタックフレームのセットが観測された回数、期間の異なる季節に各々が関連する、前記線形接続されたスタックフレームのセットの強度の1つ以上の測定値、前記線形接続されたスタックフレームのセットの強度の1つ以上の測定値のうちの1つに各々が関連付けられた1つ以上の季節因子、または、それらの組合せ、を含む、請求項1に記載のコンピュータにより実現される方法。

請求項9

前記1つ以上のスタックトレース、前記スタックトレース、および前記1つ以上の後続スタックトレースは、マルチスレッドプログラムの実行中に出力される1つ以上のスレッドダンプを介して取得される、請求項1に記載のコンピュータにより実現される方法。

請求項10

1つ以上のプロセッサと、前記1つ以上のプロセッサにアクセス可能メモリとを備え、前記メモリは、1つ以上の命令を格納し、前記1つ以上の命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、1つ以上のスタックトレースの少なくとも一部に基づいて、線形接続されたスタックフレームのセットを参照しているスタックセグメントのフィルタ状態を監視させ、スタックトレースを受信させ、前記スタックトレースを受信すると、前記スタックトレースの少なくとも一部に基づいて、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出させ、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出すると、前記スタックセグメントを、前記スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割させ、前記複数の新しいスタックセグメントは、前記スタックセグメントによって参照され、前記1つ以上の命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、さらに、前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて、前記複数の新しいスタックセグメントに対応する複数のフィルタ状態を初期化させ、1つ以上の後続スタックトレースの少なくとも一部に基づいて、前記スタックセグメントのフィルタ状態および前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態の各々を別々に追跡させる、システム

請求項11

階層関係において、前記複数の新しいスタックセグメントの各々は子ノードであり、前記スタックセグメントは親ノードである、請求項10に記載のシステム。

請求項12

前記スタックセグメントを前記複数の新しいスタックセグメントに分割することは、前記線形接続されたスタックフレームのセットのうちの前記分岐点に先行する線形接続されたスタックフレームの第1サブセットを参照する第1の新しいスタックセグメント、および前記線形接続されたスタックフレームのセットのうちの前記分岐点に続く線形接続されたスタックフレームの第2サブセットを参照する第2の新しいスタックセグメントを作成することと、前記第1の新しいスタックセグメントを第1の子ノードとして参照し、前記第2の新しいスタックセグメントを第2の子ノードとして参照するように、前記スタックセグメントを変更することとを含み、前記第1の新しいスタックセグメントおよび前記第2の新しいスタックセグメントは、前記スタックセグメントを前記親ノードとして参照する、請求項11に記載のシステム。

請求項13

前記1つ以上のスタックトレースの少なくとも一部に基づいて前記スタックセグメントのフィルタ状態を決定することは、前記1つ以上のスタックトレースのうちの第1スタックトレースを受信することと、前記1つ以上のスタックトレースのうちの前記第1スタックトレースが前記線形接続されたスタックフレームのセットの各々を含むと観測することと、前記線形接続されたスタックフレームのセットを参照するように、前記スタックセグメントを作成することと、前記1つ以上のスタックトレースのうちの前記第1スタックトレース以外の前記1つ以上のスタックトレースの各々について、前記1つ以上のスタックトレースのうちの前記スタックトレースを受信することと、前記1つ以上のスタックトレースのうちの前記スタックトレースが前記線形接続されたスタックフレームのセットの各々を含む、または前記線形接続されたスタックフレームのセットのいずれも含まないと観測することと、前記1つ以上のスタックトレースのうちの前記スタックトレースの少なくとも一部に基づいて、前記スタックセグメントのフィルタ状態を更新することとを含む、請求項10に記載のシステム。

請求項14

前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態を初期化することは、前記スタックセグメントのフィルタ状態を、前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態にコピーすることを含む、請求項10に記載のシステム。

請求項15

前記複数の新しいスタックセグメントの各々に含まれる前記スタックフレームのサブセットは、線形接続されたままである、請求項10に記載のシステム。

請求項16

少なくとも1つのスタックトレースが第1スタックフレームおよび第2スタックフレームの両方を含むと観測され、前記第1スタックフレームおよび前記第2スタックフレームの一方しか含まないと観測されるスタックトレースがなかった場合、前記第1スタックフレームは、前記第2スタックフレームに線形接続され、別の少なくとも1つのスタックトレースが前記第1スタックフレームおよび前記第2スタックフレームの前記一方しか含まないと観測された場合、前記第1スタックフレームと前記第2スタックフレームは、線形接続されない、請求項10に記載のシステム。

請求項17

前記フィルタ状態は、前記線形接続されたスタックフレームのセットが観測された回数、期間の異なる季節に各々が関連する、前記線形接続されたスタックフレームのセットの強度の1つ以上の測定値、前記線形接続されたスタックフレームのセットの強度の1つ以上の測定値のうちの1つに各々が関連付けられた1つ以上の季節因子、または、それらの組合せ、を含む、請求項10に記載のシステム。

請求項18

前記1つ以上のスタックトレース、前記スタックトレース、および前記1つ以上の後続スタックトレースは、マルチスレッドプログラムの実行中に出力される1つ以上のスレッドダンプを介して取得される、請求項10に記載のシステム。

請求項19

1つ以上の命令を格納する非一時的なコンピュータ読み取り可能な媒体であって、前記1つ以上の命令は、1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、1つ以上のスタックトレースの少なくとも一部に基づいて、線形接続されたスタックフレームのセットを参照しているスタックセグメントのフィルタ状態を監視させ、スタックトレースを受信させ、前記スタックトレースを受信すると、前記スタックトレースの少なくとも一部に基づいて、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出させ、前記スタックセグメントの前記線形接続されたスタックフレームのセットに沿った分岐点を検出すると、前記スタックセグメントを、前記スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割させ、前記複数の新しいスタックセグメントは、前記スタックセグメントによって参照され、前記1つ以上の命令は、前記1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、さらに、前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて、前記複数の新しいスタックセグメントに対応する複数のフィルタ状態を初期化させ、1つ以上の後続スタックトレースの少なくとも一部に基づいて、前記スタックセグメントのフィルタ状態および前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態の各々を別々に追跡させる、非一時的なコンピュータ読み取り可能な媒体。

請求項20

前記スタックセグメントのフィルタ状態の少なくとも一部に基づいて前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態を初期化することは、前記スタックセグメントのフィルタ状態を、前記複数の新しいスタックセグメントに対応する前記複数のフィルタ状態にコピーすることを含む、請求項19に記載の非一時的なコンピュータ読み取り可能な媒体。

技術分野

0001

関連出願の相互参照
本願は、2017年5月5日に出願され、「Correlation of Stack Segment Intensity in Emergent Relationships(出現した関係におけるスタックセグメント強度の相関)」と題された第15/588,521号 、2016年5月9日に出願され、「Correlation of Thread Intensity and Heap Usage to Identify Heap-Hoarding Stack Traces(ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関)」と題された米国仮出願第62/333,786号、2016年5月9日に出願され、「Memory Usage Determination Techniques(メモリ使用量判断技術)」と題された米国仮出願第62/333,798号、2016年5月9日に出願され、「Compression Techniques for Encoding Stack Traces Information(スタックトレース情報を符号化するための圧縮技術)」と題された米国仮出願第62/333,804号、2016年5月9日に出願され、「Correlation of Stack Segment Intensity in Emergent Relationships(出現した関係におけるスタックセグメント強度の相関)」と題された米国仮出願第62/333,811号、2016年5月9日に出願され、「Systems and Methodsof Stack Trace Analysis(スタックトレース分析のシステムおよび方法)」と題された米国仮出願第62/333,809号、2016年5月23日に出願され、「Characterization of Segments of Time-Series(時系列セグメント特徴づけ)」と題された米国仮出願第62/340,256号、2017年5月5日に出願され、「Correlation of Thread Intensity and Heap Usage to Identify Heap-Hoarding Stack Traces(ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関)」と題された米国通常出願第15/588,531号、2017年5月5日に出願され、「Memory Usage Determination Techniques(メモリ使用量判断技術)」と題された米国通常出願第15/588,526号、および、2017年5月5日に出願され、「Compression Techniques for Encoding Stack Trace Information(スタックトレース情報を符号化するための圧縮技術)」と題された米国通常出願第15/588,523の国際出願であり、米国特許法第119条(e)の下で、これらの出願に基づく優先権の利益を主張するものであり、これらの出願のすべてを、あらゆる目的のために引用により本明細書に援用する。

0002

本願は、本出願と同時に提出した下記の出願の関連出願であり、これらの出願のすべてを、あらゆる目的のために引用により本明細書に援用する。

0003

(1)2017年5月8日に出願され、「CORRELATION OF THREAD INTENSITY ANDHEAPUSAGETO IDENTIFY HEAP-HOARDING STACKTRACES(ヒープをため込んでいるスタックトレースを特定するための、スレッド強度とヒープ使用量との相関)」と題されたPCT通常特許出願PCT/US2017/031586号(代理人整理番号:088325−1047566(175200PC))。

0004

(2)2017年5月8日に出願され、「MEMORY USAGEDETERMINATION TECHNIQUES(メモリ使用量判断技術)」と題されたPCT通常特許出願PCT/US2017/031589号(代理人整理番号:088325−1047576(175210PC))。

0005

(3)2017年5月8日に出願され、「COMPRESSION TECHNIQUES FOR ENCODING STACKTRACEINFORMATION(スタックトレース情報を符号化するための圧縮技術)」と題されたPCT通常特許出願PCT/US2017/031593号(代理人整理番号:088325−1047578(175220PC))。

背景技術

0006

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

0007

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

発明が解決しようとする課題

0008

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

0009

概要
新しく分類されたスタックフレームのスタックセグメントの強度統計データを推定するために一連のスレッドダンプ標本を逐次解析するための特定の方法を開示する。

課題を解決するための手段

0010

一実施形態は、方法を対象とする。この方法は、コンピュータによって、1つ以上のスタックトレースの少なくとも一部に基づいて、線形接続されたスタックフレームのセットを参照しているスタックセグメントのフィルタ状態を決定するステップと、スタックトレースを受信するステップと、スタックトレースを受信すると、スタックトレースの少なくとも一部に基づいて、スタックセグメントの線形接続されたスタックフレームのセットに沿った分岐点を検出するステップと、スタックセグメントの線形接続されたスタックフレームのセットに沿った分岐点を検出すると、スタックセグメントを、スタックフレームのサブセットを各々が含む複数の新しいスタックセグメントに分割するステップとを含み、複数の新しいスタックセグメントは、スタックセグメントによって参照され、方法は、さらに、スタックセグメントのフィルタ状態の少なくとも一部に基づいて、複数の新しいスタックセグメントに対応する複数のフィルタ状態を初期化するステップと、1つ以上の後続スタックトレースの少なくとも一部に基づいて、スタックセグメントのフィルタ状態および複数の新しいスタックセグメントに対応する複数のフィルタ状態の各々を別々に追跡するステップとを含み得る。

0011

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

図面の簡単な説明

0012

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

実施例

0013

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

0014

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

0015

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

0016

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

0017

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

0018

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

0019

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

0020

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

0021

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

0022

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

0023

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

0024

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

0025

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

0026

スレッドが実行すると、スタックセグメントBはスタックセグメントEを呼び出し、スタックセグメントEはスタックセグメントFを呼び出す。次に、標本4を取ることによって、スタックセグメントA、B、E、およびFがスタック上にあったことを示す第4スタックトレースができる。スタックセグメントF、E、およびBは、互いを返す。次に、標本5を取ることによって、スタック上にスタックセグメントAしかないことを示す第5スタックトレースができる。スタックセグメントAは、スタックセグメントCをスタック上にのせる。スタックセグメントCが戻る前に標本6および7が取られ、その結果、スタックセグメントAおよびCがスタック上にあることを示す第6スタックトレースおよび第7スタックトレースができる。最終的に、スタックセグメントCが戻り、スタック上にはスタックセグメントAしか残らない。スタックセグメントAに関連するメソッドが戻ったとき、スレッドは実行を終了する。

0027

図2に示すように、呼び出しコンテキストのツリー200は、標本抽出間隔に対するスタックセグメントA〜Fの実行時間を表す。ノード202は、7つの標本すべてにおいてスタックセグメントAが観測されたことを示す。ノード204は、7つの標本のうちの4つおいてスタックセグメントBが観測されたことを示す。ノード206は、7つの標本のうちの2つにおいてスタックセグメントCが観測されたことを示す。ノード208は、7つの標本のうちの2つにおいてスタックセグメントDが観測されたことを示す。ノード210は、7つの標本のうちの1つにおいてスタックセグメントEが観測されたことを示す。ノード212は、7つの標本のうちの1つにおいてスタックセグメントFが観測されたことを示す。スレッド100の総実行時間が標本抽出間隔の存続期間のほぼ10倍であるので、各スタックセグメントの観測回数は、スタックセグメントの実行時間と密接な相関関係にあるだろう。たとえば、スタックセグメントBが4回観測されたので、スタックセグメントBの相対実行時間は、少なくとも標本抽出間隔の4倍であると推測できる。

0028

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

0029

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

0030

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

0031

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

0032

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

0033

しかしながら、より一般的には、制御システムは、1つ以上のスタックフレームを、先に観測されたスタックトレースと共有するスタックトレース観測することができる。図1に戻ると、たとえば、制御システムが観測した第1スタックトレースが{(A,B,D)}(すなわち、標本1または標本2に含まれるスタックトレース)であるとする。このスタックトレースは、スタックセグメントA、B、およびDに含まれるスタックフレームを含む。制御システムは、スレッドクラス{(A,B,D)}を初期化し、スタックセグメントA、B、およびDに含まれるスタックフレームを含むと観測されるすべてのスレッドを分類してもよい。次に、制御システムによって観測された第2スタックトレースが{(A,C)}(すなわち、標本6または標本7に含まれるスタックトレース)であるとする。この点については、制御システムは、第1スタックトレースと第2スタックトレースは互いに異なるが、第1スタックトレースと第2スタックトレースは、スタックセグメントAに含まれるスタックフレームのすべてを共有していると判断してもよい。これによって、スタックセグメントAにおいて分岐点ができる。これに応答して、制御システムは、スレッドクラス{(A,C)}を初期化して、スタックセグメントAおよびCをコールスタック上に含むすべてのスレッドを分類してもよい。

0034

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

0035

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

0036

上記例に戻ると、第1スタックトレースの観測の後、第2スタックトレースの観測の前、スレッドクラス{(A,B,D)}は、1つの二分木からなる組に対応してもよい。第1スタックトレース内のフレームのシーケンス全体が1つのスタックセグメントと考えられるので、当該1つの二分木は、スタックセグメント(A,B,D)を表す1つの根ノードを含んでもよい。第2スタックトレースの観測の後、組は、まだ1つの二分木しか含んでいないだろう。しかしながら、ここで、二分木は、スタックセグメント(A,B,D)を表す根ノードと、スタックセグメント(A)を表す根ノードの第1子ノードと、スタックセグメント(B,D)を表す根ノードの第2子ノード、という3つの別々のノードを含んでもよい。トレースシグネチャとセグメントシグネチャとを合成する処理については、図4図6を参照して以下にさらに詳細に説明する。

0037

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

0038

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

0039

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

0040

A.スレッド強度の季節変動

0041

0042

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

0043

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

0044

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

0045

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

0046

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

0047

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

0048

0049

スタックトレースの例では、Java Database Connectivity(JDBC)ドライバのスタックセグメント(すなわち、「oracle.jdbc.driver…」を含んだ2つのスタックフレーム)下のスタックフレーム「oracle mdscore MetadataObject getBaseMO」は、Meta Data Service(MDS)ライブラリが当該JDBCスタックセグメントに対応するJDBC動作を呼び出すことを示す。MDSライブラリのスタックセグメント(すなわち、「oracle.mds…」を含んだ3つのスタックフレーム)下のスタックフレーム「oracle adf model servlet ADFBindingFilter doFilter」は、MDS動作がApplication Development Framework(ADF)動作によって呼び出されることを示す。このスタックトレースの下部のWebLogicスタックセグメント(すなわち、「weblogic…」を含んだ4つのスタックフレーム)が示すように、ADF動作は、Hypertext Transfer Protocol(HTTP)Servletリクエストによって呼び出される。

0050

例として、2レベルハフマン符号化法を用いて上記スタックトレースを符号化して圧縮することができ、その結果、このスタックトレース例を表すコンパクト符号のシーケンスができる。第1レベルでは、圧縮ツール(たとえば、gzip)が、「ServletRequestImpl.java」および「weblogic.servlet.internal.ServletRequestImpl.run」など、スタックトレース内の部分文字列を検出して、これらの部分文字列がどれだけ頻繁にスタックトレースに存在するかに応じて部分文字列のハフマン符号を導出できる。圧縮比を上げるためには、より頻繁に存在する部分文字列に、より短いハフマン符号を割り当てればよい。第1レベルの圧縮の後、圧縮されたスタックトレースは、ハフマン符号から部分文字列を復元するために使用され得る符号化辞書メタデータとして含んでもよい。

0051

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

0052

C.データ構造の例
分類シグネチャは、1つ以上のオブジェクト型を介してメモリで表されてもよい。具体的には、いくつかの実施形態は、ThreadClassificationInfoオブジェクトを用いてスレッドクラスの分類シグネチャ(すなわち、トレースシグネチャ)を表し、SegmentInfoオブジェクトを用いてスレッドセグメントの分類シグネチャ(すなわち、セグメントシグネチャ)を表し、StackFrameInfoオブジェクトを用いてスタックセグメント内の線形接続されたスタックフレームに含まれる各要素を表し、SeasonalTrendInfoオブジェクトを用いてスレッドクラスまたはスレッドセグメントの強度統計データをカプセル化して追跡してもよい。

0053

ThreadClassificationInfoオブジェクト、SegmentInfoオブジェクト、StackFrameInfoオブジェクト、およびSeasonalTrendInfoオブジェクトを定義するクラス/インタフェース定義の例を以下に示す。

0054

0055

上記定義から分かるように、各ThreadClassificationInfoオブジェクト、SegmentInfoオブジェクト、およびStackFrameInfoオブジェクトは、一意の識別子(すなわち、ID)と、名称と、同じ型(たとえば、同じスレッドクラス、同じスレッドセグメント、同じ型のスタックフレーム)のオブジェクトが最新のスレッドダンプにおいて観測された回数(すなわち、numOfOccur)を追跡するカウンタと、同じ型のオブジェクトがすべてのスレッドダンプにおいて観測された回数を追跡する別のカウンタとを含む。

0056

ThreadClassificationInfoオブジェクトは、SegmentInfoオブジェクトのリストと、SeasonalTrendInfoオブジェクトとを含み得る。この点については、ThreadClassificationInfoが二分木からなる組に対応し得るのに対して、SegmentInfoオブジェクトのリストは、二分木を構成するノードに対応する。SeasonalTrendInfoオブジェクトは、ThreadClassificationInfoオブジェクトが表すスレッドクラスに関する強度統計データ(たとえば、フィルタ状態)を記録してもよい。

0057

SegmentInfoオブジェクトは、StackFrameInfoオブジェクトのリストと、第1の子であるSegmentInfoオブジェクト(すなわち、firstSegment)と、第2の子であるSegmentInfoオブジェクト(すなわち、secondSegment)と、結合(coalescing)(すなわち、親である)SegmentInfoオブジェクト(すなわち、coalescingSegment)と、前節の兄弟であるSegmentInfoオブジェクト(すなわち、前節点)のリストと、次節の兄弟であるSegmentInfoオブジェクト(すなわち、次節点)のリストと、SeasonalTrendInfoオブジェクトとを含み得る。この点については、SegmentInfoオブジェクトは、スタックセグメントに対応し得る。SegmentInfoオブジェクトが葉ノードに対応する場合、StackFrameInfoオブジェクトのリストは、スタックセグメントに含まれる線形接続されたスタックフレームに対応してもよい。SegmentInfoオブジェクトが分岐点に隣接する場合、兄弟であるSegmentInfoオブジェクトは、分岐点の反対側のスタックセグメントに対応し得るのに対して、結合SegmentInfoオブジェクトは、当該スタックセグメントおよび兄弟スタックセグメントを含む親スタックセグメントに対応し得る。SegmentInfoオブジェクトが葉ノードに対応しない場合、子であるSegmentInfoオブジェクトは、スタックセグメントにおいて分岐点が発見された時に作成されたスタックセグメントのサブセグメントに対応し得る。SeasonalTrendInfoオブジェクトは、SegmentInfoオブジェクトが表すスレッドセグメントに関する強度統計データを記録してもよい。

0058

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

0059

新しいSegmentInfoノードの各々は、セグメントの一部においてStackFrameInfoオブジェクトの結合ノードになる。特定の実施形態は、StackFrameInfoオブジェクトのcoalescingSegmentを、各StackFrameInfoオブジェクトが適切な結合SegmentInfoノードを参照するように、対応付けて更新できる。この2つの新しいSegmentInfoノードは、左兄弟ノードと右兄弟ノードとして表される。また、この2つの新しいSegmentInfoノードは、元のSegmentInfoノードの子ノードにもなり、当該元のSegmentInfoノードは、これら2つの新しいSegmentInfoノードの親になる。親であるSegmentInfoノードは、2つの新しいSegmentInfoノードの結合ノードになり得る。

0060

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

0061

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

0062

各SegmentInfoノードは、SegmentInfoノードが表すスレッド(サブ)クラスの強度統計データを追跡するためのSeasonalTrendInfoオブジェクトを含んでもよい。SegmentInfoノードを2つの新しい子であるSegmentInfoノードに分割する際、いくつかの実施形態は、SegmentInfoノードのSeasonalTrendInfoオブジェクトをクローン作成して2つの新しいSeasonalTrendInfoオブジェクトを作成し、子であるSegmentInfoノードの各々に1つのSeasonalTrendInfoオブジェクトをセットすることができる。

0063

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

0064

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

0065

StackFrameInfoオブジェクトは、1つ以上の前節のStackFrameInfoオブジェクトおよび/または1つ以上の次節のStackFrameInfoオブジェクト(すなわち、前節点および次節点)と、結合SegmentInfoオブジェクト(すなわち、coalescingSegment)と、StackFrameInfoオブジェクト(すなわち、classMethodLineNumber)が参照するコードを識別する情報とを含み得る。StackFrameInfoオブジェクトが分岐点に隣接しない場合、StackFrameInfoオブジェクトは、1つの前節点であるスタックフレームと1つの次節点であるスタックフレームとに線形接続することができる。StackFrameInfoオブジェクトは、含んでいるSegmentInfoオブジェクトを、メンバ変数coalescingSegmentによって参照することができる。

0066

最新のスレッドダンプを処理する時が来ると、ThreadClassificationInfoオブジェクト、SegmentInfoオブジェクト、およびStackFrameInfoオブジェクトごとのメンバ変数numOfOccurは、0にリセットされ得る。スレッドダンプから得られた各スタックトレースは、スタックトレースの下から上に構文解析されてもよい。第1レベルのハフマン符号化法を適用して当該スタックトレースを圧縮した後、スタックトレースの各行は、StackFrameInfoオブジェクトに構文解析されてもよい。StackFrameInfoオブジェクトのリストをSegmentInfoオブジェクトのリストに構文解析した後、いくつかの実施形態は、SegmentInfoオブジェクトの一致するリストを含むThreadClassificationInfoオブジェクトにSegmentInfoオブジェクトのリストを照合しようと試みてもよい。このようなThreadClassificationInfoオブジェクトが存在しない場合、いくつかの実施形態は、SegmentInfoオブジェクトのリストを表すための新しいThreadClassificationInfoオブジェクトを登録してもよい。その後、次に、いくつかの実施形態は、一致する/新しいThreadClassificationInfoオブジェクトのnumOfOccurメンバ変数およびtotalNumOfOccurメンバ変数、ならびに当該一致する/新しいThreadClassificationInfoオブジェクトに含まれる各SegmentInfoオブジェクトおよびStackFrameInfoオブジェクトを更新してもよい。なお、SegmentInfoノードが葉レベルのノードである場合、当該ノードのnumOfOccurメンバ変数は、SegmentInfoノードに含まれる各StackFrameInfo要素のnumOfOccurメンバ変数と同等である。

0067

次に、いくつかの実施形態は、関連するSeasonalTrendInfoオブジェクトにカプセル化された強度の統計的測定値を更新できる。具体的には、いくつかの実施形態は、含んでいるThreadClassificationInfoオブジェクトまたはSegmentInfoオブジェクトのnumOfOccurメンバ変数にrawMeasureをセットすることによって、各SeasonalTrendInfoオブジェクトに含まれるrawMeasureメンバ変数を更新してもよい。なお、いくつかの実施形態では、rawMeasureは、N個のスレッドダンプごとに更新されればよく、この場合、SeasonalTrendInfoオブジェクトのrawMeasureは、Nで除算された対応するnumOfOccurにセットされる。いくつかの実施形態では、このような実施形態は、関連するThreadClassificationInfoオブジェクトまたは関連するSegmentInfoオブジェクトのnumOfOccurメンバ変数がゼロでない場合にのみ、SeasonalTrendInfoオブジェクトのrawMeasureメンバ変数を更新してもよい。numOfOccurメンバ変数がゼロでない場合、SeasonalTrendInfoオブジェクトのrawMeasureは、Nで除算されたnumOfOccurの値にセットされる。ここで、Nは、rawMeasureが最後に更新されてからのスレッドダンプの数である。このような実施形態では、メソッドは、numOfOccurがゼロであるときのケースを、使用可能な測定値がないかのように扱う。この点については、使用可能な測定値がない場合、rawMeasureは更新されない。言い換えると、このような実施形態は、rawMeasure「N」が最後に更新されてからのスレッドダンプの数を追跡する。スレッド強度の測定値は、不規則な時系列に対応してもよい。なお、不規則な間隔のための指数フィルタ(たとえば、上述したホルトの二重指数およびウィンターの3重指数フィルタ)は、rawMeasureを効果的にフィルタリングし、季節変動が除去された(de-seasonalized)測定値および季節因子を、不規則な間隔で行われた一連の測定から得ることができる。

0068

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

0069

D.分類シグネチャの生成の例
図3は、いくつかの実施形態に係る、一定期間にわたる仮想マシン300のスレッドダンプの例を示す図である。図1の標本抽出間隔が100ミリ秒〜1秒であるランタイムプロファイリングとは対照的に、図3の制御システムが採用する標本抽出間隔は、標本抽出のオーバヘッドを低減するために、さらに長くてもよい(たとえば、20秒〜1分の間)。図3に示すように、2〜3つの標本抽出間隔内で、仮想マシン300内で動作中のプロセスは、スレッド302、304、306、308、310、および312を生成する。スレッド302〜312の各々は、動作中に別のコールスタックに関連付けられるので、スレッドダンプが出力されたときにスタックトレースを出力することができる。図3は、スレッドダンプN、スレッドダンプN+1、およびスレッドダンプN+2という、全部で3つの出力されるスレッドダンプを表す。

0070

図3は、3つの連続したスレッドダンプにおいて(A,B,D)、(A,B,D)、(A,C)、(A,B,E)の順序で観測される3つの異なる型のスタックトレースを示す。スタックトレース(A,B,D)は、2回観測される。スレッドダンプNが出力される前に、スレッド302が生成されて動作を開始する。スレッドダンプNが出力されると、スレッド302に関して、スタックトレース(A,B,D)が観測される。なお、スタックセグメントA、スタックセグメントB、およびスタックセグメントDはまだ識別されていないが、説明を簡単にするため、図3に示す例の初めから終わりまでスタックセグメントの名前を使用する。スレッドダンプNが出力された後に1つの標本抽出間隔が経過すると、スレッド302が終了し、スレッド306および308が生成されている間にスレッド304が生成されて、標本抽出されることなく終了する。スレッドダンプN+1が出力されると、スレッド308がスタックトレース(A,B,D)を出すのに対して、スレッド310は、スタックトレース(A,C)を出す。スレッドダンプN+1が出力された後に別の標本抽出間隔が経過すると、スレッド306および308が終了し、スレッド310が生成されて、標本抽出されることなく終了し、スレッド312が生成される。スレッドダンプN+2が出力されると、スレッド312は、スタックトレース(A,B,E)を出す。図3から分かるように、(A,B,D)スレッド型は、観測される最初の型のスレッドであり、(A,B,D)スレッド型の強度は、(A,C)または(A,B,E)スレッド型よりも大きい。

0071

スレッドダンプNの後、制御システムは、1つのSegmentInfo(A,B,D)ノードをスタックトレース(A,B,D)の分類シグネチャとして登録できる。次に、制御システムは、SeasonalTrendInfo(A,B,D)オブジェクトをSegmentInfo(A,B,D)ノードに関連付けて、このノードによってカプセル化された状態を更新してもよい。

0072

SegmentInfo(A,B,D).numOfOccur = 1.
SegmentInfo(A,B,D).totalNumOfOccur = 1.
図4は、スタックトレース(A,B,D)に応答して登録された1つの分類シグネチャ450を含む分類シグネチャ400のセットを示す図である。図4から分かるように、分類シグネチャ450は、SegmentInfo(A,B,D)に対応する1つのノード402を含む。SegmentInfo(A,B,D)は、スタックトレースのすべてのスタックフレームa1〜d3の結合ノードとして示されている。

0073

スレッドダンプN+1においてスタックトレース(A,B,D)が再び観測された場合、制御システムは、SegmentInfo(A,B,D)ノードを、以下のように更新してもよい。

0074

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

0075

いくつかの実施形態では、制御システムは、下記のように、SeasonalTrendInfo(A,B,D)オブジェクトをクローン作成して、ノードSegmentInfo(A)およびSegmentInfo(B,D)のSeasonalTrendInfo(A)オブジェクトおよびSeasonalTrendInfo(B,D)オブジェクトをそれぞれ作成し、SegmentInfo(C)の新しいSeasonalTrendInfo(C)を作成してもよい。

0076

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

0077

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

SegmentInfo(C).numOfOccur = 1
SegmentInfo(C).totalNumOfOccur = 1
図5は、分類シグネチャ450と、スタックトレース(A,C)を初めて観測したことに応答して生成された新しい分類シグネチャ550とを含む、分類シグネチャ500のセットを示す図である。図5から分かるように、ここで、分類シグネチャ450は、ノード402、ノード502、およびノード504という3つのノードを含む。ノード402は、SegmentInfo(A,B,D)に対応し、これは、ノード502およびノード504の結合ノードである。ノード502は、SegmentInfo(A)に対応し、スタックフレームa1〜a3を結合する。ノード504は、SegmentInfo(B,D)に対応し、スタックフレームb1〜d3を結合する。分類シグネチャ550は、スタックフレームa1〜a3を結合するものとして示されるSegmentInfo(A)に対応するノード506、および、スタックフレームc1〜c3を結合するものとして示されるSegmentInfo(C)に対応するノード508という2つのノードを含む。

0078

スレッドダンプN+2においてスタックトレース(A,B,E)が初めて観測された場合、制御システムは、スタックセグメント(B,D)内のスタックフレームのセット全体はもはや線形接続されていないと判断する。ここで、「B」で表されるスタックフレームのセットのうちの最後のスタックフレームと「D」で表されるスタックフレームのセットのうちの最初のスタックフレームとの間に分岐点が存在する。なぜならば、どのようなスタックトレースにおいても、最後のスタックフレームに続く次のスタックフレームは、(1)(D)のうちの最初のスタックフレーム、または(2)「E」で表されるスタックフレームのセットのうちの最初のスタックフレームであるからである。したがって、制御システムは、ノードSegmentInfo(B)およびSegmentInfo(D)を作成して、これら2つのノードをSegmentInfo(B,D)の子ノードに割り当てることによって、スタックセグメント(B,D)をスタックセグメント(B)とスタックセグメント(D)とに分割してもよい。スタックトレース(A,B,E)については、制御システムは、ノードSegmentInfo(E)を作成することによってスタックセグメント「E」を初期化し、SegmentInfo(A)、SegmentInfo(B)、およびSegmentInfo(E)をスタックトレース(A,B,E)の分類シグネチャとして含む順序組を登録してもよい。

0079

いくつかの実施形態では、制御システムは、下記のように、SeasonalTrendInfo(B,D)オブジェクトをクローン作成して、ノードSegmentInfo(B)およびSegmentInfo(D)のSeasonalTrendInfo(B)オブジェクトおよびSeasonalTrendInfo(D)オブジェクトをそれぞれ作成し、SegmentInfo(E)の新しいSeasonalTrendInfo(E)を作成してもよい。

0080

SeasonalTrendInfo(B) <-SeasonalTrendInfo(B,D)
SeasonalTrendInfo(D) <-SeasonalTrendInfo(B,D)
SeasonalTrendInfo(E) <- new SeasonalTrendInfo
また、制御システムは、上記SegmentInfoノードを、以下のように更新してもよい。

0081

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

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

SegmentInfo(E).numOfOccur = 1
SegmentInfo(E).totalNumOfOccur = 1
図6は、分類シグネチャ450および550と、スタックトレース(A,B,E)に応答して生成された新しい分類シグネチャ650とを含む、分類シグネチャ600を示す図である。図6から分かるように、ここで、分類シグネチャ450は、ノード402、ノード502、ノード504、ノード602、およびノード604という5つのノードを含む。ノード504は、SegmentInfo(B,D)に対応し、これは、ノード602とノード604との結合ノードである。ノード602は、SegmentInfo(B)に対応し、スタックフレームb1〜b3を結合する。ノード604は、SegmentInfo(D)に対応し、これは、スタックフレームd1〜d3の結合ノードである。分類シグネチャ550は変更されていない。分類シグネチャ650は、スタックフレームa1〜a3を結合するものとして示されるSegmentInfo(A)に対応するノード606、スタックフレームb1〜b3を結合するものとして示されるSegmentInfo(B)に対応するノード608、およびスタックフレームe1〜e3を結合するものとして示されるSegmentInfo(E)に対応するノード610という3つのノードを含む。

0082

図6に示すように、スタックトレース(A,B,D)の分類シグネチャは、分類シグネチャ450の根にある1つのSegmentInfoノードから構成され得る。すなわち、強度が最も高いスタックトレースであるスタックトレース(A,B,D)は、最もコンパクトな表現を有する。一方では、スタックトレース(A,C)には、2つの順序ノード(A)および(C)を有する2番目に短い分類シグネチャが割り当てられている。最後に検出されたスタックトレース(A,B,E)には、3つの順序ノード(A)、(B)、および(E)を有する3番目に短い分類シグネチャが割り当てられている。図4図6に示すように、ThreadClassificationInfoオブジェクトは、SegmentInfoノードからなる組に対応してもよく、1つのSegmentInfoノードは、その他のSegmentInfoノードおよび/またはその他のStackFrameInfoオブジェクトのセットからなる二分木(またはバイナリである部分木)を参照してもよい。ThreadClassificationInfoオブジェクト、SegmentInfoノード、およびStackFrameInfoオブジェクトは、合わせて、生成文法を構成してもよい。

0083

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
上記から分かるように、個々のスタックフレームai、bi、ci、di、eiが文法終端であるのに対して、SegmentInfoノードは、非終端である。いくつかの実施形態は、スタックトレースのスタックフレームを、スタックトレースの下から上に(下記の表記法において左から右の方向に)構文解析できる。

0084

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)を使用
上記から分かるように、いくつかの実施形態は、上向き構文解析によってスタックフレームを解析できる。上向き構文解析は、シフト還元構文解析または左から右への「LR」構文解析と同様であり得る。この解析には、木の葉から根に向かって解析を進めていくことによってスタックトレースの解析木を構成するために、スタックフレームおよびSegmentInfoノードをシフト還元することが必要になり得る。いくつかの実施形態は、スレッドのスタックトレースの先の出現についての解析木を合成し、別の出現のスレッドのスタックトレースを、同じ解析木に還元する(すなわち、シフト還元構文解析、左から右に読む「LR」構文解析)ことによって解析する。分類木の各ノードは、スタックトレースのクラスのコンパクトラベルで有り得、分類木の根は、スレッドのクラスのコンパクトラベルで有り得る。

0085

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

0086

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

0087

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

0088

判断706において、実施形態は、別のスタックトレースを解析する必要があるかどうかを判断する。必要がない場合、フローチャートは、ステップ716で終了する。具体的には、スレッドダンプのスタックトレースのすべてが1つ以上の監視プロセスによって解析されると、いくつかの実施形態は、1つ以上のオブジェクトによってメモリにカプセル化された強度統計データを更新してもよい。たとえば、スレッドダンプからどのような種類のスタックトレースが得られたかに基づいて、1つ以上のSeasonalTrendInfoオブジェクトのメンバ変数(たとえば、rawMeasure、rawDeseasonalizedMeasure、smoothedWeekdaySeasonalFactor、および/またはsmoothedWeekendSeasonalFactor)が更新されてもよい。

0089

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

0090

判断710において、このようなトレース(すなわち、分類)シグネチャが存在する場合、フローチャートは、ステップ714に進む。存在しない場合、ステップ712において、実施形態は、スタックトレースが含むスタックフレームのシーケンスを表す新しいトレースシグネチャを生成する。すなわち、線形接続されていると考えられていたスタックフレームのセット内に分岐点が発見される。次に、いくつかの実施形態は、1つ以上のSegmentInfoノードを生成し、1つ以上の二分木を変更し、および/または1つ以上の順序組を変更して、スタックトレースが含む(前に)線形接続されたスタックフレームのセットを表す新しい分類シグネチャを生成してもよい。新しい分類シグネチャを生成する手法については、図8を参照して以下にさらに詳細に説明する。

0091

ステップ714において、実施形態は、判断706に戻る前に、トレースシグネチャに関するカウンタをインクリメントする。具体的には、スタックトレース、スタックセグメント、およびスタックフレームが受信および発見されるときに、それらの数をその型によって追跡するために、ThreadClassificationInfoオブジェクト、SegmentInfoオブジェクト、および/またはStackFrameInfoオブジェクトのメンバ(たとえば、numOfOccurおよび/またはtotalNumOfOccur)である特定のカウンタがインクリメントされてもよい。

0092

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

0093

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

0094

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

0095

ステップ806において、実施形態は、当該1つ以上のスタックフレームのサブシーケンスを表すための、1つ以上の追加ノードを生成してもよい。具体的には、新しい型のスタックセグメントに含まれるスタックフレームごとに新しいStackFrameInfoオブジェクトが生成されてもよい。新しい型のスタックセグメントに対応する新しいSegmentInfoノードが生成されてもよく、新しいSegmentInfoノードは、新しいStackFrameInfoオブジェクトの各々を参照する。

0096

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

0097

ステップ810において、実施形態は、1つ以上の追加の二分木を生成する。1つ以上の二分木の少なくとも1つ以上は、1つ以上の追加のノードの少なくとも1つを含む。ほとんどの場合、1つ以上の追加の二分木は、1つのノードを有する単レベルの木であるだろう。新たに生成された二分木のうちの1つが、ステップ806において生成された新しいSegmentInfoノードを含んでもよい。

0098

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

0099

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

0100

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

0101

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

0102

1957年および1960年に発表されたホルト・ウィンタース3重指数フィルタは、季節トレンド把握および予測のために用いることができる。C.C.ホルト(C.C.Holt)による「Forecasting Trendsand Seasonal by Exponentially Weighted Averages(指数移動平均によるトレンドおよび季節の予測)」(海軍研究事務所覚書、第52号、1957年)が引用によって本明細書に援用される。P.R.ウィンタース(P.R.Winters)による「Forecasting Sales by Exponentially Weighted Moving Averages(指数加重移動平均による販売予測)」(Management Science第6巻、第3号324頁〜342頁、1960年)が引用によって本明細書に援用されている。ライト(Wright)は、不規則な間隔に対応するために1986年にホルト・ウィンタース法を拡張させた。D.J.ライト(D.J.Wright)による「Forecasting data published at irregular time intervals using an extension of Holt's method(ホルト法の拡張を用いた、不規則な時間間隔で公開されるデータの予測)」、(Management Science第32巻、第4号499頁〜510頁、1986年)が引用によって本明細書に援用されている。2008年に、ハンザック(Hanzak)が時間近接間隔の調整因子を提唱した。T.ハンザック(T.Hanzak)による「Improved Holt Method for Irregular Time Series(不規則な時系列のために改良されたホルト法)」(世界科学データシステム(WDS)2008年予稿集(WDS’08 Proceedings)第1部、62頁〜67頁、2008年)が引用によって本明細書に援用されている。

0103

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

0104

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

0105

いくつかの実施形態では、ヒープメモリ使用量およびスレッド強度などのリソース利用量の測定値を監視および予測するために、指数平滑移動平均線を求める式を当てはめて時系列データ、局所的な線形トレンド、季節トレンド、予測の誤差残差、および予測の絶対偏差を平滑化する。いくつかの実施形態では、この式は、1956年に提唱されたブラウンの指数フィルタと、1957年に提唱されたホルトの2重指数フィルタと、1960年に提唱されたウィンタースの3重指数フィルタと、1986年に提唱されたライトの不規則な間隔のための拡張と、2008年に提唱されたハンザックの時間近接間隔の調整因子と、外れ値検出およびクリッピングとに基づき得る。下記の刊行物は、引用によって本明細書に援用されている。R.G.ブラウン(R.G.Brown)による「Exponential Smoothing for Predicting Demand(需要予測のための指数平滑法)」(ケンブリッジアーサー・D・リトル株式会社(Arthur D. Little Inc.)、1956年)、15頁、C.C.ホルトによる「Forecasting Trendsand Seasonal by Exponentially Weighted Averages(指数移動平均によるトレンドおよび季節の予測)」(海軍研究事務所覚書、第52号、1957年)、P.R.ウィンタースによる「Forecasting Sales by Exponentially Weighted Moving Averages(指数加重移動平均による販売予測)」(Management Science第6巻、第3号324頁〜342頁、1960年)、D.J.ライトによる「Forecasting data published at irregular time intervals using an extension of Holt's method(ホルト法の拡張を用いた、不規則な時間間隔で公開されるデータの予測)」(Management Science第32巻、第4号499頁〜510頁、1986年)、T.ハンザックによる「Improved Holt Method for Irregular Time Series(不規則な時系列のために改良されたホルト法)」(世界科学データシステム(WDS)2008年予稿集(WDS’08 Proceedings)第1部、62頁〜67頁、2008年)、S.マウン(S.Maung)、S.W.バトラー(S.W.Butler)、およびS.A.ヘンク(S.A.Henck)による「Method and Apparatus for process Endpoint Prediction based on Actual Thickness Measurements(実際の厚み測定値に基づくエンドポイント予測を処理するための方法および装置)」(米国特許第5503707号、1996年)。

0106

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

0107

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

0108

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

0109

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

0110

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

0111

0112

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

0113

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

0114

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

0115

いくつかの実施形態は、ファイルシステムコールにおいてスレッドがブロック状態である間にbufferおよびbuffer.toString()という少なくとも2つのオブジェクトがガベージコレクションされるように、コードを下記のように修正できる。

0116

0117

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

0118

B.平日期間および週末期間の季節因子の初期化
ヒープをため込んでいるスタックトレースを特定するために、いくつかの実施形態は、(1)実行環境のヒープ使用量統計データの季節トレンドを推定することによってヒープ使用量が高い季節を特定し、(2)1つ以上のスレッドのクラスの各々について、スレッドのクラスのスレッド強度統計データの季節トレンドを推定してもよい。規則的間隔または不規則な間隔のヒープ使用量統計データの季節トレンドおよびスレッド強度統計データの季節トレンドを決定するためのいくつかの手法が、特許出願第14/109,578号、第14/109,546号、および第14/705,304号に記載されている。これらの出願は、あらゆる目的のために、引用により本明細書に援用する。

0119

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

0120

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

0121

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

0122

季節は、間隔のセットをある基準によって分類する。たとえば、1年という期間を考えると、1月、2月、3月、4月、5月、6月、7月、8月、9月、10月、11月、および12月という12個の間隔は、下記のように4つの気象季節に分類できる。

0123

12月、1月、および2月は、の季節として分類される。
3月、4月、および5月は、の季節として分類される。

0124

6月、7月、および8月は、の季節として分類される。
9月、10月、および11月は、の季節として分類される。

0125

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

0126

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

0127

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

0128

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

0129

0130

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

0131

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

0132

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

0133

平日の季節指数:Di、i=1,2,…96
週末の季節指数:Ei、i=1,2,…,192
10個の祝祭日の季節指数:Hk,i、i=1,2,…,96;k=1,2,…10
特定の年において、253日の平日(祝祭日を除く)と、50.5日の週末と、10日の祝祭日があるとする。253+50.5×2+10=364日である。この例において、いくつかの実施形態は、下記の式を用いて、季節因子の加重平均「A」を算出してもよい。ここで、重みは、1年における各期間(たとえば、平日期間、週末期間、および10個の祝祭日期間)のサイクルの数に比例する。

0134

0135

いくつかの実施形態は、各季節因子Di、Ei、およびHk,iをAで除算することによって、期間ごとの新しいくりこみ季節因子を導出できる。

0136

0137

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

0138

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

0139

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

0140

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

0141

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

0142

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

0143

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

0144

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、0.3という平滑化パラメータを用いてR言語のsmooth.spline関数を呼び出して、当該因子を平滑化してもよい。

0145

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

0146

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

0147

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekendSeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子と週末因子との配列を平滑化してもよい。たとえば、いくつかの実施形態は、0.3という平滑化パラメータを用いてR言語のsmooth.spline関数を呼び出して、これらの因子を平滑化してもよい。

0148

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

0149

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

0150

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

0151

0152

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

0153

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、0.3という平滑化パラメータを用いてR言語のsmooth.spline関数を呼び出して、当該因子を平滑化してもよい。

0154

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

0155

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

0156

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekendSeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子および週末因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、0.3という平滑化パラメータを用いてR言語のsmooth.spline関数を呼び出して、当該因子を平滑化してもよい。

0157

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

0158

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

0159

factors <- c(smoothedWeekdaySeasonalFactor,
smoothedWeekendSeasonalFactor,
smoothedWeekdaySeasonalFactor)
次に、いくつかの実施形態は、スプラインを適用して平日因子および週末因子の配列を平滑化してもよい。たとえば、いくつかの実施形態は、0.3という平滑化パラメータを用いてR言語のsmooth.spline関数を呼び出して、当該因子を平滑化してもよい。

0160

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

0161

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

0162

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

0163

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

0164

Qが1つの期間における季節指数の数を示し、Pが1つの期間にあるサイクルの数を示し、Kが1つの期間のサイクル中にある間隔の数を示し、K=P×Qが成り立つとする。

0165

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

0166

0167

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

0168

0169

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

0170

0171

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

0172

仮説を検定するために、いくつかの実施形態は、1つ以上の検定統計量を定義してもよい。検定統計量は、パラメータを変数とする関数であってもよい。この場合、相関係数ru,vが検定される。下記の検定統計量tは、自由度が「n−2」のスチューデントのt分布を有し、ru,vを変数とする関数である。いくつかの実施形態は、帰無仮説ru,v=0を定義する。これは、1つの期間のサイクル間で季節指数が相関関係にないことを想定する。いくつかの実施形態は、対立仮説受け入れることによって、帰無仮説(すなわち、ru,v=0)を棄却するための証拠を探してもよい。

0173

0174

F(t)が、確率分布を示すとする。有意水準が0.1であるとすると、F(t)=0.9が成り立つような確率変数tの値をt0.9,(n−2)が示すとする。対立仮説は、偏った条件である。

0175

0176

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

0177

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

0178

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

0179

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

0180

0181

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

0182

0183

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

0184

0185

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

0186

0187

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

0188

帰無仮説が真(すなわち、ru,v=0)である場合、下記の検定統計量tは、自由度が「n−2」のスチューデントのt分布を有する。

0189

0190

F(t)が、確率分布を示すとする。有意水準が0.1であるとすると、F(t)=0.9が成り立つような確率変数tの値をt0.9,(n−2)が示すとする。対立仮説は、偏った条件である。

0191

0192

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

0193

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

0194

0195

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

0196

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

0197

0198

乗法季節因子の範囲は、(1.34−0.76)であり、0.58である。したがって、季節因子の範囲の85パーセントは、(0.76+0.85×0.58)であり、1.253である。この85パーセントを閾値Tに与えると、T=1.25である。その結果、このような実施形態は、5月、6月、および7月を、年間ヒープ使用量が高い季節として分類するだろう。

0199

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

0200

0201

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

0202

具体的には、いくつかの実施形態は、measureFilterConstant α、rateFilterConstant β、accelerationFilterConstantκ、seasonalFactorFilterConstant γ、errorResidualFilterConstant δ、およびtimeZoneOffset tzというフィルタ定数(すなわち、独立変数である回帰パラメータ)を用いて非線形回帰を行い、1ステップ予測の残差の平均二乗誤差(MSE)および/または平均絶対偏差(MAD)を最小化できる。いくつかの実施形態では、タイムスタンプは、回帰において、時間帯オフセットtzだけずらされてもよい。いくつかの実施形態は、最適化ルーチン(たとえば、Rプログラミング言語が提供する最適ルーチン)を用いて、非線形多変量回帰を適用してもよい。いくつかの実施形態は、このような実施形態が採用する下記の式に示すα、β、κ、γ、δ、およびtzの最適値を用いて、平日季節因子および週末季節因子を導出してもよい。

0203

0204

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

0205

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

0206

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

0207

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

0208

Hが、ヒープ使用量のN個の季節因子のシーケンスを示すとする。Tが、スレッドのクラスのスレッド強度のN個の季節因子のシーケンスを示すとする。季節因子のこの2つのシーケンスの相関係数は、下記に定義する相関係数(H,T)によって得られる。

0209

0210

いくつかの実施形態は、直近の年間ヒープ使用量が高い季節に含まれるヒープ使用量統計データの回帰を実施することによって、ヒープ使用量の平日季節因子および週末季節因子を導出してもよい。データセットのこのセグメントの時間間隔を、(t1,t2)で示す。スレッドのクラスの強度統計データの季節因子とヒープ使用量の季節因子との相関を解析するために、いくつかの実施形態は、スレッドのクラスに関連するSeasonalTrendInfoに含まれる季節因子時系列における同じ時間間隔(t1,t2)から、季節因子を得ることができる。具体的には、季節因子時系列は、関連するSeasonalTrendingInfoオブジェクトに含まれるsmoothedWeekdaySeasonalFactorメンバ変数およびsmoothedWeekendSeasonalFactorメンバ変数に格納され得る。

0211

いくつかの実施形態は、スレッドのクラスのすべてのThreadClassificationInfoオブジェクトを反復し、ThreadClassificationInfoオブジェクトの各々に含まれるSegmentInfoオブジェクトを再帰的に横断して、ThreadClassificationInfoオブジェクトおよびSegmentInfoオブジェクト内に含まれるSeasonalTrendInfoオブジェクトを収集できる。上記の式を用いてスレッドのクラスの各々とヒープ使用量との相関係数(H,T)を計算する際、いくつかの実施形態は、SeasonalTrendInfoオブジェクトの各々に含まれる平日因子または週末因子を取り出すことができる。スレッドのクラスごとの相関度合いが算出されると、いくつかの実施形態は、スレッドのクラスをヒープ使用量季節トレンドとの相関度合いによってランク付けしてもよい。次に、最高位にランク付けされたスレッドのクラスが、ヒープをため込んでいるスレッドのクラスとして分類されてもよい。次に、いくつかの実施形態は、ヒープをため込んでいるスレッドのクラスに関連するコードおよびスタックトレースを解析して、手動または自動で修正および/または向上させることがきる非効率なメモリ使用量を特定してもよい。

0212

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

0213

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

該当するデータがありません

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

該当するデータがありません

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

この 技術と関連性が強い技術

該当するデータがありません

この 技術と関連性が強い法人

該当するデータがありません

この 技術と関連性が強い人物

該当するデータがありません

この 技術と関連する社会課題

該当するデータがありません

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ