目的

IBM Thread Analyzer ツールを使用して、AEM Java スレッドダンプを分析します。

手順

  1. IBM Thread Analyzer(以下、略して IBM TDA とします)をダウンロードしてインストールします。
  2. パフォーマンスの問題が発生している AEM インスタンスからスレッドダンプをキャプチャします。
  3. IBM TDA でスレッドダンプを開きます。
  4. スレッドダンプの詳細を表示するには、リストでファイルを選択して、「Thread Detail」ボタン* をクリックします。
tda-threaddetail
  1. 「Stack Depth」で並べ替えて、最も長いスタックが上に来るようにします。
tda-image1
  1. スタックの深さが 10 行以上のスレッドを確認します。 これらは通常、最も関心のあるスレッドです。 関心のあるスレッドをメモします。
  2. スレッド「State」で並べ替えます。
  3. 「Runnable」スレッドまでスクロールします。Runnable スレッドは、スレッドダンプが取得された際に、実際に CPU 時間を取っていたスレッドです。

注意:「Runnable」スレッドを確認する際に、このページの下部にある「Threads that can be ignored」セクションにリストされたスレッドを無視できます。

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

無視できるスレッド:

  • VM Thread:これは VM システムのスレッドです。
  • GC タスクスレッドで始まるスレッド:これらは、ガベージコレクションスレッドです。
  • java.net.PlainSocketImpl.socketAccept(Native Method) にあるコード内の - [1347028691218] に似た名前を持つスレッド:これらは、新しい接続を待機しているサーブレットエンジンのスレッドプールからのスレッドです。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー