Application Real-Time Monitoring Service:よくある質問

継続プロファイリングを有効にした後、ページにデータが表示されないのはなぜですか?

ヒープメモリモニタリングに表示されるメモリ使用率と、継続プロファイリングで特定の期間中に検出されたメモリ使用率が異なります。これは正常ですか?

継続プロファイリングは、指定された期間中のヒープメモリの割り当てのみを記録し、現在のプロセスに実際に含まれるメモリの総量を記録するわけではありません。したがって、これら 2 つのデータセット間に違いがあるのは正常です。

CPU 診断にはデータが表示されるのに、メモリ診断にはデータが表示されないのはなぜですか?

問題

メモリ診断データがない問題は、通常、Alpine ベースイメージを使用するコンテナ環境で V3.1.4 以降の ARMS エージェントで発生します。 Alpine はイメージサイズを小さくするために JDK デバッグシンボルを取り除くため、継続プロファイリング機能が無効になります。

解決策

1. 環境内の JDK にデバッグシンボルが含まれているかどうかを確認します。

2. 含まれていない場合は、イメージ内の JDK にデバッグシンボルをインストールするか (デバッグシンボルパッケージがない一部の JDK バージョンではインストールに失敗する可能性があります)、Alpine 以外のベースイメージを使用します。

コードホットスポットのデータがないのはなぜですか? コードホットスポットデータが期待どおりでないのはなぜですか?

1. JDK (Alibaba Dragonwell JDK を含む) で仮想スレッドまたは同様のテクノロジーを使用するアプリケーションでは、メモリホットスポット分析は使用できません。

2. 現在、コードホットスポット機能は SkyWalking プロトコルではサポートされていません。トレースのスパンの詳細でプロトコルタイプを確認してください。

3. コードホットスポット機能には、V3.1.4 以降の ARMS エージェントが必要です。

4. V4.2.1 より前の ARMS エージェントは同期呼び出しのみをサポートしており、データ収集が不完全になる場合があります。非同期呼び出しを行うと、データが欠落したり不正確になったりする可能性があります。たとえば、Spring Cloud Gateway、Undertow、Lettuce などのフレームワークを使用する場合、非同期スレッドの切り替えにより、データ収集が不正確になる可能性があります。エージェント V4.2.1 以降では、これらの問題を解決するために最適化されています。最適なパフォーマンスを得るには、エージェントを更新 してください。

5. コードホットスポットは、固定サンプリングレートでサンプリングされたトレースでのみサポートされます。固定されていないサンプリングレートを使用してトレースを収集すると、トレースの完了後にトリガーされる誤サンプリング (s9) や低速サンプリング (s10) など、パフォーマンスのオーバーヘッドが大幅に増加する可能性があります (スパン属性の sample.reason フィールドを確認できます)。固定されていないサンプリングレートを使用して収集されたトレースは、現在、コードホットスポットをサポートしていません。

   固定されていないサンプリングレートで収集されたトレースの場合、ホットスポット コードを含むトレースプラグインのドキュメントを確認します。 ページの パラメーターを使用して、コードホットスポットを含むトレースをフィルタリングして問題診断を行うことをお勧めします。

   

6. エージェント V4.2.1 以降を使用しているにもかかわらず、収集された期間が外部スパンによって記録された期間よりも大幅に短い場合、アプリケーションが非同期、非ブロッキング NIO フレームワーク (例: Spring Cloud Gateway) を使用している可能性があります。このようなフレームワークは、ダウンストリームサービスにリクエストを送信するときに、ダウンストリームデータの準備ができていない場合、スレッドをブロックしません。代わりに、すぐに復帰してスレッドが他のタスクを実行できるようにすることで、スレッドの利用率を向上させます。このシナリオでは実際のスレッド実行が発生しないため、パフォーマンスのボトルネックは現在のアプリケーション内にはない可能性があります。このような場合、コードホットスポットの収集期間はスパン期間よりもはるかに短くなる可能性があります。ダウンストリームアプリケーションのリクエスト処理またはネットワークレイテンシにボトルネックがないかどうかを重点的に調査する必要があります。

継続プロファイリングのパフォーマンスオーバーヘッドはどのくらいですか?

• 継続プロファイリングはテスト済みであり、一般的な Spring Web アプリケーションですべての機能を有効にした 500 TPS のシナリオでは、CPU オーバーヘッドは約 5% 増加し、オフヒープメモリ使用量は約 50 MB 増加しますが、GC とリクエストレイテンシは大幅に増加しません。

• 極端な場合、メモリホットスポット分析は現在スロットリングを実装していないため、アプリケーションが頻繁にメモリを割り当てると、関連するイベントが大量に生成される可能性があり (1 分あたり数万など)、P99 レイテンシに影響を与える可能性があります。この問題を解決するには、メモリプロファイリングを一時的に無効にすることができます。

  この問題は V4.1.10 で修正されています。エージェントを V4.1.10 以降に アップグレード できます。

アプリケーションに JFR 関連のスレッドがあるのはなぜですか?

• 継続プロファイリング機能は JFR スレッドを生成します。これらのスレッドは主に ARMS エージェント V4.1.10 に存在し、V4.1.10 以降では積極的に導入されなくなります。

• これらのスレッドは、アプリケーションのパフォーマンスボトルネックを引き起こしません。

• 継続プロファイリングを動的に無効にした後、スレッドはすぐに破棄されず、アプリケーションの再起動後にのみ消えます。

継続プロファイリングがアプリケーションの起動時間に影響を与える場合はどうすればよいですか?

継続プロファイリングを有効にするアプリケーションの場合、JDK にデバッグシンボルがなく、クラスローダーが多くのメソッドをロードする場合、起動速度が大幅に低下する可能性があります。ただし、起動が完了すると、ランタイムパフォーマンスへの影響はありません。

この問題は V4.2.1 で修正されており、アプリケーションの起動には影響しません。エージェントを V4.2.1 以降に アップグレード できます。

フレームグラフの合計メモリが実際に構成されているメモリ制限を超えているのはなぜですか?

継続プロファイリングに表示されるデータは、マシンの構成に直接関連付けられていません。データは、分析された期間中に割り当てられたヒープメモリのサイズを表します。ガベージコレクションのため、表示されるメモリがマシンの実際に構成されているメモリを超えることが予想されます。

OpenJ9 JDK の統合に失敗した場合はどうすればよいですか?

継続プロファイリングは現在、Eclipse OpenJ9 (以前は IBM J9 として知られていました) をサポートしていません。この JDK は統合に失敗し、エラーが報告される可能性があります。OpenJDK または Oracle JDK を使用することをお勧めします。

スパンのコードホットスポットデータが不完全な場合はどうすればよいですか?

コードホットスポットは、トレース内のスレッドのメソッドスタックを定期的にサンプリングすることによって収集されます。コードホットスポットフレームグラフにメソッドがない場合は、実行時間が 500 ミリ秒未満かどうかを確認してください。500 ミリ秒未満の場合、キャプチャされていない可能性があります。実行時間の短いメソッドはパフォーマンスのボトルネックになる可能性が低いため、これは関連する低速トレースの診断には影響しません。

フレームグラフに .GC_active スタックが含まれているのはなぜですか?

.GC_active は、フレームグラフデータの収集中に、アプリケーションがガベージコレクションの Stop-the-World プロセス (すべての Java ビジネススレッドが一時停止される) の影響を受けたことを示します。これにより、関連するビジネススレッドが中断されます。.GC_active がコードホットスポットに表示される場合、リクエストレイテンシの一部が GC の一時停止によって引き起こされたことを意味します。

フレームグラフに .no_Java_frame エントリが含まれているのはなぜですか?

これは一般に、Alpine ベースイメージの使用が原因です。イメージサイズを小さくするために、Alpine は JDK デバッグシンボルを削除するため、JDK 内の C++ スレッドメソッドスタックの関数名を認識できません。その結果、これらのスタックは .no_Java_frame として表示されます。これらのスタックは主に Java 以外のスレッド実行情報 (VM スレッドや JIT コンパイラスレッドなど) を表しているため、その割合が低い場合は無視して、他の Java メソッドスタックに焦点を当ててパフォーマンス分析を行うことができます。.no_Java_frame エントリの割合が高い場合は、ベースイメージの JDK にデバッグシンボルをインストールするか、Alpine 以外のベースイメージに切り替えることを検討してください。一部の JDK バージョンには対応するデバッグシンボルパッケージがないため、インストールできない場合があります。

フレームグラフに「その他」の項目が表示されるのはなぜですか?

ログ出力「parse lib sigsegv handler installed」は、実行時にアプリケーションに影響しますか?

perf_event_open の制限によって発生する「No access to perf events」エラーを解決するにはどうすればよいですか?

[ERROR] Failed to execute 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr' // [エラー] 'start,jfr=0,event=cpu,interval=11ms,alloc=512k,file=/tmp/cpc-async-profiler-7729534006755968198.jfr' の実行に失敗しました
[ERROR] Failed to start Continuous Profile Collector // [エラー] 継続プロファイルコレクターの起動に失敗しました
java.lang.RuntimeException: java.lang.IllegalStateException: No access to perf events. Try --fdtransfer or --all-user option or 'sysctl kernel.perf_event_paranoid=1' // java.lang.RuntimeException: java.lang.IllegalStateException: perf イベントにアクセスできません。 --fdtransfer または --all-user オプション、または 'sysctl kernel.perf_event_paranoid=1' を試してください

「No AllocTracer symbols found. Are JDK debug symbols installed?」エラーを解決するにはどうすればよいですか?

このエラーまたはプロファイリングデータの欠落は、Alpine ベースイメージを使用する場合に、コンテナ環境で実行されている Java プロセスで発生する可能性があります。このようなイメージは、イメージサイズを小さくするために JDK デバッグシンボルを取り除くため、継続プロファイリング機能が低下します。この場合、必要に応じて JDK のアップグレード、ベースイメージの変更、または標準の Alpine Linux と JDK の使用 を行ってください。

「perf_event mmap failed...」エラーを解決するにはどうすればよいですか?

その他

from Alpine:3.9 // Alpine:3.9 から
RUN apk add openjdk8 // RUN apk add openjdk8