管理

Linux Perf ツール – CPU のボトルネックを分析・解消する

Linuxの「perf」ツールを使えば、CPUのボトルネックを素早く特定し、明確に分類して、その解消に向けた具体的な対策を導き出すことができます。私は以下の測定データを活用しています カーネル– およびユーザー空間を活用し、ボトルネックを可視化し、コストを削減し、応答時間を大幅に短縮する。.

中心点

以下の核心的な主張が、私のアプローチの指針となり、実践的な取り組みの枠組みを構成しています。 パーフェクト:

統合型 重いエージェントを使わずに信頼性の高いCPUプロファイリングを行うためのカーネルツール
クリア コマンドの順序：list → stat → record → report → top
低いオーバーヘッドがあるため、本番システムでも安心して利用可能
測定可能な 効果：最適化、再測定、効果的な変更のみを採用
実践的 パターン：キャッシュミス、分岐ミス、ロック、システムコール

Linux perfとは何か――そしてなぜそれが重要なのか

をセットした。 パーフェクト Linuxカーネルに直接組み込まれており、ハードウェアカウンタ、ソフトウェアカウンタ、トレースポイントへの共通インターフェースを提供しているためです。この密接な連携により、 オーバーヘッド また、高負荷下でも信頼性の高いデータを提供します。このアーキテクチャでは、カーネルのデータ収集ロジックとユーザー向けツールが分離されているため、データを効率的に収集し、柔軟に分析することができます。これにより、実際のCPUカウンタにアクセスし、サイクル、命令、キャッシュヒットなどのイベントを監視できます。これにより、技術的な判断を「勘」ではなく、確かな測定値に基づいて下すことができます。.

CPUのボトルネックを早期に特定する

私は早期に対応します。なぜなら、応答の遅さ、高いレイテンシ、そして継続的なコア使用率は、明らかな警告サインとなるからです。そして、 スケーリング パフォーマンスを低下させる。データベースへのアクセスやジョブの実行に顕著な遅延が見られる場合、多くの場合、アルゴリズムの非効率性や不適切な並列化が原因である。また、レポートの実行時間が予定より長引く場合も、コストのかかるバッチ処理が行われていることを示しています。私は、安易に計算リソースを増強するのではなく、適切なCPUプロファイリングを行うことで、こうした原因を特定しています。これにより、リソース消費を削減し、システムの安定性を高めることができます。 パフォーマンス 持続可能だ。

perf を使ったワークフロー：概要からホットスポットまで

大まかな全体像から具体的なボトルネックにたどり着けるよう、決まった順序に従って進め、原因明確に区別します。まず主要指標を把握し、次にコールスタックを含むプロファイルを収集し、最後に的を絞った分析を行います。導入段階では概要測定が適しており、その後は負荷がかかった状態での代表的な記録を目指します。最後に、デプロイ中などにおける実稼働時の挙動を確認します。以下の表では、コマンド、目的、および呼び出し例を簡潔にまとめ、手順と 調査結果 明確なままにしておく。.

分隊	目的	例	典型的な知見
perf list	開催予定のイベントを表示する	`perf list`	この問題に関連する指標はどれか
パースタット	主要指標の概要	`perf stat -a sleep 10`	IPC、サイクル、キャッシュの挙動を一目で把握
パーレコード	プロファイリングデータの記録	`sudo perf record -g -F 99 ./myapp`	CPU時間が実際に浪費されている場所
perfレポート	記録されたデータを分析する	`perfレポート`	機能およびコールグラフ別のホットスポット
perf top	リアルタイムのホットスポットを監視する	`sudo perf top`	負荷がかかった状態での変化を即座に確認

イベントを絞り込んで選ぶ：perf list

私は次のように始める。 perf list, CPUに関連するイベントの選択を確認し、計測対象を絞り込むためです。計算負荷の高い問題ではサイクルや命令を観察し、メモリ関連の問題ではキャッシュ参照やキャッシュミスを確認します。分岐に関しては、ブランチミスを確認することで、予測の誤りを可視化できます。このコマンド perf list CPUやカーネルに応じて利用可能なカウンタを表示してくれるので、目的を絞って選択することができます。そのため、すべてを計測するのではなく、私の質問回答しました。.

ステータスのクイック確認：perf statの正しい読み方

と一緒に パースタット 詳しく掘り下げる前に、概要をざっと把握しておきます。次のような呼び出しで perf stat サイクル数、命令数、キャッシュ参照数、キャッシュミス数、およびIPC値を返します。IPC値が非常に低い場合は、メモリアクセスによる待機時間が原因である可能性があり、一方、IPC値が高い場合は、演算中心の実行を示している傾向があります。このオプションは -a トラフィックのピーク時など、システム全体で測定したい場合には、これを考慮に入れます。そうすることで、あるプログラムがCPUに依存しているかどうか、あるいは メモリ 限定。.

詳細なプロファイリング：推測に頼らない「perf record」

詳細な分析を行う際には、私は パーレコード そして、以下のようにコールスタックを取得します。 -g, 、呼び出しパスをすべて確認できるようにするためです。サンプリング周波数は -F, 、短くも意味のある時間枠については、1秒あたり約99サンプル。負荷が多くのプロセスに分散している場合は「システム全体のプロファイリング」を選択し、その後、個々のサービスに絞り込みます。例： sudo perf record -F 99 -a -g -- sleep 30 典型的なピークの代表的なプロファイルを作成します。このデータにより、目に見えないホットスポットを可視化し、 クラリティ 今後の手順について。.

ホットスポットを可視化する：perf report と perf top

と一緒に perfレポート そのファイルを評価する perf.data を表示し、関数ごとのCPU時間における割合を確認します。コールグラフビューでは、どの呼び出しチェーンが負荷の原因となっているかが明らかになります。割合が高い箇所をホットスポットとしてマークし、自作のコード、ライブラリ、カーネルの各部分を慎重に区別します。ライブビューには perf top, 、デプロイメントの変更や設定の変更を即座に把握するためです。これにより、データに基づいて意思決定を行い、 リスク 誤った最適化によるもの。.

実際のボトルネックのパターンを読み取る

実務の現場では、繰り返し見られるパターンがあり、私はそれを パーフェクト 速やかに確認し、対処します。計算負荷の高いホットスポットについては、アルゴリズムの変更、キャッシュの活用、あるいはより効率的なライブラリの導入を検討すべき箇所だと判断しています。頻繁なキャッシュミスは、データアクセスが最適化されていないことを示唆しています。これについては、私の記事「キャッシュミスについて理解する. ブランチミスが多数見られる場合は、ロジックが複雑に枝分かれしすぎていることを示しており、ロック関数での処理時間が過度に長い場合は、並列化における競合が疑われる。システムコールやカーネル関数が多く見られる場合は、呼び出し頻度を減らし、I/Oを束ね、強化する キャッシング.

チューニング対策に関するプロファイルから

単にコア数を増やすのではなく、具体的な最適化策を導き出し、変更のたびに指標。最初のプロファイリングを行った後、コードやデータ構造、設定を調整し、すぐに再測定を行います。効果が得られない場合は、そのアプローチを破棄し、次の仮説を検証します。実行時間やガベージコレクションについてより深い洞察が必要な場合は、言語固有のプロファイラを補完的に使用します。測定、介入、検証というこの閉じたサイクルは、時間を節約し、コストを削減し、 安定性.

実稼働環境におけるPerf：サンプリング、セキュリティ、コンテナ

連続運転時には、次のような理由からサンプリングレートを適度に設定しています。 追加負荷 負荷を最小限に抑えつつ、有意義なプロファイルを取得できるようにしています。システム全体の分析については、システムに不必要な負荷をかけないよう、ピーク時など関連性の高い時間枠に限定しています。パフォーマンスデータからは内部の業務プロセスが把握できるため、アクセス権限は明確に定義しています。コンテナやKVMが導入されている環境では、ホストとゲストの視点を分離し、双方の観点から評価を行います。スケジューリングに関する質問については、以下を参照してください。 CFSの代替療法, 、標準的な計画が負荷に合わない場合や、 コード 介入する。.

スケジューラ、コンテキスト切り替え、およびレイテンシ

ホットスポットに加え、コンテキストの切り替えにも注意を払っています。頻繁な切り替えはスレッドの処理を遅くし、 レイテンシー を向上させる。CPUアフィニティを監視し、必要に応じてプロセスをピン留めし、不要なスレッドの生成を削減している。バッチジョブについては、負荷のピークを悪化させないようスケジュールを組んでいる。切り替えコストを的確に評価するために、この概要が参考になっている。文脈の変化を評価する. このようにして、変更の回数を適正な範囲に抑え、均一性を確保しています。利用.

インフラとホスティング環境を賢く選ぶ

たとえクリーンなコードであっても、もし ハードウェア リソースが不足している場合や、セットアップが負荷に見合っていない場合です。スケーリングを行う前に、CPUの世代、クロック周波数、キャッシュ、NUMAトポロジーを確認します。ホスト側に余裕を持たせることで、ピーク時の負荷に対応できる余地が生まれ、クリティカルパスでの待ち時間を短縮できます。マシンクラスを統一することで、測定結果の比較が容易になり、誤った解釈を防ぐことができます。このようにして、アクティブなプロファイリングを適切な環境と組み合わせることで、無計画に容量を増やすのではなく、毎月目に見えるほどのユーロ単位のコスト削減を実現しています。購入.

シンボルの解決とコールスタックを確実に処理する

詳細な コールスタック これらは、適切な意思決定の基盤となります。私は、バイナリやライブラリにデバッグ情報が含まれていることを確認します（-g) で構築されており、妥当な場合にはフレームポインタが削除されない（-fno-omit-frame-pointer). 安定したスタックには、私は --call-graph fp, 、フレームポインタが存在する場合は、または --call-graph dwarf, 、DWARFアンワインディングを優先する場合： perf record -g --call-graph fp -F 99 -- ./myapp. ディストリビューションでは、適切なものをインストールします デバッグ情報-パッケージ、これにより perfレポート シンボルを正しくマッピングします。コンテナ環境では、デバッグシンボルにアクセスできるようにしています（例：ボリューム経由）。そうしないと、レポートにはアドレスのみが表示されてしまいます。ライブラリが stripped の場合、デバッグ情報を別々に保存しつつも利用できるようにするビルドプロセスを採用しています。そうすることで、関数名やソースコードの行番号が確認できるため、当て推量を避けることができます。.

測定設計と再現性

信頼性の高い測定には、清浄な 実験計画. 私は繰り返し実行します perf stat -r 5 -e cycles,instructions,cache-misses --, 、変動を確認するため、テスト環境を一定に保つ（データ量や負荷プロファイルを同一にする）。CPUの周波数スケーリングは指標に影響を与えるため、ガバナー／ターボの状態を記録し、負荷を taskset -c 固定コアについて。絶縁された比較を行うには、干渉負荷のない専用コア（例：絶縁されたCPU）が役立ちます。ウォームアップ段階は測定期間から明確に分離し、 キャッシュ そしてJITが安定している。システム全体の測定を行う際は、私は -a そして、期間を次のように設定します。 --timeout あるいは、それを囲む sleep. 本番環境では、破壊的な操作（キャッシュの強制的なクリアなど）は避け、結果が再現可能となるよう、テストの各手順を記録しています。.

メモリおよびNUMAの分析をさらに深く理解する

表示 国際刑事裁判所 下へ、そして キャッシュミス 上の方では、メモリの挙動を具体的に調査しています。 パフォーマンス・メモリ・レコード そして perf mem report メモリアクセスを追跡し、コストのかかるパス（例：LLCミス）を関数に紐付けることができます。NUMAトポロジーについては、リモートアクセスを削減すること（例：スレッドピンニングやローカル割り当て）によって対応しています。関連するイベントには、以下などが含まれます。. LLCロードミス, dTLBのロードミス, ページフォールト (短音階／長音階) および mem-loads、mem-stores CPUによって異なります。データ構造が順次アクセスを容易にするかどうか、また キャッシュライン 不必要に無効化されてしまう。過度に大きく、ランダムなワーキングセットは、好ましくない状況を データレイアウト; ここでは、構造化パッキング、ホット／コールド・スプリッティング、あるいはストリーミングアルゴリズムが役立ちます。データベースに関しては、バッファサイズに注意を払い、, THP-ミスのコストを低減するための動作とプリフェッチ効果。.

ロック、スケジューラ、および待機時間を詳細に分析する

もしホットスポットが pthread_mutex_lock, futex あるいはスピンロックにつながる場合、私は計算時間を 待ち時間.と一緒に perf lock record そして perf lock レポート 争奪戦となっているロックとその保持時間を特定します。. perf sched timehist Runqueueの遅延に関する洞察を提供し、, 先取権 およびスリープ／ウェイクアップのチェーン。これにより、スレッドが計算を行う代わりにCPUの割り当てを待機しているかどうかを判別します。スライスごとの実行時間が短いにもかかわらずコンテキストスイッチが頻繁に発生する場合は、並列化が細かすぎることを示唆しています。その場合は、ワークチャンクのサイズを拡大し、同期の頻度を下げます。 I/O負荷の高いワークロードでは、ブロック時間を調整し（例：非同期I/O、バッチ処理）、読み取り／書き込みパスを個別のスレッドに分離することで、 CPUコア 動作の遅い端末を待たない。.

システムコールとI/Oオーバーヘッドを可視化する

支配する システムコール またはカーネルパスは perfレポート, 、アクセス頻度とレイテンシを分析します。 perf trace システム呼び出しを監視していると、チャッティなパターン（例えば、読み取り／書き込みサイズが小さすぎる、頻繁な stat-閲覧数、多数 epoll_wait-切り替え）。対策としては、バッチ処理、ゼロコピー戦略、バッファの調整などが挙げられる。よくある clock_gettime-閲覧数、または gettimeofday Hotloopsでは、サンプリング頻度を下げて置き換えています。ネットワークパスについては、コピーコストとチェックサムコストのどちらが支配的かを確認し、Hotpathsの負荷を軽減するために キャッシング 接続パラメータの調整や、小さなパケットの結合など。その目的は、コストのかかるユーザー／カーネル間の切り替えを削減し、システムコール1回あたりの有効処理量を増加させることにある。.

コンテナ、権限、セキュリティの詳細

共有ホスト上では、 権利関係 そして、可視性が極めて重要です。私は以下を通じて kernel.perf_event_paranoid そして kernel.kptr_restrict 明確な境界を設定し、最新のカーネルでは優先的に使用している CAP_PERFMON 完全アクセス権の代わりに。コンテナでは、以下が必要となります パーフェクト ホストの設定（例：perf_event デバイスや必要な機能の引き渡しなど）。これを行わない場合、利用可能なイベントは限定されます。コンテナに焦点を当てた計測を行う際は、cgroup フィルターを用いて絞り込みを行い、関連するプロセスのみをプロファイリングし、 オーバーヘッド 低下させる。機密性の高い環境では、パフォーマンスデータによって社内の業務プロセスが露見する可能性があるため、監査ログや厳格なアクセス権限の設定が有効である。.

JITコードとインタプリタコード：信頼性の高いスタック

時点では ジャストインタイム-言語（JVM、.NET、JavaScriptなど）やインタプリタについては、シンボルの解決が適切に行われるよう注意を払っています。Javaについては、ホットスポット内のフレームポインタを確保し、JIT情報を有効にし、JITマップを活用することで、 パーフェクト メソッドを正しく命名する。いくつかの実行時間を生成する perf-PID.map-ファイル、または jitdump-アーティファクト；測定中はこれらを保存しておき、 perfレポート それぞれ perf スクリプト 。PythonやRubyの場合、最適化されたC拡張モジュールは頻繁にホットスポットとなります。こうした場面では、ネイティブモジュールのデバッグシンボルが重要な洞察をもたらします。信頼性の高いスタック情報がなければ、 見せかけのホットスポット （例：Trampolinenなど）が最適化を誤った方向へ導いてしまう。そのため、私はキャンペーンを開始する前に、対象言語向けのスタックが完全かつ安定しているかどうかを毎回確認している。.

ロングラン、マルチプレクシング、およびバッファの制御

記録期間が長い場合、適切なサイズに調整することでデータ損失を防いでいます。 リングバッファ (-m）および正確なサンプリングレート。高周波測定では、イベントを 多重化, 、そのため比較が難しくなります。重要な指標については、確固たる結論を導き出すために、グループごとに、あるいは個別に測定しています。時間的な傾向については、 perf stat -I 1000 -a 一目で1秒ごとの主要指標を確認でき、これにより負荷のピークを把握したり、回帰デプロイメントごとに。比較可能な数値については、調整を行っています。 -F/サンプリング期間を確認し、PMUが選択したイベントを同時にサポートできるかどうかを確認する。実行ごとにカウンターのセットを絞り込むことで、より堅牢な トレンドに関する見解 満杯の計量かごよりも。.

可視化とコラボレーション

チームがすぐに取り組み始められるよう、結果を整理しています。. perf report --stdio チケット内のテキストスナップショットにはこれを使用し、インタラクティブなビューではホットパスを可視化しています。 perf annotate 不審な関数を開き、どのソースコード行がループを生成しているかを確認します。要約表示を行うために、次からスタック可視化を生成します。 perf スクリプト-各呼び出しチェーンごとの時間配分を示し、代替案を比較できるようにするデータ。. perf diff 「ビフォー・アフター」のプロフィールを客観的に比較するのに役立ち、それによって私は効果事実上の根拠です。私は、各サービスクラスごとにベースラインプロファイルを用意し、パフォーマンスの低下を早期に検知し、確かな数値に基づいて議論を行うようにしています。.

簡単にまとめると

と一緒に リナックス perf を使って、目標を明確に定めて作業を進めます。イベントの選択、指標の確認、プロファイルの収集、ホットスポットの評価、効果の測定を行います。キャッシュの挙動、分岐、ロック、システムコールを明確に整理することで、原因と症状を区別します。ライブビューを活用して分析を補完することで、変更を即座に把握し、誤った方向への進みを回避します。プロファイリングデータの信頼性を維持するため、ハードウェアとスケジューリングにも常に注意を払っています。このようにして、CPUのボトルネックを段階的に解消し、コストを削減し、一貫性のある 応答時間.