管理

perf top Linux：カーネル内のCPUホットスポットを特定する

と一緒に perf top Linuxでは、現在どのカーネル関数が最も多くのCPU時間を消費しているか、またどこにボトルネックが生じているかを、わずか数秒で特定できます。このガイドでは、明確な手順に沿って、ライブホットスポットを特定し、出力結果を正確に解釈し、そこからスケジューラ、ネットワーク、メモリの迅速な最適化策を導き出す方法を解説します。.

中心点

私は、のライブビューを パーフェクト 強力な出発点として最適です。なぜなら、最も時間を浪費している箇所を即座に可視化してくれるからです。各アイコンの割合を見ることで、ボトルネックが カーネル あるいはユーザースペースにあるかどうか。繰り返し現れるパターンから、ロック、IRQ、ネットワーク、メモリのどれが主な原因かを特定します。その後、より詳細なツールを使って問題箇所を絞り込み、負荷がかかった状態で変更内容を直接検証します。このようにして、段階的に CPU-稼働率を向上させ、レイテンシを持続的に低減する。.

ライブ・ホットスポット 特定し、優先順位をつける
割合機能ごとに正しく解釈する
中核的な焦点 設定：IRQ、ロック、メモリ
ワークフロー: トップ → 記録 → レポート
最適化 的を絞って検証する

「Perf Top」とは何ですか？また、どのような用途に使いますか？

私はこうしている。 perf top, 、実行中の負荷において、どのシンボルがCPU時間を最も多く消費しているかを即座に確認するためです。このツールはハードウェア・パフォーマンス・カウンターにアクセスし、CPU時間を最も多く消費している関数の最新ランキングを短い間隔で表示してくれます。『Linux-Magazin』誌によると、perfはプロファイリングとトレースの両方をこなすため、 ライブビュー より詳細な分析とシームレスに結びつけます。通常のフローでは、その瞬間の状況を「perf record」と「perf report」で補完し、コールグラフや正確な実行パスを調査します。そうすることで、次の核心的な疑問に答えるのです。「どこで CPU 今まさにその処理が行われているのは、ネットワークスタック、メモリサブシステム、スケジューラ、それともドライバの中でしょうか？

perf top をインストールして起動する

ディストリビューションパッケージによるインストール後、次のように実行します。 パーフェクト top は通常、カーネルシンボルやシステムイベントが表示されるよう、拡張権限で実行されます。「perf top」と入力するだけで簡単に起動でき、最初のライブビューを表示して、主要な機能を把握することができます。個々のプロセスに焦点を当てたい場合は、 PID -p オプションで開始します。特定の CPU については、リストまたは範囲を指定して -C オプションを使用します。イベントは -e オプションで指定します。例えば、cpu-cycles、instructions、branch-misses など、解明したい課題に応じて選びます。再現性のある結果を得るために、実際の負荷がかかっている状態で測定を開始し、 ホットスポット はっきりと示され、アイドル時のノイズに埋もれないようにすること。.

この号の読み方

このリストでは、まず パーセント値 各シンボルごとに、それらが相対的な時間配分を反映しているためです。システム関数の割合が高い場合はカーネルのボトルネックを示唆し、ユーザースペースのシンボルが支配的な場合はアプリロジックに起因する可能性が高い。スケジューラルーチンが多く見られる場合は、アクティブなスレッドの過剰、不適切なアフィニティ、あるいは不適切な優先順位を疑う。メモリ関連の関数が上位に表示される場合は、割り当てパターン、ページフォールト、NUMAの局所性、およびキャッシュを確認します。ネットワークパスに関しては、IRQの分布、Gro/TSOの設定、およびドライバの挙動に注目します。なぜなら、こうした詳細が レイテンシー 大きな影響を与える。.

カーネルのホットスポットが生じる典型的な原因

多くのホットスポットは、多くの小さなコストが積み重なって大きなものになるために発生する負荷合計される。多くの場合、過度なコンテキスト切り替え、ロックの競合、および不均等に分散されたIRQがCPU時間を増加させる。同様に、断片化されたメモリ構造、非効率的なスラブの使用、あるいは絶え間ないページングも、不要なサイクルを消費する。特定のドライバに問題が見られた場合、副作用を限定するために、ワークロード、ハードウェア、バージョンとの相関関係を調べます。また、マルチコアシステムでは、カーネルドキュメントによると、共有キャッシュラインはすぐに高コストな オーバーヘッド 心配になるかもしれない。.

ホットスポットの分析例

長期間にわたり、ネットワーク関連の機能の割合が著しく高いことが確認された場合、まず最初に、パケットサイズ（小 vs. 大）、TLS vs. 平文、多数の接続 vs. 少数の長期セッションといった負荷の種類を分類し、その原因範囲を絞り込みます。その後、`perf record` と `perf report` を使って詳細を分析し、コールグラフ（-g）を有効にして、複数回の実行結果のパスを比較します。その代わりにメモリ管理が問題となる場合は、アロケータ、Huge Pages、THP設定、NUMAアフィニティを確認します。これらの領域では、不要なパスが容易に発生するからです。スケジューラのホットスポットについては、多くの場合、実行可能スレッド（Runnable）が多すぎるか、CPUへのバインディングが不適切であることの兆候だと解釈しています。私は常に、一度に1つだけ パラメータ 1回の実行ごとに、効果を正確に特定できるようにするためです。.

ホスティング環境における最高のパフォーマンス

ホスティングの現場では、わずかなカーネルコストが レイテンシー 多くのサービスの負荷が積み重なる。並行して実行されるコンテナ、VM、データベースインスタンスにより、負荷プロファイルはネットワーク、ストレージ、スケジューラへと大きくシフトする。perf top を使用することで、ボトルネックがIRQ処理、SoftIRQ処理、あるいはロックパスのいずれにあるかを特定できる。その後、カーネルバージョン、NUMAレイアウト、IRQアフィニティ、キューの深さを検証に組み込みます。これらは相互に作用する要因だからです。さらに深く掘り下げたい方は、このガイドを参照してください。 CPUのボトルネックを分析する私が実務で日常的に活用している、その他の実用的なアプローチです。.

分析のための実践ガイド

測定結果の比較可能性を確保するため、再現可能な負荷シナリオから始め、 ホットスポット 安定して現れるのを待ちます。その後、perf top を実行し、数回の更新にわたって支配的なシンボルを記録します。このスナップショットを perf record/report を使ってコールグラフの明確な図にまとめ、コストのかかる箇所へのパスを特定できるようにします。その後、IRQアフィニティやキューの深さなど、特定の要素を1つだけ変更し、再度測定を行います。その効果が明確になって初めて、次のステップに進みます。 ステップ について検討し、その知見を将来のメンテナンス期間に備えて記録しておく。.

どのような場合に他のツールが適しているか

歴史的な視点や、より詳細なコールグラフ、あるいは特定のイベントチェーンを確認する際には、私は パーフェクト record/report、ftrace、あるいはeBPFです。トレースポイントを使えば特定のパスを詳細に分析でき、BPFプログラムを使えば柔軟なメトリクスを取得できます。カーネルのパスをさらに深く調べたい場合は、 eBPF解析ツール発生現場で直接得られる貴重なシグナル。キャッシュや共有に関する問題については、ホットスポットが明確に特定されれば、perf-c2c や pahole が役立ちます。このようにして、無関係な情報に惑わされることなく、ライブビューから原因の特定へと分析を進めていきます。詳細を失う。.

サンプリングオプションとフィルターの実践的な活用

私はそれを調整します。 サンプリング- すべてを一律に測定するのではなく、問題に応じて戦略を調整します。散発的なスパイクが発生した場合は、サンプリング頻度を高め、表示間隔を短縮して、一過性のピークを捕捉します。プロセスに焦点を当てる場合は、-pオプションで対象のPIDを指定し、CPUに焦点を当てる場合は-Cオプションで負荷の高いコアを指定します。-eオプションでイベントを制御し、広範囲なプロファイリングにはcpu-cyclesを、メモリ動作に問題がある疑いがある場合はcache-missesなどを指定します。ホットスポットを大まかに特定し、原因スタック内で見つけたい。.

以下の表は、私が日常的によく組み合わせて使っている実用的なスイッチと、各オプションの代表的な用途を示しています：

オプション	効果	用途
-p PID	測定を1つのプロセスに限定する	アプリ固有のホットスポット絞り込む
-C CPU一覧	厳選された中核分野に焦点を当てる	NUMA/IRQの割り当てを確認する
-e イベント	ハードウェアイベントまたはソフトウェアイベントを選択してください	サイクル、命令、キャッシュミス
-g	Callgraphサンプリングを有効にする	『』の中の高価な道スタック認識する
–カーネル/–ユーザー	カーネル空間またはユーザー空間でフィルタリングする	CPU時間の発生源を特定する
–sort	シンボル、DSO、dso:symbol で並べ替え	読みやすさランキング増加

長時間の測定を開始する前に、常に設定を簡単にテストしています。そうすることで、表示安定した状態が維持され、副作用が発生しないことを確認します。特にサンプリング周波数が高い場合は、システムに不必要な負荷をかけないよう、オーバーヘッドに注意を払っています。コンテナホストについては、さらにネームスペースやcgroupの制限によって可視性が制限されていないかを確認します。再現性のあるベンチマーク結果を得るために、カーネルやドライバのバージョンを含め、すべての設定オプションを記録しています。この徹底した記録作業のおかげで、後々多くの手間が省けます。時間変化を分類する際。.

サブシステムの解釈：ネットワーク、メモリ、スケジューラ

ネットワークパスが上位にある場合、私はまずIRQアフィニティ、RSS（Receive-Side-Scaling）、およびGRO/TSOなどのオフロード機能を検証します。なぜなら、これらの調整パラメータが スループット-レイテンシのバランスを調整する。メモリ関連の異常が見られる場合は、割り当てパターン、Huge Pages、スラブ統計、ページフォールト率を確認する。スケジューラの負荷は、多くの場合、スレッド数の過剰、CPUアフィニティの設定不足、あるいは不適切な優先順位付けと関連している。特定のカーネルイベントを特定するために、トレースポイントを追加で設定するか、またはホスティングにおけるbpftrace, 、仮説を検証するために。このようにして、perf topでのリアルタイム観測データをより深い測定地点のデータと結びつけ、より迅速に本来の原因.

アイコンの表示条件と可視性

だから perf top 関連するすべてのカーネルシンボルを展開する際、私は2つの点に注意を払っています。それは、適切な権限と利用可能なシンボル情報です。本番環境では、 kernel.perf_event_paranoid 多くの場合、この値は高く設定されています。カーネルの詳細な情報を確認する必要がある場合は、この値を一時的に下げるか、必要な権限（CAP_PERFMON/CAP_SYS_ADMIN）を持つrootユーザーとして作業します。カーネルアドレスが隠されている場合（kptr_restrict)、それでもたいていは関数名は表示されますが、生アドレスは表示されません――私にとっては、優先順位をつけるにはそれで十分です。ユーザースペースについては、perf topがオフセットではなく関数名を表示するように、関連するデバッグ情報パッケージをインストールしています。これにより、当て推量を減らし、原因の特定を早めることができます。.

パーセンテージとサンプリングの落とし穴

リストにあるパーセンテージについては、私は次のように解釈しています。 相対的な割合 測定されたサンプルの値であり、時間軸上の正確なCPU使用率ではありません。複数のイベントを選択すると、 多重化 適用：Perfはカウンターを時間軸に沿って分散させ、 ノーマライズ 表示について。明確な傾向を把握するため、まずはCPUサイクルや命令数で広範囲に測定し、特殊なイベントは後で追加するようにしています。短時間のスパイクは、より高い周波数（-F）と短い間隔で捕捉します。システムが安定している場合は、標準の周波数で十分です。また、以下の点にも注意しています。 アイドル-位相や周波数の変化（ターボ、ガバナー）によって知覚が歪む可能性がある。そのため、比較測定を行う際には、クロック設定とエネルギー設定を統一している。.

コールグラフの深層分析

ホットスポットを特定したら、コールグラフを活用してその有効性を高めます。 -g そして、適切なアンワインディング手法を用いることで、コストのかかる箇所のパスが特定できます。フレームポインタやDWARFアンワインディングにより安定したスタックが得られます。利用可能な場合は、非常に正確なトレースチェーンを得るために、ハードウェア支援型のリターンバッファ（LBR）を使用します。オーバーヘッドを最小限に抑えるため、mmapバッファは必要な分だけ増やします。スタックに多くのヘルパー関数が表示される場合は、以下の点に注意を払います。 を含む 対限定コスト：重要なのは、その機能自体がコストがかかるものなのか、それとも単なる通過点としてコストを占めているだけなのかという点です。この区別をつけることで、原因究明にかかる時間をしばしば数時間分節約できます。.

コンテナおよびVMでの作業

コンテナ環境では、私のビューが cgroups およびネームスペースが正しいことを確認します。測定は関連するPIDとCPUに絞ることで、ノイズの多い近隣プロセスが結果を歪めるのを防ぎます。 VMについては、仮想PMUが有効になっているかを確認します。有効になっていないと、正確なハードウェアイベントが取得できず、主にソフトウェアのシグナルしか確認できなくなります。KVMホストは、多くの場合、周囲のシンボルから識別できます。 kvm_vcpu 或いは vmx/svm. このような状況では、原因と結果を混同しないよう、ホストとゲストの分析を明確に区別しています。.

認識可能なパターンと迅速な仮説

日常生活では、特定のパターンが有効であることが分かっているので、私はすぐにそれを確認するようにしています：

ロック・コンペティション: ダイビング queued_spin_lock_slowpath 或いは mutex_spin_on_owner 上の方では、データ構造の分割が粗すぎたり、ワークキューの幅が狭すぎたりしています。シャーディング、ロック粒度の微調整、またはバッチサイズの変更によって、競合を軽減します。.
スケジューラ印刷: 増え続けている schedule(), pick_next_task_fair あるいはウェイクアップパスについては、スレッド数、アフィニティ、優先度を調整します。多くの場合、「おしゃべりな」スレッドを落ち着かせたり、CPU設定を明確に定義したりするだけで十分です。.
ネットワーク・ソフトIRQ: ピークは net_rx_action, napi_poll あるいは、チェックサムのオフロードが発生している場合は、パケットストームや、RSSおよびIRQの割り当てが最適でないことを示唆しています。私はIRQを適切なコアに割り当て、希望するスループット／レイテンシのプロファイルに合わせてGRO/TSOを調整します。.
保存パス: 多くの時間を do_page_fault, copy_user_* あるいはスラブ関数を使用することで、割り当てパターン、THP/Huge Pages、NUMAの局所性を確認できます。ここでの不適切な配置は、気づかないうちに非常に多くのサイクルを浪費してしまいます。.
RCUとタイマー: 支配する rcu_core あるいはタイマーコールバックなどについては、システムの動作をより安定させるために、各サービスのポーリングやバッチ処理の戦略を見直しています。.

測定の厳密さと再現性をさらに深める

正確に比較可能な実行結果を得るため、環境要因を一定に保っています。具体的には、CPUガバナー、ターボステート、バックグラウンドジョブ、さらには高密度ノードにおける室温までです。テスト負荷を定義済みのコアに割り当て、必要に応じて負荷の高いCPUを隔離することで、スケジューラの判断が安定するようにしています。変更内容については、カーネル、ドライバ、ファームウェアのバージョンを含めて記録します。リスクの高い調整を行う場合は、ロールバックポイントを設定し、変更直後に再度測定を行います。これにより、信頼性の高い ビフォー／アフター-数ヶ月経った今でも、その経緯をたどることができる話だ。.

実用的なコマンド：私がよく使うコマンド

質問の内容に応じて、簡潔なレシピを紹介しています：

負荷下での広範囲なスコープ調査: perf top -e cpu-cycles –kernel –user
カーネルとユーザースペースのどちらが主導権を握っているかを素早く把握する。.
Callgraph を用いたプロセス分析: perf top -p PID -g –kernel –user
システムノイズを伴わずに、該当するアプリケーションのライブパスを表示してください。.
CPU特集: perf top -C 2-5 -e cpu-cycles -g
NUMAやIRQのホットスポットにおいて、ごく一部のコアだけが「過熱」している場合に役立ちます。.
窃盗の容疑: perf top -e cache-misses -e cycles -g –kernel
サイクルに対するメモリパスの割合を一瞬表示します。.
一時的なスパイクを固定する: perf top -F 999 -I 1000 -e cycles
周波数を高くし、表示間隔を短くすることで、短いピークを捉えることができます。.

具体的なサブシステムに関する解釈の指針

時点では ネットワーク NAPIやRX/TXパスに加え、ハンドシェイクの発生量が多い場合には支配的になり得るTLS/暗号化の割合も監視しています。ゼロコピーやコアリセシングが適切に機能しているか、また大きなセグメント（TSO/GSO）がレイテンシの許容範囲を超えているかを確認します。 メモリ-この点についてはTHPを確認しています：これは私の負荷軽減に役立つのか、それともスプリット／マージイベントが邪魔になるのか？ ストレージ 私は解釈する blk_mq-シンボルとio_uringパスは、キューの深さやマージ戦略を示す指標として用いられる。 スケジューラ WakeupアバランチをLockチェーンやIOチェーンと組み合わせ、スレッド数を増やすのではなく、バックプレッシャーを用いてパスの負荷を分散させます。.

「パーフェクトトップ」の限界と、私が方針転換するタイミング

なぜなら perf top サンプリングベースであるため、個々のイベントよりも平均的な傾向の方が把握しやすい。決定論的な処理チェーンについては、正確な因果関係を立証するために、トレースポイント、ftrace、またはeBPFに切り替えます。正確な定量化（例：リクエストあたりの命令数）が必要な場合は、以下と組み合わせて使用します。 パースタット あるいは、perf record/report によるオフライン分析。不明瞭なスタック（シンボルの欠落、アンワインディングの不具合）に遭遇した場合は、まず可視性を確保します。そうしなければ、暗中模索に過ぎないからです。.

簡単にまとめると

と一緒に perf top これにより、カーネル内のどの部分でCPUが時間を費やしているか、またどのシンボルを最初に調査すべきかをリアルタイムで把握できます。パーセンテージ値、繰り返し現れるパターン、そしてカーネル空間とユーザー空間の分離に基づいて、具体的な次のステップを導き出します。その後、`perf record/report` を使用して調査結果をまとめ、負荷下での変化を検証し、測定プロセスを文書化します。ホスティング環境では、カーネルパスが効率的に動作するようになると、多くのサービスやコンテナが相互に恩恵を受けるため、このアプローチは特に効果的です。このプロセスを体得すれば、診断にかかる日数を削減し、 遅延時間 これにより、実際の負荷下でも応答時間が著しく安定します。.