異常検出ビュー

アプリケーションの異常検出解析を実行した後、結果を解釈します。注目するコード領域でパフォーマンスの異常を特定します。

異常検出解析の結果を解釈するには、異常検出ビューを使用します。一般的なワークフローでは、次の領域の調査が行われます。

データを表示

アプリケーションの異常検出の実行が完了すると、収集されたデータは [サマリー] ウィンドウに表示されます。

注目するコード領域の実行期間の分布図から開始します。これは、特定の期間または待機時間 (ミリ秒単位) のパフォーマンスが重要なタスクのインスタンス数を表示します。

以下を確認するため分布図を調査します。

この図は、低速な領域の予期しないパフォーマンスの異常値を特定します。

注目する存続期間のコード両機の分布図

注

必要に応じて、X 軸のスライドバーで高速、良い、低速のレイテンシーのしきい値を調整します。

低速な領域の負荷詳細

[ボトムアップ] ウィンドウで、注目する領域の低速なコードの負荷に関する詳細を確認できます。

  1. [ボトムアップ] ウィンドウに切り替えます。

  2. [注目する/存続期間タイプのコード領域] によるグループ化の結果。

  3. 低速な領域の異常値を詳しく調査するには、低速なフィールドを右クリックし、[選択してインテル® プロセッサーのデータをロード] を選択します。

これにより、[インテル® プロセッサー・トレース詳細] ウィンドウに、コード領域に関連する詳細がロードされます。

レイテンシーのプロセッサー・データをロード

プロセッサー・トレースの詳細を比較

[インテル® プロセッサー・トレース詳細] ウィンドウでトレースデータをロードすると、マークされたコード領域のそれぞれのインスタンスのトレースを詳しく比較できます。スタックの上位は、カーネルのエントリーポイントを表します。

メトリック

解釈

リタイアした命令、呼び出しカウント、反復数の合計

制御フローのメトリック。リタイアした命令は、カーネルへのエントリー数を表します。

CPU 時間 (カーネルとユーザー)

CPU 上のアクティブ時間。

待機時間、インアクティブ時間

同期またはプリエンプションによりスレッドがアイドルであった期間。

経過時間

レイテンシー (コード領域の実行ウォールクロック時間)。

このウィンドウを中心にして、次のタイプのパフォーマンス異常を検出します。

コンテキスト・スイッチ異常

  1. [インテル® プロセッサー・トレース詳細] ウィンドウで、インアクティブ時間と待機時間メトリクスを確認します。待機時間は、同期による問題でスレッドがアイドル状態であった時間を示します。

    1. メトリックの値がゼロである場合、アプリケーションではコンテキスト・スイッチが発生しなかったことを意味します。次の異常検出の確認に進んでください。

    2. メトリックがゼロでない場合、この手順を続行してコンテキスト・スイッチを確認します。

  2. 待機時間でデータをソートします。

  3. 待機時間が大きいインスタンスでは、待機時間と経過時間を比較します。スレドの経過時間のかなりの部分がアイドル状態である場合、問題の原因はコンテキスト・スイッチの同期によるものであると考えられます。この例では、thread 25883 は 1.318 ミリ秒の内 1.269 ミリ秒、つまり 96% の時間がアイドルであることを意味します。

    コンテキスト・スイッチのパフォーマンス異常

  4. インスタンスを展開し、関数やスタックにドリルダウンできます。スレッドをアイドル状態にしたスタック (複数も可) を特定します。

カーネルに起因する異常

  1. [インテル® プロセッサー・トレース詳細] ウィンドウで、カーネル時間でデータをソートします。スタックの最上位の要素は、カーネルへのエントリーポイントを指します。経過時間に対するカーネル時間の比率が高い場合、かなりの時間をカーネルが費やしたことを意味します。この例では、997 ミリ秒の内 566 ミリ秒がハイライトされたスレッド カーネルに起因する異常 のカーネルで費やされました。

  2. スレッドを展開して、カーネル時間を長くしているスタックを見つけます。

    カーネルに起因する異常のスタック

カーネルやドライバーには動的に実行されるコードが含まれるため、バイナリーに対して静的な処理を行うことはできません。スタックの最上位にある kernel_activity ノードは、注目するコード領域の特定のインスタンスで発生したカーネル・アクティビティーにおけるすべてのパフォーマンス・データが集約されています。

カーネルバイナリーは処理されないため、インテル® VTune™ プロファイラーは、呼び出しカウント、反復カウント、またはリタイアした命令などのコードフローのメトリックを収集できません。これらのメトリックは、カーネルへのエントリー数を示すリタイアした命令を除き、すべてゼロです。

カーネルに起因する異常な症状として、ネットワーク速度の低下が考えられます。ネットワーク上で要求の受信や応答を送信する際に、制御がカーネルに移行することで速度が低下する場合があります。

周波数の低下

次のウィンドウのいずれかで、周波数の低下に関連する情報を検索します。

周波数低下の原因はいくつか考えられます。

制御フロー偏差異常

一部のスレッドでリタイアした命令メトリックが予想外に大きい場合、制御フローの異常を示しています。コード領域で実行中のコードに偏差があることが考えられます。

制御フロー逸脱

  1. グリッド内でリタイアした命令の値が高いノードを選択します。

  2. 右クリックして、[コンテキスト] メニューから [選択してフィルター処理] を選択します。

  3. [呼び出し元/呼び出し先] ウィンドウに切り替えます。

    制御フロー逸脱の [呼び出し元/呼び出し先] ビュー

    [フラット・プロファイル] ビューでは、コメント付きのセルフと合計 CPU 時間を参照できます。[呼び出し元] ビューには、選択した関数の呼び出し元がボトムアップで表示されます。[呼び出し先] ビューには、選択された関数からのコールツリーがとトップダウンで表示されます。

この例では、_slab_evict_rand 関数から _slab_evict_one 関数の呼び出しにより、セルフ CPU 時間で分かるように大量の逸脱が発生しています。

ソースコード解析:

これは、制御フローの逸脱を特定する代替手段です。

  1. 合計反復カウントを確認すると、高速反復と低速反復のループ反復回数を比較できます。

  2. 低速な反復回数が多い場合、[ソース/アセンブリー] ビューに切り替えて関数のソースコードを調査します。

  3. 低速な反復がキャッシュされた要素の評価にパスしたか確認します。

これらは両方ともまれにしか発生しませんが、キャッシュ・エビクション (キャッシュ追い出し) の発生を示します。キャッシュのエビクションは完全に排除することはできないかもしれませんが、次の方法で最小限にすることができます、

上位トピック: 異常検出解析 (プレビュー)

関連情報

異常検出解析
パフォーマンス解析