AEM スレッドダンプ分析
IBM Thread Analyzer ツールを使用してAEM Java スレッドダンプを正常に分析するには、この記事で詳細に説明されている手順とベストプラクティスに従ってください。
説明 description
環境
Adobe Experience Manager
問題
IBM Thread Analyzer ツールを使用して、AEM Java スレッドダンプを分析する方法を教えてください。
解決策 resolution
-
IBM Thread Analyzer (以下、略してIBM TDA とします)をダウンロードしてインストールします。
-
パフォーマンスの問題が発生している AEM インスタンスからスレッドダンプをキャプチャします。
-
IBM TDA でスレッドダンプを開きます。
-
スレッドダンプの詳細を表示するには、リストでファイルを選択して、「 スレッドの詳細 」ボタンをクリックします。
-
スタックの深さ で並べ替え、最も長いスタックを上に表示します。
-
スタックの深さが 10 行以上のスレッドを確認します。 これらは通常、最も関心のあるスレッドです。
関心のあるスレッドをメモします。
-
スレッド 状態 で並べ替えます。
-
Runnable スレッドまでスクロールします。 Runnable スレッドは、スレッドダンプが取得された際に、実際に CPU 時間を取っていたスレッドです。
メモ:Runnable スレッドを確認する際に、このページの下部にある Threads セクションにリストされた、無視できるスレッドを無視できます。
-
例えば、バックグラウンドジョブスレッドやリクエストスレッド(リクエストスレッドは、- 127.0.0.1
[
1347028187737]
GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1 のような名前です)など、アプリケーションの一部である Runnable スレッドを探します。見つけたら、1 つずつクリックします。
-
各リクエストスレッドについて、スレッド名のタイムスタンプを調べることで、ユーザーのブラウザーがサーバーに対してリクエストを行った時間を調べることができます。
例えば、上記のスレッド名では、タイムスタンプ(ミリ秒単位の Unix Epoch 形式)は 1347028187737 です。
www.epochconverter.com を使用して、この Epoch 数を日付/時間に変換できます。
各スレッドダンプは、取得された日時を示します。
リクエスト時間とスレッドダンプ時間の時間の差から、リクエストがアクティブであった時間の長さを確認できます。
-
リクエストスレッドを確認したら、他の Runnable スレッドにスクロールします。
関心のある Runnable スレッドが見つかったら、中央のパネルの 待機スレッド を確認します。
リストにThreadsは、選択したスレッドがモニターを解放するのを待っています。
待機しているスレッドが表示されない場合、選択したスレッドがまだ Lock の所有者である可能性があります(詳しくは、Lock の実装クラスを参照)。
例えば、ReentrantReadWriteLock の場合、ロックは複数のモニターを内部で実装しているので、どのスレッドがロック所有者であるかはわかりません。
そのため、ロック所有者である可能性のあるスレッドと組み合わせるために、ソースコードを調べる必要がある場合があります。
-
そのスレッドが他の多くのスレッドが待機しているロックまたはモニターを持っている場合、残りのスレッドダンプを確認すると、同じ問題がある他のスレッドが見つかるかどうかがわかります。
他のダンプに同じスレッドがまだ存在するかどうかを確認します(IBM TDA で、複数のスレッドダンプを選択して、「Threadsの比較 」ボタンをクリックすると、複数のスレッドダンプにわたるスレッドの状態を表示できます。
-
以下のスクリーンショットの コレクターサービス を参照してください。
-
この表示では、複数のスレッドダンプにわたるスレッドを確認すると、長時間実行されているスレッドかどうかがわかります。
基本的に、複数のダンプにわたってスレッドが Runnable 状態で長いスタックを持つ場合、通常は、長時間実行されているスレッドであることを意味します。
-
Runnable スレッドがあまり見つからなかった場合は、スレッドリストに戻り、スレッドダンプを選択してから、上部のパネルの Monitor Detail ボタンをクリックします。
IBM TDA によって、ウィンドウが開かれ、スレッドを所有するモニターとその待機スレッドのツリービューが表示されます。
メモ:サーブレットエンジンスレッドプールモニターなど、一部のスレッドプールスレッドが表示されることがあります。アイドルスレッドは無視されます。
通常、ほとんどの時間、10 行以下のスタックのみなので、スレッドがアイドルスレッドプールスレッドであることがわかります。
スレッドレベルの CPU 使用率(Linux プラットフォームのみ) :
-
スレッドダンプ
top -H -b -n1 -p <javapid>
加えて出力をキャプチャした場合は、スレッドレベルの CPU 使用率を相互参照できます。top 出力を開いて、CPU を使用しているスレッドのプロセス ID を取得します。
プロセス ID を 16 進数に変換し、対応するスレッドダンプファイルでその 16 進数の値を検索します。
この ID は、いずれかのスレッドの nid に一致する必要があります。
-
ほとんどの CPU を使用している、一致するスレッドが VM Thread または任意の GC スレッドの場合、メモリの問題が発生している可能性があります。
より多くのスレッドダンプおよび top 出力に対して、同じ演習を繰り返します。これらのスレッドが CPU 時間を占めるパターンがある場合は、メモリの問題が発生しています。
-
メモリの問題を確認した場合、次回問題が発生したらヒープダンプをキャプチャします。
ヒープダンプのキャプチャおよび分析について詳しくは、 メモリの問題の分析を参照してください。
無視できる Threads:
- VM Thread:これは VM システムのスレッドです。
- GC タスクスレッドで始まるスレッド:これらは、ガベージコレクションスレッドです。
- [ 1347028691218] in code at java.net.PlainSocketImpl.socketAccept(Native Method)
に似た名前を持つThreads:これらは、新しい接続を待機しているサーブレットエンジンのスレッドプールからのスレッドです。