perfとフレームグラフで本番CPUホットスポットを診断｜低影響採取と解析・改善サイクル

なぜ本番環境でperfを使うのか

CPUが高騰しているサービスにおいて、「どの関数が時間を消費しているか」を特定せずに改善を試みるのは、暗闇の中で的を射るようなものです。スタックトレースを周期的にサンプリングして可視化するフレームグラフは、その問題を整理する最も実用的な手段の一つです。

Linuxカーネルに組み込まれたperfコマンドは、eBPFベースのツールが台頭した現在も、カーネルとユーザー空間を横断したプロファイリングにおいて安定した選択肢であり続けています。ドラマチックなアーキテクチャ変更なしに「今夜のリリースで間に合わせたい」というシーンで特に重宝されます。

ただし本番環境での採取はオーバーヘッドとの戦いです。サンプリング頻度・採取時間・対象プロセスの絞り込みを意識しないと、診断行為そのものが障害要因になりかねません。本記事では、影響を最小限に抑えながら有益なデータを得るための一連の手順を整理します。

採取前の準備：シンボル解決とカーネルパラメータ

フレームグラフの読み解きやすさは、シンボルが正しく解決されているかどうかに大きく依存します。採取結果が[unknown]だらけになると、改善の手がかりを得ることができません。

まず対象プロセスのデバッグシンボルを確認します。RPM系であればdebuginfo-install、Debian系であればapt install <パッケージ名>-dbgsymでインストールします。コンパイル済みバイナリの場合は、ビルド時に-fno-omit-frame-pointerを付与することが推奨されます。このオプションなしでもeBPFベースのプロファイラはスタックを辿れる場合がありますが、perfはフレームポインタに頼るため、省略すると不完全なスタックが記録されます。

次にカーネル側の設定を確認します。

# カーネルシンボルのアクセス権を確認
cat /proc/sys/kernel/perf_event_paranoid
# 推奨値：1（rootのみフルアクセス、一般ユーザーはユーザー空間のみ）

# カーネルスタックトレースを取得する場合
sudo sysctl -w kernel.perf_event_paranoid=1
sudo sysctl -w kernel.kptr_restrict=0

perf_event_paranoidを-1にすれば一般ユーザーでも広範なデータを取れますが、セキュリティ上のリスクが増します。本番環境ではrootもしくはsudo権限での採取にとどめ、作業後に値を戻すことを運用フローに組み込むのが現実的です。

低影響での採取：サンプリング頻度と対象絞り込み

本番採取で最も重要なのは「どれだけ短く・的確に採取するか」です。広く長く採取するほどデータは豊富になりますが、サービスへの影響も増大します。

基本的な採取コマンドは以下の通りです。

# 特定PIDを30秒間、99Hzでサンプリング（コール グラフをフレームポインタで取得）
sudo perf record -F 99 -p <PID> -g --call-graph fp -- sleep 30

# systemdサービス全体を対象にする場合（cgroup経由）
sudo perf record -F 99 --cgroup=<サービス名> -g --call-graph fp -- sleep 30

サンプリング周波数-F 99（99Hz）は一般的な本番向けの出発点です。1000Hz以上にするとCPU自体の負荷が顕著になるため、まずは99〜199Hzで試します。採取時間は30〜60秒が目安で、短すぎるとサンプル数が不十分になります。

採取完了後にデータを展開します。

sudo perf script > perf.out

このperf.outファイルが後段のフレームグラフ生成の入力になります。採取サーバーからローカルや分析用サーバーに転送して処理しても構いません。

フレームグラフの生成と読み方

フレームグラフの生成にはBrendan Greggが公開しているFlameGraph（GitHubで公開中のシェルスクリプト群）が事実上の標準です。

git clone https://github.com/brendangregg/FlameGraph
cd FlameGraph

# スタックの折り畳みと整形
./stackcollapse-perf.pl ../perf.out > perf.folded

# SVGの生成
./flamegraph.pl perf.folded > flame.svg

生成されたSVGをブラウザで開くと、インタラクティブなフレームグラフが表示されます。読み方の要点を整理すると次のようになります。

• 横軸はCPU時間の割合を示します（アルファベット順ではありません）
• 縦軸はコールスタックの深さで、上に行くほど呼び出し元に近づきます
• 幅の広いフレームが「多くのサンプルで観測された関数」、つまりホットスポットです
• 天井（スタックの最上部）が広い場合、その関数自体がCPUを消費しています
• 天井が狭いが台形になっている場合、子関数への呼び出しが問題の本体です

SVGはクリックでズームイン、Ctrl+Fで関数名検索が可能です。疑わしい関数に絞り込んでスタックを遡ることで、コード上のどのパスが問題を起こしているかを把握できます。

改善サイクル：仮説→修正→再採取での検証

フレームグラフはあくまでも仮説形成の道具です。「この関数が重い」という観察から、「なぜ重いのか」「修正の効果はあったか」を確かめるサイクルが重要です。

典型的なシナリオとして、Webサービスの応答レイテンシが急増したケースを考えます。フレームグラフでmallocやfree周辺のフレームが異常に広いと判明した場合、メモリアロケータの競合が疑われます。対策としてjemallocやtcmallocへの差し替えを試み、同条件・同時間で再採取します。修正前後のSVGを並べて比較することで、改善の定量的な根拠が得られます。

差分フレームグラフ（Differential Flame Graph）も有用です。

# 修正前後の差分グラフ生成
./difffolded.pl perf_before.folded perf_after.folded | ./flamegraph.pl > diff.svg

赤いフレームが増加した箇所、青いフレームが減少した箇所を示すため、修正の副作用として悪化したパスの発見にも役立ちます。改善の確認だけでなく、回帰の早期発見にも応用できます。

2026年現行環境での注意点と代替手段

2026年時点でのメジャーディストリビューションにおける状況を整理しておきます。

RHEL 9系およびAlmaLinux/RockyLinuxでは、デフォルトカーネルがCONFIG_FRAME_POINTERを無効化したビルドになっているケースがあります。この場合、--call-graph dwarfオプションを使うことでDWARFアンワインドが有効になりますが、サンプルあたりのメモリ使用量が増加し採取コストが上がります。本番採取では--call-graph lbr（Intel LBRが利用可能な場合）も検討に値します。

Ubuntu 22.04/24.04環境ではlinux-tools-$(uname -r)パッケージでperfが提供されます。カーネルバージョンに対応するパッケージが存在しない場合に採取が失敗するケースがあるため、まずuname -rとパッケージ名を照合する習慣をつけておくと無駄なトラブルを避けられます。

コンテナ環境ではホストカーネルに対してperfを実行する必要があります。Kubernetes上では特権コンテナやSYS_ADMINケーパビリティが必要なため、採取専用のデバッグPodを一時的に起動してノードのPIDネームスペースに入る構成が現場では多く採られています。

eBPFベースのプロファイラ（bpftraceやprofile.btスクリプト、あるいはContinuous Profilingソリューションとして知られるPyroscope・Grafana Pyroscope）は、フレームポインタなしでのスタック解決能力に優れており、長時間の継続採取にも向いています。一方で環境要件（カーネルバージョン・BTF対応など）が厳しいため、perfはその敷居の低さから引き続き有力な選択肢です。目的と環境に応じてツールを使い分けることが、現実的な運用判断といえます。

採取後は必ずカーネルパラメータを元に戻し、perf.dataファイルを安全に削除することも忘れずに。プロファイルデータにはメモリアドレスや関数名など、セキュリティ上の情報が含まれる点を意識した運用フローを整えておくことが重要です。