Application Real-Time Monitoring Service:コードホットスポットによる Java の低速な呼び出しの診断

利用シーン

• 販売促進などの高トラフィックイベント中に低速な呼び出しが発生した場合に、問題のあるコードを迅速に特定します。

• システムで大量の低速な呼び出しが発生した場合に、実行コンテキストを自動的に保存します。

• 再現が困難な複雑または断続的な低速な呼び出しに対して、正確なメソッドレベルの実行パスを再構築します。

• トレースに非フレームワークメソッドのイベントトラッキングがない場合、コードホットスポット機能はこれらのメソッド呼び出しの実際の実行時間を特定するのに役立ちます。

前提条件

• コードホットスポット機能には、エージェントバージョン 3.1.4 以降が必要です。

• コードホットスポット機能は継続的プロファイリングに依存しており、オペレーティングシステムのカーネルと JDK のバージョンに特定の要件があります。詳細については、「制限事項」をご参照ください。互換性のあるオペレーティングシステムと JDK を使用していることを確認してください。

• 4.2.1 より前のエージェントバージョンは、同期呼び出しのみをサポートします。非同期呼び出しの場合、データが失われる可能性があります。たとえば、Spring Cloud Gateway、Undertow、または Lettuce を使用する場合、非同期のスレッド切り替えによりデータ収集の不正確さが発生する可能性があります。エージェントバージョン 4.2.1 以降は、非同期シナリオをサポートします。

コードホットスポットの有効化

1. ARMS コンソールにログインします。左側のナビゲーションウィンドウで、Application Monitoring > アプリケーションリストを選択します。

2. アプリケーションリスト ページで、上部でリージョンを選択し、ご利用のアプリケーションの名前をクリックします。

   説明

   言語 列のアイコンは、次のことを示します：

   ：アプリケーションモニタリングに接続された Java アプリケーション。

   ：アプリケーションモニタリングに接続された Go アプリケーション。

   ：アプリケーションモニタリングに接続された Python アプリケーション。

   -：トレースエクスプローラー (OpenTelemetry) に接続されたアプリケーション。

3. 左側のナビゲーションウィンドウで アプリケーションの設定 をクリックし、次に カスタム設定 タブをクリックします。

4. [継続的プロファイリング] セクションで、 [メインスイッチ] をオンにし、次に [コードホットスポット] スイッチをオンにします。この機能を有効にしたいアプリケーションインスタンスの IP アドレスまたはインスタンスグループの CIDR ブロックを設定します。

5. ページの下部で、保存 をクリックします。

   この変更は、アプリケーションを再起動することなく、すぐに有効になります。

コードホットスポットデータの分析

この例では、JSON データを解析して反復処理し、ダウンストリームの HTTP API を呼び出します。

public class HotSpotAction extends AbsAction {
  private RestTemplate restTemplate = new RestTemplate();
  // Request entry method.
  @Override
  public void runBusiness() {
    readFile();
    invokeAPI();
  }
  // Make an HTTP call.
  private void invokeAPI() {
    String url = "https://httpbin.org/get";
    String response = restTemplate.getForObject(url, String.class);
  }
   // Read and parse file data.
  private double readFile() {
    InputStreamReader reader = new InputStreamReader(
        ClassLoader.getSystemResourceAsStream("data/xxx.json"));
    LinkedList<Movie> movieList = GSON.fromJson(reader, new TypeToken<LinkedList<Movie>>() {
    }.getType());
    double totalCount = 0;
    for (int i = 0; i < movieList.size(); i++) {
      totalCount += movieList.get(i).rating();
    }
    return totalCount;
  }
}

1. ARMS コンソールにログインします。左側のナビゲーションウィンドウで、Application Monitoring > アプリケーションリストを選択します。

2. アプリケーションリスト ページで、上部でリージョンを選択し、ご利用のアプリケーションの名前をクリックします。

   説明

   言語 列のアイコンは、次のとおりです。

   ：アプリケーションモニタリングに接続された Java アプリケーション。

   ：アプリケーションモニタリングに接続された Go アプリケーション。

   ：アプリケーションモニタリングに接続された Python アプリケーション。

   -：Managed Service for OpenTelemetryに接続されたアプリケーション。

3. 左側のナビゲーションウィンドウで、 [インターフェイス呼び出し] をクリックします。ページの右側で、ターゲットインターフェイスを選択し、 [トレースクエリ] タブをクリックします。

4. [トレースクエリ] タブで、ターゲットの TraceId リンクをクリックします。

5. [詳細] 列で、虫眼鏡アイコンをクリックし、次に [コードホットスポット] タブをクリックします。

   左側のパネルには、この呼び出しに関与するすべてのメソッドとその実行時間が一覧表示されます。右側のパネルには、選択したメソッドのスタックトレースを可視化するフレームグラフが表示されます。

   • [Self] 列には、子メソッドによって消費された時間やリソースを除き、メソッド自体の実行中に消費された時間やリソースが表示されます。これにより、自身のロジックでかなりの時間を費やしているメソッドを特定するのに役立ちます。

   • [Total] 列には、メソッドとそのすべての子メソッドによって消費された時間やリソースが表示されます。これにより、呼び出しスタックの全体的な実行時間に最も寄与しているメソッドを理解するのに役立ちます。

   特定のコードホットスポットを特定するには、 [Self] 列に注目するか、フレームグラフの下部にある幅の広いバーを探します。幅の広いバーは、高レイテンシーの根本原因を示し、多くの場合、java.lang.Thread.sleep() メソッドなどのシステムパフォーマンスのボトルネックを表します。

   次のようにデータを分析します：

   1. Self 列を降順でソートします。java.util.LinkedList.node(int) など、Self の値が最も高いメソッドをクリックします。右側のフレームグラフは、関連するメソッドにフォーカスします。

   2. フォーカスされたビューでは、java.util.LinkedList.node(int) がフレームグラフのスタックの最上部で最も幅の広いバーであることがわかります。

   3. このメソッドは、ご利用のアプリケーションのビジネスロジックではなく、Java 開発キット (JDK) のライブラリ関数です。コード内のソースを見つけるには、java.util.LinkedList.node(int) から呼び出しスタックを上にたどります。これは java.util.LinkedList.get(int) によって呼び出され、さらに com.alibaba.cloud.pressure.memory.HotSpotAction.readFile() によって呼び出されます。com.alibaba.cloud.pressure.memory.HotSpotAction.readFile() メソッドは、ご利用のアプリケーションの一部です。この例では、3.75 秒を消費しており、これはフレームグラフの合計時間の 69.88% を占めています。これは、com.alibaba.cloud.pressure.memory.HotSpotAction.readFile() が重大なパフォーマンスボトルネックであることを示しています。このメソッドのロジックを分析して、最適化の機会を特定してください。

よくある質問

• コードホットスポットに表示される持続時間が、リクエストの合計持続時間よりも短いのはなぜですか？

  ご利用のアプリケーションへのパフォーマンスへの影響を最小限に抑えるため、コードホットスポット機能は最適化された収集メカニズムを使用します。これにより、記録された持続時間が実際のリクエストの持続時間よりわずかに短くなることがあります。この偏差は通常 20 ms 以内です。このわずかな違いは無視し、相対的な持続時間が最も長いメソッドに注目してください。

• コードホットスポットのデータ収集範囲に制限はありますか？

  • 15 分以上続くリクエストの場合、コードホットスポット機能は最初の 15 分間の分析データのみを提供します。

  • システムオーバーヘッドを削減するため、ARMS は低レイテンシーのリクエストに対してコードホットスポットデータを収集しません。これらは通常 500 ms 未満で完了するリクエストですが、正確なしきい値はシステム負荷に基づいて動的に決定されます。その結果、これらのリクエストに対してはタブにデータが表示されない場合があります。

関連トピック

継続的プロファイリング機能を使用して、高い CPU およびメモリ使用率の問題をトラブルシューティングできます。詳細については、次のトピックをご参照ください：

• フレームグラフを使用してパフォーマンスボトルネックを特定する

• CPU ホットスポットプロファイリングを使用して高い CPU 使用率を診断する

• メモリホットスポットプロファイリングを使用して高いヒープメモリ使用量を診断する