AEM スレッドダンプ分析

説明

環境
Adobe Experience Manager

問題
次を使用してAEM Java スレッドダンプを分析 IBM Thread Analyzer ツールとベストプラクティスを参照してください。

解決策

ソリューション

次の手順とベストプラクティスに従って、を使用してAEM Java スレッドダンプを分析します。 IBM Thread Analyzer ツール:

  1. ダウンロードとインストール IBM Thread Analyzer ( つまり、IBM TDA と呼ぶ )。

  2. パフォーマンスの問題が発生している AEM インスタンスからスレッドダンプをキャプチャします。

  3. IBM TDA でスレッドダンプを開きます。

  4. スレッドダンプの詳細を表示するには、リスト内のファイルを選択し、 スレッドの詳細 」ボタンをクリックします。

    tda-threaddetail

  5. 並べ替え基準 スタックの深さ 一番長いスタックが上にある

    tda-image1

  6. スタックの深さが 10 行以上のスレッドを確認します。これらは通常、最も関心のあるスレッドです。

    関心のあるスレッドに関するメモを取ります。

  7. スレッドで並べ替え 都道府県.

  8. 下にスクロールして 実行可能 スレッド。 Runnable スレッドは、スレッドダンプが取得された際に、実際に CPU 時間を取っていたスレッドです。

    注意：レビュー時に 実行可能 スレッドを使用すると、 無視できるスレッド 」セクションをクリックします。

  9. 例えば、バックグラウンドジョブスレッドやリクエストスレッド（リクエストスレッドは、127.0.0.1 1347028187737 GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1 のような名前です）など、アプリケーションの一部である Runnable スレッドを探します。

    見つけたら、1 つずつクリックします。

  10. 各リクエストスレッドについて、スレッド名のタイムスタンプを調べることで、ユーザーのブラウザーがサーバーに対してリクエストを行った時間を調べることができます。

    例えば、上記のスレッド名では、タイムスタンプ（ミリ秒 UNIX エポック形式）はです。 1347028187737.

    このエポック番号は、 www.epochconverter.com.

    各スレッドダンプは、実行された日時を示します。

    リクエスト時間とスレッドダンプ時間の間の時間差を取り、リクエストがアクティブになっている時間を確認できます。

  11. リクエストスレッドを確認したら、他のスレッドをスクロールします 実行可能 スレッド。

    目的の実行可能なスレッドを見つけたら、中央のパネルを見てみましょう。 待機中スレッド.

    一覧に表示されたスレッドは、選択したスレッドがモニタを解放するのを待っています。

    待機中のスレッドが見つからない場合、選択したスレッドは、 ロック （クラスの実装を参照） ロック を参照 )。

    例えば、 ReentrantReadWriteLock ロックが複数のモニタを内部的に実装するので、どのスレッドがロックホルダかは判別できません。

    だから、ソースコードを見て、ロックホルダーのスレッドと照合しなければならないかもしれません。

  12. 他の多くのスレッドが待機していたロックまたはモニタがスレッドにあった場合は、残りのスレッドダンプを調べて、同じ問題を持つ他のスレッドが見つかるかどうかを確認します。

    他のダンプに同じスレッドがまだ存在するかどうかを確認します (IBM TDA では、複数のスレッドダンプを選択し、 スレッドの比較 ボタンを使用して、複数のスレッドダンプにわたるスレッドの状態を表示します。

    tda-comparethreads

  13. 詳しくは、 コレクターサービス 以下のスクリーンショットでは、

    tda-Image2

  14. この表示では、複数のスレッドダンプにわたるスレッドを確認すると、長時間実行されているスレッドかどうかがわかります。

    基本的に、スレッドが 実行可能 複数のダンプをまたいで、長いスタックを持つ状態。通常は、長い実行スレッドです。

  15. もし 実行可能 スレッドを選択し、スレッドリストに戻り、スレッドダンプを選択して、 モニタの詳細 ボタンを使用して、製品内で利用できます。

IBM TDA によって、ウィンドウが開かれて、スレッドを所有するモニターとその待機しているスレッドのツリービューが表示されます。

注意：サーブレットエンジンのスレッドプールモニターのように、一部のスレッドプールスレッドが表示される場合があります。アイドルスレッドは無視できます。

通常、スレッドはアイドルスレッドプールのスレッドであることを示すことができます。これは、ほとんどの場合、10 個以下のスタックラインしかないためです。

tda-monitordetail

スレッドレベルの CPU 使用率（Linux プラットフォームのみ）:

  1. をキャプチャした場合 top -H -b -n1 -p javapid スレッドダンプに加えて、スレッドレベルの CPU 使用率を相互参照できます。

    上部の出力を開き、CPU を使用しているスレッドのプロセス ID を取得します。

    プロセス ID を 16 進数に変換し、対応するスレッドダンプファイルでその 16 進数値を検索します。

    ID は nid ある糸の

  2. 最も多くの CPU を使用する一致スレッドが VM スレッド または任意 GC スレッドを読み込むと、メモリに問題が発生する可能性があります。

    同じ演習を繰り返して、より多くのスレッドダンプとトップ出力を行います。CPU 時間をかけるこれらのスレッドのパターンがある場合は、メモリの問題が発生します。

  3. メモリの問題を確認した場合、次回問題が発生したらヒープダンプをキャプチャします。

    参照 メモリの問題の分析記事 ヒープダンプのキャプチャと分析の詳細については、を参照してください。

無視できるスレッド:

  • VM Thread：これは VM システムのスレッドです。
  • GC タスクスレッドで始まるスレッド：これらは、ガベージコレクションスレッドです。
  • 名前が次のようなスレッド - 1347028691218 in code at java.net.PlainSocketImpl.socketAccept(Native Method):これらは、新しい接続で待機しているサーブレットエンジンのスレッドプールからのスレッドです。

このページ