アプリケーションの問題の特定

アプリケーションの問題切り分け担当者は、アプリケーションまたはアプリケーション環境内で問題が発生していることが分かった場合、その問題がどこで発生しているかを特定することから調査を始めます
apmdevops104jp
アプリケーションの問題切り分け担当者は、アプリケーションまたはアプリケーション環境内で問題が発生していることが分かった場合、その問題がどこで発生しているかを特定することから調査を始めます
3
2
[ホーム]タブからのアプリケーション稼働状況およびパフォーマンスの監視
アプリケーション稼働状況およびパフォーマンスの監視を定期的に行うことによって、通常のパフォーマンスがどのようなものであるかを知ることができます。典型的な環境状態を知っておくと、問題が発生したときにアプリケーション環境内の問題や異常な変化を迅速に特定することができます。
アプリケーションの監視には[ホーム]タブを使用します。[ホーム]タブには稼働状況やステータスの概要が表示されます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. 必要に応じて、WebView の[ホーム]タブをクリックします。
    : SAP WebView ユーザは、[ホーム]タブを利用できません。この場合、ユーザはダッシュボードから開始することができます。「サンプル ダッシュボードでのアプリケーションの監視」を参照してください。
  3. [ホーム]タブでは、以下の情報を使用して特定のシステムおよびアプリケーションのパフォーマンスを監視および理解します。
    • ビジネス トランザクションおよびアプリケーション コンポーネント稼働状況の表示。
    • 最も遅い、または最も非効率的なパフォーマンスのフロントエンドおよびビジネス トランザクションの表示。
    • アプリケーション層稼働状況のリスクの表示。
    • アクティブなアラートの表示。
    • 最近のアラート通知メッセージの表示。
  4. (オプション)まず、アプリケーション問題切り分けマップ、または WebView Console ダッシュボードから問題の場所を調査します。
標準メトリック
WebView は、エージェントがメトリックとしてリモートおよびローカル システムから収集するアプリケーション パフォーマンス データを表示します。監視対象のフロントエンドおよびバックエンドのアプリケーション コンポーネント、およびその他の多くのアプリケーション コンポーネントについては、以下の標準メトリックが表示されます。
  • Average Response Time (ms) (平均応答時間(ミリ秒))
    -- 基準となるアプリケーション応答速度。
  • Concurrent Invocations (同時進行中の呼び出し)
    -- 一定の時間に処理される要求の数。
  • Errors Per Interval (間隔ごとのエラー数)
    -- 指定した時間スライス中に発生するエラーの数。
  • Responses Per Interval (間隔ごとの応答数)
    -- 指定した時間スライス中に完了した要求の数。
  • Stall Count (ストール数)
    -- ストールの数。ストールは、指定した時間しきい値内に完了しなかった要求です。
ビジネス トランザクションおよびアプリケーション コンポーネント稼働状況の表示
ビジネス トランザクションおよびアプリケーション コンポーネント稼働状況のサマリを表示することにより、パフォーマンス稼働状況での問題を特定および診断できます。
アプリケーション コンポーネントもフロントエンドと呼ばれます。これは受信トランザクションを最初に処理するアプリケーション コンポーネントです。最も一般的な J2EE のアプリケーションでは、サーブレットや JSP がこれにあたります。Java インスタンスによっては EJB やその他のコンポーネントのこともあります。Introscope はサーブレットと JSP をフロントエンドとして自動認識しますが、その他のコンポーネントの場合、自動的には認識しません。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. 必要に応じて、WebView の[ホーム]タブをクリックします。
  3. ビジネス トランザクション サマリやアプリケーション コンポーネント サマリに表示される正常なパフォーマンスおよび異常なパフォーマンスを監視し、状態を把握します。
    • ステータス
      アラート インジケータを表示します。このステータスは以下のいずれかのメトリックを使用します。
      • Average Response Time (平均応答時間)
      • Concurrent Invocations
      • Errors per Interval
      • Responses per Intervals
      • Stalls Count
    • R/T (秒)
      応答時間を表示します。応答時間は、要求が完了するまでにかかる時間(秒単位)です。
      • 応答時間が短いのが望ましい状態です。
      • 長い応答時間は、問題があることを示しています。
      Average Response Time(平均応答時間)メトリックは、間隔中に完了したすべての要求の応答時間の平均を示します。このメトリックが警告ステータス(黄)または危険ステータス(赤)を示した場合、セルの色はステータスに対応した色になります。
    • エラー
      JVM および HTTP エラー コードでレポートされる例外の数を表示します。ストール数の傾向を他のメトリックの変化と組み合せて、問題を識別し、診断できます。
  4. 現在の傾向または履歴傾向を調査します。
    • ライブ データおよび履歴データを表示します。
      [時間ウィンドウ]ドロップダウン リストから時間範囲を選択します。
    • 目的のビジネス トランザクションまたはアプリケーション コンポーネントの名前をクリックします。
      問題切り分けマップ ツリー内の対応するビジネス サービスまたはフロントエンドによって表示が切り替わります。自動検出されたアプリケーション コンポーネントおよびそれらの依存関係が、[概要]タブのアプリケーション問題切り分けマップに表示されます。マップ エレメントにマウス カーソルを合わせて、フロントエンドのパフォーマンスを監視しながらメトリックを表示および確認できます。
最も遅い、または最も非効率的なパフォーマンスのフロントエンドおよびビジネス トランザクションの表示
CA APM 環境の要約された稼働状況を表示できます。このサマリには、最も遅いパフォーマンスおよび最も非効率的なパフォーマンスの上位 25 件のビジネス トランザクションおよびフロントエンドが表示されます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. 必要に応じて、WebView の[ホーム]タブをクリックします。
  3. 以下のグラフを分析して問題の特定および診断を行い、これらのメトリックスを監視して、常に速度が遅くエラーが起こりやすいのがどのトランザクションであるかを把握します。
    • 最も遅いものから 25 件
    • エラー数およびストール数の最も多いものから 25 件
  4. (オプション)ライブ データおよび履歴データを表示します。
    [時間ウィンドウ]ドロップダウン リストから時間範囲を選択します。
  5. [メトリック ブラウザ]タブで特定のメトリックを分析します。
アプリケーション層稼働状況のリスクの表示
アプリケーション層(バックエンド呼び出し、CPU、およびメモリ)の稼働状況を表示し、問題の根本原因を特定できます。バックエンドは最も一般的なデータベースですが、メール サーバなどの任意の外部システムである可能性もあります。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. 必要に応じて、WebView の[ホーム]タブをクリックします。
  3. [他の層からのリスク]ペインを表示します。
    [バックエンド コール]には、triage map backends calls で定義されたアラートのステータスが表示されます [CPU]には、ホストの CPU 使用率に対して定義されたアラートのステータスが表示されます。[メモリ]には、ガベージ コレクションに費やされた時間の割合に対して定義されたアラートのステータスが表示されます。
    • 警告状態(黄)または危険状態(赤)のアラート インジケータを探します。
  4. 目的のアプリケーション層をクリックします。
    表示が、管理モジュール ツリーのアラートに切り替わります。[プレビュー]ペインにアラートの設定が表示されます。
  5. グラフでしきい値を超えているメトリックにマウス カーソルを合わせると、役に立つ詳細情報が表示されます。
    • 関心のあるメトリック リンクをクリックすると、メトリック ブラウザ ツリーで詳細を確認できます。
  6. [メトリック ブラウザ]タブで特定のメトリックを分析します。
アクティブなアラートの表示
ライブ モードと履歴モードのアクティブなアラート ステータスは[ホーム]タブに表示されます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
     
  2. 必要に応じて、WebView の[ホーム]タブをクリックします。
  3. [アクティブなアラート]ペインで、危険、警告、または正常のステータスを持ったすべてのアクティブなアラートのサマリ数を確認します。
  4. アクティブなアラート テーブルの[下位 10 件]ペインを表示します。
    • 警告状態(黄)または危険状態(赤)のアラート インジケータを探します。
  5. 何がアラートをトリガしたかを確認または分析するには、テーブルで関心のあるアラート名をクリックします。
    • 簡易アラート定義。
      [管理モジュール]ツリーのプレビュー ペインには、アラートの設定が表示されます。
    • 管理モジュール ツリーの簡易アラート定義。
      関連する簡易アラートすべてを含むサマリ アラート定義を表示します。
    • アラートを問題切り分けマップ ツリーで定義するときの基準となるメトリック。
  6. 関連するメトリックがアラートしきい値を超えたときに調査することにより、アラートを検査します。
  7. [メトリック ブラウザ]タブで特定のメトリックを分析します。
最近のアラート通知メッセージの表示
[ホーム]タブには、常に 5 つの最新のアラート通知メッセージが自動的に表示されます 
以下の手順に従います。
  1. [最近の通知]アラート リストを表示し、警告(黄)または危険(赤)アラート インジケータを探します。
  2. 何がアラートをトリガしたかを確認または分析するには、関心のあるアラート通知をクリックします。
    • 簡易アラート定義。
      [管理モジュール]ツリーのプレビュー ペインには、アラートの設定が表示されます。
    • アラートを問題切り分けマップ ツリーで定義するときの基準となるメトリック。
  3. アラートを調査するには、そのアラートをクリックし、なぜ変更がトリガされたかを判断します。
メトリック ブラウザについて
[メトリック ブラウザ]タブには、メトリックとほかの情報がツリー形式で表示されます。ドメインのすぐ下の高レベル ノードは、個々のアプリケーション サーバ ホストまたは同等のものにインストールされているエージェントを表します。
高レベル ノードが表す各種コンポーネントには、次のものがあります。
  • サーブレット、EJB、ASP ページなど、J2EE または.NET アプリケーションのコンポーネント
  • アプリケーション サーバを実行するホスト、および CA APM を実行するホスト コンピュータを含むシステム ノード
Investigator では、ライブ データを表示するか、時間範囲を選択して履歴データを表示できます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. 使用している環境に応じて、メトリック ブラウザ ツリーの SuperDomain または Domains ノードを展開します。
    ノードは、特定のメトリック情報が収集され、エージェント中心のツリー ビューに表示される場所です。たとえば、バックエンド ノードや CPU 使用状況ノードがあります。ノードを展開すると、より詳細なメトリック情報を表示し、検索できます。
    エージェント、リソース、およびメトリックのツリー ビューは、15 秒ごとに更新されて最新のメトリック データを表示します。このツリーには以下のノードが含まれます。
    • SuperDomain
      -- このノードには、Enterprise Manager にレポートするすべてのエージェントのメトリックが含まれています。メトリックは、[ホスト|プロセス|エージェント]階層で編成されます。
      • Custom Metric Host (Virtual)
        -- このノードは、特定の個別のエージェントがレポートしないメトリックが含まれている仮想ホストを表します。たとえば、カスタム メトリックまたはカスタム集約エージェントは、このノードの下に表示されます。(このノードは、物理ホスト コンピュータに対応していません。)
      • Hosts
        -- このノードは、エージェントをホストするコンピュータを表します。各ホスト ノードには、モニタ対象のアプリケーションのインスタンスのプロセス ノードが含まれています。また、プロセス ノードには Agent ノードが含まれます。Agent ノードには、メトリックを含むアプリケーションおよびシステム リソースに対応するノードが含まれています。Agent ノードに表示されるアプリケーション リソースは、Agent の種類が Java か .NET かによって異なります。
    • Domains
      -- Enterprise Manager にレポートするエージェントが複数ドメインに分けられている場合は、各ドメインのサブノードがこのノードに含まれます。各サブノードはそれぞれ、個々のアプリケーション サーバ ホストまたはそれに準ずるものにインストールされているエージェントを表します。
  4. ホストの下にあるエージェント ノードをクリックし、展開します。
  5. イベントなどのデータを調査するには、右ペインのタブをクリックします。
    たとえば、[エラー]タブをクリックしてアプリケーション エラーを検出します。エラー診断の詳細については、シナリオ「エラーを分析する方法」を参照してください。
アプリケーションのバイタル サイン
一部のメトリックは、アプリケーションのパフォーマンスの監視に特に有用です。以下のメトリックは、アプリケーションのバイタル サインと見なすことができます。
  1. Resources
    • メモリ
      • GC Heap
    • CPU
    • Threads
    • JMX
  2. フロントエンド
  3. Backends
使用するメトリックの多くは標準的なメトリックです。
  • Average Response Time (平均応答時間)
  • Concurrent Invocations
  • Errors Per Interval
  • Responses Per Interval
  • Stall Count
アプリケーションの問題の傾向タイプ
Average Response Time をほかのメトリックの変化と組み合せて、傾向を分析することで、問題を識別し、診断できます。
Average Response Time の傾向
定義
継続的な問題
Available Thread Count の値が低く、Average Response Time の値が一貫して高い場合は、以下の問題を示している可能性があります。
  • 非効率なコード
  • 外部システムの過剰使用
  • バックエンドが遅い
  • レイヤが多すぎる
一貫した問題が常に存在し、改善することも悪化することもありません。
定期的な問題
Average Response Time が定期的に高くなり、定期的に急増した後、通常に戻るというようなグラフで示されます。
Available Thread Count の値が低く、Average Response Time の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
  • GC リークが頻繁に発生
  • 負荷に関連するバックエンドのボトルネック
  • CPU Utilization の値が低く、Average Response Time の値が定期的に高くなる場合は、以下の問題を示している可能性があります。
  • 内部問題
定期的な問題が発生し、一定の間隔で収まります。
進行的な問題
Average Response Time が長期にわたって着実に増加しており、Responses Per Interval の値が低い場合は、以下の問題を示している可能性があります。
  • メモリ リーク
段階的な問題は時間と共に減少します。
エージェントからのメトリックの分析
アプリケーションの問題を表示するメトリックを分離して、特定のメトリックを分析し、さらに多くの情報を収集します。
エージェントによってレポートされる以下の情報を分析します。
  • サーブレット、EJB、ASP ページなどの、J2EE または .NET アプリケーションのコンポーネント。
  • アプリケーション サーバを実行するホスト、および CA APM を実行するホスト コンピュータを含むシステム ノード。
  • イベント、障害、漏洩、およびその他の特殊な状況の発生。
以下の手順に従います。
  1. [ホーム]タブのチャート、ダッシュボード、またはアラート定義でデータ ポイントをクリックします。
    メトリック ブラウザ ツリーにメトリックが表示されます。
  2. 何がメトリック値変更のトリガになったかを判断します。
    1. メトリック値がいつ変わったかを確認するために時間ウィンドウで時間範囲を変更します。
    2. 時間範囲内の 1 つ以上のチャートを確認し、その問題が継続的か、定期的か、進行的か、突発的かを判断します。
  3. 他のメトリックのデータを確認すると、問題の場所の特定に役立ちます。
    1. メトリック ブラウザ ツリーで、検査しているメトリックの親ノードをクリックし、次に[概要]タブをクリックします。
      たとえば、Average Response Time (ms) を確認している場合は、平均応答時間のメトリックと、その他の標準的なメトリックを含むアプリケーション ノードをクリックします。
    2. 初期メトリック値が変わったときにその他の変更が発生したかどうかを判断するには、[概要]タブのチャートに表示されたメトリックを検査します。
フロントエンド メトリックによるパフォーマンスの調査
フロントエンドのメトリックおよびタブを使用して、アプリケーション コンポーネントおよび標準的なメトリックを監視することで、パフォーマンスの問題を調査できます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. メトリック ブラウザ ツリーで Frontends|Apps|
    Frontend_Namen
    に移動します。
    右ペインで選択したノードに対応するパフォーマンス メトリック情報が表示されます。
    注:
    同じメトリックが、[問題切り分けマップ]ツリーの By Frontend|
    Frontend_Name
    |Health に表示されます。
  4. ツリーでメトリックを確認します。
    1. 異常に高い平均レスポンス時間を探します。
    2. Concurrent Invocations (同時進行中の呼び出し)を探します。
      同時進行中の呼び出しは、同じ間隔中に終了を待たずに起動します。メソッドをできるだけ早く終了するためには、同時進行中の呼び出しが異常に多いのは望ましくありません。複数の呼び出しが同時に進行中のときは、一時的に値が急増する可能性がありますが、メトリックは毎回、ゼロに戻ります。ゼロに戻らない場合は、スレッド、データベース接続の数、またはその他の共有リソースのボトルネックを示している可能性があります。
  5. [全般]タブを使用して調査します。
    1. Frontends|Apps|<
      App_Name
      >|URLs に移動して、[全般]タブをクリックします。
      上位 10 件の URL が表示されます。
    2. この上位 10 件が、最も遅いトランザクション上位 10 件のいずれかを表している場合は、遅いトランザクションに関連するメトリックを検査します。
  6. [全般]タブを使用して調査します。
    1. [概要]タブをクリックします。
      このタブには、そのノード下にあるアプリケーション コンポーネントが表示されます。最も値が高い[応答時間](R/T)コンポーネントがリストの一番上に表示されるように、コンポーネント テーブルが並べ替えられます。
    2. アプリケーション パフォーマンス データをグラフで表示するには、以下の手順を実行します。
      • テーブルの最初の列で、1 つ以上のチェック ボックスをオンにします。
      • [グラフ化する列の選択]をクリックします。ドロップダウン リストから、列([エラー]など)を選択します。一度に選択できるのは、1 つの列のみです。
      • [グラフを描画]をクリックします。
        下部ペインのグラフには、選択した項目の現在のデータ ビューが表示されます。データ ポイントにマウス カーソルを合わせると、詳細情報を含むヒントを表示できます。
      • 履歴データを表示するには、[時間ウィンドウ]ドロップダウン リストから時間範囲オプションを選択します。選択した時間範囲がステータス バーに表示されます。
    3. 問題のコンポーネントがあるかどうかを判断するには、以下の手順を実行します。
      • テーブルの 2 列目にある青色ボックスの右向き矢印をクリックし、メトリック ブラウザ ツリーのデフォルト位置までコンポーネントを追跡します。
        [概要]タブには、選択したコンポーネントの全体的なパフォーマンス メトリックのグラフ ビューが表示されます。Average Response Time の傾向を利用して、問題の特徴を明らかにします。
    4. [概要]タブの[Average Response Time]メトリックをクリックします。
      メトリックのグラフ ビューが[全般]タブに表示されます。チャートとグラフは、時間範囲を反映します。
  7. (オプション)遅いトランザクションをさらに詳しく調査します。
フロントエンド メトリックによるパフォーマンスの調査
メトリック ブラウザ ツリーの[Backends]ノードには、接続された各バックエンド システムの標準的なメトリックが表示されます。IBM WebSphere MQ、ミドルウェアおよび Web サービスはバックエンド システムです。
たとえば、[SQL]ノードには、基準パフォーマンスを認識するのに役立つメトリックが表示されます。バックエンド アプリケーションのパフォーマンスを調査するには、遅い、またはエラーを生成している SQL ステートメントを表示するといいでしょう。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. メトリック ブラウザ ツリーで、[Backends]-[Application_Name]-[
    SQL
    ]に移動します。
    [概要]タブに標準メトリックが表示されます。
  4. クエリ テーブルで[R/T](応答時間)列ヘッダをクリックして、テーブル内の項目を並べ替えます。
  5. 最も遅い SQL クエリに注意してください。
  6. 他の列を並べ替えて、他にも問題がないかどうかを調査します。
システム リソースの調査。
GC ヒープや CPU メモリなどのシステム リソースの使用率の高さが、アプリケーションのパフォーマンス低下の原因になることがあります。アプリケーションの問題の根本な原因の究明には、関連するメトリックの評価が役立つでしょう。
GC ヒープ メトリックによるパフォーマンスの調査
ガベージ コレクション(GC)はオブジェクトが使用しなくなったメモリを解放するプロセスです。GC Heap (Garbage Collection Heap) メトリックは、アプリケーションのパフォーマンスを監視および理解する場合に有効なツールとなります。
JVM に割り当てたメモリの量が少なすぎる、または多すぎる場合は、パフォーマンスの問題が発生する可能性があります。これらのガイドラインを使用します。
  • 割り当てたメモリが少なすぎると、より頻繁に GC プロセスが実行されるため、短期間ですが頻繁にパフォーマンスが低下するという問題が発生します。
  • 割り当てたメモリが多すぎると、GC プロセスの実行時に、その所要時間が比較的長くなるため、その間のパフォーマンスが低下します。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. エージェント セントリック ツリーの[GC Heap]ノードに移動します。
    • アプリケーションの問題の原因がメモリ リークにあるかどうかを判断するには、以下のメトリックを使用します。
      • GC Heap|Bytes In Use
        オブジェクトが使用しているメモリの量をレポートします。
      • GC Heap|Bytes Total
        JVM が割り当てるメモリの合計をレポートします。
    これらのメトリックを観察して、一定時間における基準パフォーマンスを把握します。[Bytes In Use]メトリックは定期的に増加および減少を示すはずです。ある程度の間、この変化が一定のパターンで繰り返されるようであれば、メモリ リークの兆候は示されていません。
CPU 使用率の評価
CPU 使用率の増大は、アプリケーションのパフォーマンスに問題を引き起こす可能性があります。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. エージェント セントリック ツリーの[CPU Heap]ノードに移動します。必要に応じて、サブノードを展開します。
    • CPU 使用率を判断するには、以下のメトリックを使用します。
      • CPU:Utilization % (process)
        ホストの処理能力の合計に対する割合(%)ですが、Introscope が監視する JVM プロセスにより利用される割合(%)に限定されます。
      • CPU:Utilization % (aggregate)
        個々のプロセッサの使用率。
(オプション)スレッド ダンプの収集および分析。
ブロックされたスレッドが多数存在することに気付いた場合は、スレッド ダンプを収集して調査します。thread_dump オプション権限を持つユーザは、スレッド ダンプを表示して JVM のパフォーマンスの問題の原因を特定できます。
注:
時間ウィンドウは[スレッド ダンプ]タブに影響しません。さらに、スレッド ダンプは JVM についてのみ収集できます。.NET CLR では収集できません。
スレッド ダンプ分析は以下のような場合に使用します。速度低下、サーバのハングアップ、または異常に高い CPU 使用率の原因を把握するには、エージェント JVM スナップショットを使用します。
  • トランザクション追跡セッションの実行時に、WebView にストール メトリックは表示されるが、トランザクションは表示されない。この状況は、トランザクションが終了しておらず、Enterprise Manager がエージェント サーバ ハングアップに関する不完全な情報を取得しているために発生することがあります。
  • アプリケーションの CPU 使用率が低いにもかかわらず、応答に長い時間がかかる。この状況は、操作中のスレッドがすべて、デッドロックしているか、ブロックされているか、待機中であることを示します。
  • あるメソッドでロードに長時間を要する場合、1 つのスレッドが CPU の大部分を使用していることがあります。その間、他のすべてのスレッドは、それらの次のタスクを開始する前に、単一のスレッドがそのタスクを完了するのを待機します。
    : 連続してスレッド ダンプを実施すると、パフォーマンスが低下する場合があります。最高のパフォーマンスを得るには、各スレッド ダンプ間に多少の時間をあけます。
以下の手順に従います。
  1. APM Team Center で、[WebView]をクリックします。
  2. WebView で、[Investigator]-[メトリック ブラウザ]をクリックします。
  3. メトリック ブラウザ ツリーのエージェント ノードを選択します。
  4. 右側のペインで、[スレッド ダンプ]タブをクリックします。
  5. [新規に収集]をクリックします。
  6. 表示されるメッセージで[はい]をクリックします。
    ヘッダは、スレッド ダンプ時間を表示します。スレッド ダンプ サマリ バーは、スレッドの総数、待機スレッドの数、ブロックされたスレッドの数、または実行中スレッドの数を表示します。右下隅にある円グラフは、スレッドのパーセンテージを状態別で表示します。
スレッド ダンプの調査
1 つのスレッドに関する情報を以下のように調査します。
  1. スレッド ダンプ テーブル内の行を選択します。
    各スレッドは、スタック トレースに関連付けられます。スタック トレースは、すべてのメソッドを呼び出された順にスレッド スタック トレース テーブルに一覧表示します。
  2. スレッド スタックト レース テーブル内の[重複を非表示にする]チェック ボックスをオンにします。同じクラスの複数のメソッドがスタック トレースで連続して呼び出される場合は、最初のメソッドのみが表示されます。チェック ボックスがオフにされた場合、スタック トレース内のメソッドはすべてスレッド スタック トレース テーブルに一覧表示されます。
    重複する呼び出しが非表示の場合、[スレッド ダンプ]タブには、非表示の呼び出し数が、メソッド名の隣に山かっこで囲まれて表示されます。
    たとえば、スレッドを選択しており、以下のメソッドがスタック トレース テーブルに表示されるとします。
    java.net.PlainSockettlmpl.SocketAccept(Native Method) java.net.PlainSockettlmpl.accept(PlainSockettlmpl.java:457) java.net.ServerSockettimpl.Accept(ServerSockettimpl.java:473) java.net.ServerSockettimpl.accept(ServerSocket.java:444) com.ibm.rmi.transport.ListenerThread.run(ListenerThread.java:166)
    [重複を非表示にする]チェック ボックスをオンにすると、上記のメソッドは以下のように表示されます。
    java.net.PlainSockettlmpl.SocketAccept(Native Method) <1> java.net.ServerSockettimpl.Accept(ServerSockettimpl.java:473) <1> com.ibm.rmi.transport.ListenerThread.run(ListenerThread.java:166)
    後の java.net.PlainSockettlmpl.SocketAccept メソッドと java.net.ServerSockettimpl.Accept メソッドの呼び出しは現在、追跡スタックで非表示です。これらの呼び出しは、<1> の非表示メソッド数として表されます。
  3. すべてのスレッド ダンプ情報内の特定の文字列を以下のように検索します。
    • [検索]フィールドで、単語または語句を入力します。
    • [フィルタの適用]をクリックします。
  4. すべてのスレッド、またはデッドロック、実行中、ブロック、または待機中の各状態のスレッドを以下のように一覧表示します。
    • [スレッド状態]ドロップダウン リスト([検索]フィールドの右側にある)をクリックして、状態を選択します。[フィルタの適用]をクリックします。
    • [スレッド状態]ドロップダウン リストを使用して、さらに検索をフィルタします。
  5. 前回のスレッド ダンプについて、スレッド ダンプの詳細を以下のように表示します。
    1. [以前のデータをロード]ボタンをクリックします。
    2. [前回のスレッド ダンプをロード]ダイアログ ボックスで 1 行を選択し、[OK]をクリックします。
    選択したスレッド ダンプのデータが表示されます。過去のすべてのスレッド ダンプから選択することができます。また、一度に表示できる過去のスレッド ダンプは 1 つです。
次に行う作業
問題の場所を特定し、関連する情報を収集しました。アプリケーションまたはコンポーネントの所有責任者に問題の診断を要求することができます。
以下のシナリオを使用して、根本原因をさらに詳しく調査できます。