よく使用される perf コマンド
perf イベントはカーネルの一部であり、tools/perf の下にあります。
コマンド:
perf record -e [probe] -ag
-a trace所有cpu
-g 追踪stack调用栈data--write-->perf.data ファイル
Ctrl-C 追跡を停止
パフォーマンスレポート表示分析レポート
コストの並べ替え:
small | stats/count はイベントの数をカウントします。
| サンプリング
大|トレースはイベントの詳細を収集します
V
具体的な使用法は man にあります。
カテゴリ別のパフォーマンス命令のリスト
リスト：
perf list はすべてのイベントをリストします
perf list 'sched:*' は特定のタイプのトレースポイントをリストします
カウンター：
perf stat とさまざまなパラメータ
perf stat コマンド (特定のコマンドまたは PID 用)
-d 詳細を表示します
-p PID
-すべてを記録します'
スリープ 5 5 秒間録音します
プロファイリング/サンプリング
perf レコードでは、特定のコンテンツを監視するために cmd または -p PID も追加します
-F サンプリング周波数単位 Hz
-g コールスタックをキャッチ
--call-graph dwarf スタックを記録するためにドワーフ シンボルを使用します
「--」についてはパラメータ付きコマンドの前に付けるようです。
ダイナミックプローブ
perf プローブ コマンド
perf プローブの使用では、多くの場所でデバッグ情報が必要になります。これは gcc -g が必要ということですか?
[--add] tcp_sendmsg カーネル関数のエントリにトレースポイントを追加します
-d/--del 削除TP
-V 使用可能な変数を表示します
perf プローブは、「probe:*」の下にトレースポイントを追加するようです。これは、perf レコードを通じて有効にして記録できます。
レポートを表示
perf レポート レポート形式の出力
perf スクリプトはすべてのイベント レコード (レコード テーブルの詳細エントリ) をリストします。
ftrace と perf
ftrace は debugfs に基づくフロントエンドのセットです
基礎となるデータ ソースも、tracepoint kprobe uprobe です。
一般的なルーチン:
perf-->サンプリング分析
|
v
ホットスポット機能→ftrace定量分析→呼び出し処理
フロントエンドツール:
デバッグ
trace-cmd----------> debugfs の操作のカプセル化
パフォーマンスツール
利用可能なトレース処理機能サブルーチン
++++++++++++++++++++++++
perf サンプリングを関数で横断することはできません
子供 |
自己 |
自分とサブ関数のスコア比率を計算します |
それ自体内のサブ関数の外にあるパーセンテージのみをカウントします。 |
パフォーマンスインストール
perf を使用してインストールするように求められる場合がありますが、プロンプトに従ってインストールするか、カーネル ソース コードからコンパイルしてインストールすることもできます。
必要なシンボルを使用するには、いくつかのパッケージをインストールするか、カーネル構成オプションを有効にする必要がある場合があります。
シンボルについて
-> 記号は、アドレスから関数または変数名にマッピングして、人々が理解できるようにするのに役立ちます。
-> perf を使用すると、通常は「--dbgsym」で終わるシンボルを含むデバッグ パッケージのインストールを求めるプロンプトが表示される場合があります。
-> ビルドシステム構成をチェックしてシンボル情報を保存できます。
-> カーネルレベルのシンボルの場合、カーネルの debuginfo パッケージをインストールするか、CONFIG_KALLSYMS を有効にすることができます。
スタックトレース
コンパイル時にフレーム ポインタを省略しないでください。
GCC で利用可能なコンパイル パラメータ:
-fno-省略フレームポインタ
カーネルの場合は次のようになります。
CONFIG_FRAME_POINTER=y
コードのバックトレースは FP なしでは記録できません。ドワーフやLBRをトッピングすることもできますが、使いにくいかもしれません。
トレースポイントを有効にする
perf record -e 'sched:sched_process_*' -a sleep 5トレースポイントはサンプリング/プロファイリングを使用してキャプチャされませんか? 周波数の影響を受けないのでしょうか？
周波数ごとに CPU をサンプリングしてコール スタックを取得する
perf record -F Hz原理は、定期的な割り込みイベントを作成して、perf がポインターを同時にキャプチャおよび記録できるようにすることです。
イベントソース
ソフトウェアイベント
数値を除いたパフォーマンスによって提供されます
ソフトイベントにはデフォルトの期間があり、サンプリング時に一定量が収集され、一度レポートされます (そうでない場合、レポートが多すぎる場合は、スタック上の 1 つを確認するだけで十分です)。詳細は perf Record -vv で確認できます。 。
PMC
ハードウェア パフォーマンス カウンターとプロセッサ関連
実際、レジスタは通常、さまざまなイベントが発生した回数を記録するために多重化されています。さまざまな機能を実現します。設定するには。
アプリケーションシナリオ: CPU サイクル、キャッシュミスなど
カーネルトレースポイント
カーネルに埋め込まれたコードは、より安定した独自のトレース ツールの開発に使用できます。
設計者が慎重に検討した結果、非常に一般的に使用されています。
USDT
ユーザーレベルコードの静的埋め込みポイント
まず、dtrace に代表される USDT ライブラリを環境にインストールする必要があります。【APIも比較的安定しています】
例: apt install systemtap-sdt-dev
dtraceをインストールする
次に、埋め込まれた USDT API のコードをライブラリと一緒にコンパイルします。
例: ./configure --with-dtrace
make -j64
DtraceはUSDTの代表であり、LTTngもUSDTを持っています
ダイナミックトレーシング
コードを掴む間にあるので不安定
perf プローブ間にトレースポイントを追加 --add
カーネルとプログラムの実行中に動的に増やすことができ、新しく追加された命令の一部をプローブで実行できます。
使用前もオーバーヘッドも発生せず、プローブの削除後もオーバーヘッドは発生しません。
統計統計 (PMC)
PMC を分析するための perf stat CMD
一般的に使用される指標「サイクルごとの insns」は、いわゆる IPC です。サイクルごとの命令。
IPC 高 ---> CPU スループット 高 ---> 非常に良い
低い IPC ---> ストールの増加
スピンロック CPU がアイドル状態で動作していないことに注意する必要があります。
perf stat -d を使用すると詳細をさらに確認できます。
より有用な指標は、「インスタントごとの停止サイクル」です。
mem を表し、リソース バス アクセスはレイテンシーを表します。低いほど良いです。
分析する
時間指定プロファイリング
一定時間間隔で命令ポインタとスタックトレースをサンプリング
例： パフォーマンス レコード -F 99 -a -g --sleep 30
[100 Hz ではなく 99 Hz でサンプリングするのは、特定の周期的なタスクとの競合やオフセットの発生を防ぐためです]
イベントプロファイリング
クロックの代わりにハードウェア時間をサンプル トリガーとして使用する
短期間に非常に多くのハードウェア イベントが発生する可能性があり、毎回ログを記録するとオーバーヘッドが大きくなりすぎる可能性があります。
したがって、通常は -C count を使用してトリガーしきい値を設定します。
これだけ多くのイベントを取得した後、スタックは 1 回だけ記録されます。
例: perf Record -e Lrdxaxhe-load-misses -c 10000 -ag -- sleep 5
知らせ：
多くの CPU は、ロックステップを回避するために、サンプルをトリガーした後に意図的に小さな遅延を導入します。
これは時間プロファイリングにはほとんど影響しませんが、イベント サンプリングの不正確なサンプリングを引き起こします。
解決策: いわゆる「正確なサンプリング」
すべての PMC が正確なサンプリングをサポートしているわけではありません。確認するには、「perf Record -vv」を通じて「precise_ip」の値をチェックします。
PMC イベントの後に「:p」を追加してメソッドを有効にします
例: 「-e 命令:p」
静的カーネル トレース
トレースポイントやその他の静的イベントもカウンターを使用してカウントできます
例: perf stat -e "syscalls:sys_enter_*"
perf と strace の比較
strace の最下層は ptrace を使用するもので、原理は GDB と似ています。ブレークポイント コードの実行はターゲットの場所で実行されます。strace 実行のオーバーヘッドは膨大です
動的トレース
カーネルオプション:
CONFIG_KPROBES=y
CONFIG_KPROBE_EVENTS=y
CONFIG_FRAME_POINTER=y
CONFIG_UPROBES=y
CONFIG_UPROBE_EVENTS=y
デバッグ情報が有効な場合
CONFIG_DEBUG_INFO=y
関数内のカーネル変数を記録可能
各レコードの現在の変数のサイズを表示します。
例えば：
perf プローブ -V tcp_sendmsg は使用可能なすべての変数をリストします
perf プローブ --add 'tcp_sendmsg size' プローブとレコード サイズを同時に追加します
perf Record -e プローブ:tcp_sendmsg -a を有効にして記録を開始します
debuginfoの場合、カーネル関数の行番号に応じてトレースポイントを追加することもできます
例：
perf プローブ -L tcp_sendmsg は利用可能な回線プローブをリストします
perf プローブ -V tcp_send:81 は 81 行目に表示される変数をリストします。
perf プローブ --add 'tcp_sendmsg:81 Sail' 追加プローブ
perf Record -e プローブ:tcp_sendmsg -a 記録の開始