Application Real-Time Monitoring Service (ARMS) は、CPU / メモリ使用率の高さやレイテンシの急上昇など、パフォーマンスボトルネックの根本原因分析のためにフレームグラフを生成する継続的プロファイリング機能を提供します。
フレームグラフとは
フレームグラフは、呼び出しスタック階層とその実行時間の分布をグラフィカルに表現する視覚的なプロファイリングツールであり、開発者がパフォーマンスボトルネックを特定できるようにします。
フレームグラフは、x 軸、y 軸、および複数のボックスで構成されます。 各ボックスはスタック内の関数を表します。 x 軸は関数のリソース使用率の割合を測定し、y 軸は関数の深さを測定します。 異なる時点のフレームグラフを比較することにより、プログラムのパフォーマンスボトルネックを効率的に診断および処理できます。
カテゴリ
フレームグラフは、フレームグラフ（狭義）とアイシクルグラフの 2 つのカテゴリに分類されます。 狭義のフレームグラフでは、図 1 に示すように、最上位要素は上部に、最下位要素は下部にあります。 アイシクルグラフでは、図 2 に示すように、最上位要素は下部に、最下位要素は上部にあります。
図 1. フレームグラフ（狭義）
図 2. アイシクルグラフ
フレームグラフを使用する
フレームグラフはスタックを表すため、ボックスの幅が広い関数は、ボックスの幅が狭い関数よりも多くの CPU を消費します。
コンピュータサイエンスでは、スタックは、プッシュとポップという 2 つの主要な操作を持つ要素のコレクションとして機能する抽象データ型です。 プッシュ操作はスタックに要素を挿入し、ポップ操作はスタックから要素を削除します。 スタックの底部には最初に呼び出された関数が含まれ、スタックの最上部には最近呼び出された子関数が含まれます。 最後の 子関数が最上位で実行されると、スタックから削除されます。 関数の実行に消費される時間が長いほど、その親関数で消費される時間も長くなり、次の図に示すように、ボックスの幅が広くなります。
フレームグラフを分析するには、次の手順を実行します。
フレームグラフの種類に基づいて最上部を見つけます。
フレームグラフのリソース使用量の合計が高い場合は、スタック最上部に幅の広いボックスがあるかどうかを確認します。
スタック最上部に幅の広いボックスがある場合は、上から下へと検索し、アプリケーションで定義されている最初のメソッドを見つけ、そのメソッドを最適化できるかどうかを確認します。
例
次の図は、リソース使用率が高いフレームグラフを示しています。 継続的プロファイリング機能を有効にすると、次の手順を実行してパフォーマンスボトルネックを発見できます。
スタック最上部が下部にあり、スタック底部が上部にあるアイシクルグラフであるため、下から上に分析する必要があります。
手順 2: WordPress アプリケーションをデプロイする
java.util.LinkedList.node(int)java.util.LinkedList.get(int)com.alibaba.cloud.pressure.memory.HotSpotAction.readFile()com.alibaba.cloud.pressure.memory.HotSpotAction.readFile()com.alibaba.cloud.pressure.memory.HotSpotAction.readFile() メソッドは Java 開発キット (JDK) のライブラリ関数であるため、さらに上に検索する必要があり、 メソッドとその親メソッドである を見つけることができます。 アプリケーションで定義された最初のサービスメソッドとして、 メソッドは 3.89 秒を消費し、スタックの 76.06% を占めます。 したがって、 メソッドは、指定された期間に大量のリソースを消費するという結論を出すことができます。 このメソッドを使用して、関連メソッドのロジックを分析し、最適化できるかどうかを確認できます。
さらに、フレームグラフの左下隅にある java.net.SocketInputStream メソッドに基づいて、アプリケーションで定義された最初の親メソッドが com.alibaba.cloud.pressure.memory.HotSpotAction.invokeAPI であり、スタックの約 23% を占めていることがわかります。
関連情報
継続的プロファイリング機能を使用する場合:
CPU とメモリの使用率が高い問題のトラブルシューティングについては、以下を参照してください。
一般的な問題のトラブルシューティング。