# 継続的プロファイリング ## 定義 本番システムで継続的にパフォーマンスデータを収集し、メトリクスやトレースが「何が起きているか」を示した後に「なぜそうなっているか」をコードレベルまで掘り下げるオブザーバビリティシグナルである。CPU・Heap・GPU・Mutex・IO・言語固有（Go pprof・JVM・Java pprof）など複数種類のプロファイラで構成される（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）。 ### プロファイラの種別 - **CPU プロファイラ**: 関数ごとの CPU 時間の割合を計測 - **Heap プロファイラ**: メモリ割り当てパターンと漏れを検知 - **GPU プロファイラ**: GPU カーネルの実行時間と占有率を計測 - **Mutex プロファイラ**: ロック競合とデッドロックを計測 - **IO プロファイラ**: ディスク・ネットワーク IO のボトルネックを計測 **サンプリングプロファイラ**: 従来のプロファイリングは計装オーバーヘッドが大きく本番投入が困難だった。統計的サンプリングにより「数%以内」のオーバーヘッドで本番計装が実用的になった（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]]）。 **アイシクルグラフ**: CPU 時間などのリソース配分を関数呼び出し階層で示す標準的な可視化形式。「炎のグラフ（Flame Graph）」の亜形。 ## 横断的知見 - **本番 CPU プロファイルが LLM コード最適化エージェントのベンチマーク基盤になる**: [[DODO]](Datadog Observability-Driven Optimizer)は Datadog Continuous Profiler の集約フレームグラフ(CPU 時間 1% 未満サブツリーを刈り込み)をグランドトゥルースとして Go マイクロベンチマークを生成し、プロファイル類似度 ≥98% を収束基準とする。これは「継続的プロファイリングのシグナルをリアルタイム障害診断」に使う従来の AIOps 用途から「コード最適化エージェントのベンチマーク生成基盤」への利用拡大を示す。DODO の適用で成熟した内部 Go サービスの CPU コストが 8% 以上削減された点は、継続的プロファイリングが観測だけでなく能動的改善ループの入力として機能することを実証した。(Source: [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]) - **async-profiler のフレームグラフがエージェント実装の非効率性を特定する**: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]] は async-profiler(safepoint バイアスを回避するサンプリングプロファイラ)を Java トレーシングエージェントの根本原因分析に使用し、OpenTelemetry の `CodeSpanNameExtractor`・`ArrayBasedContext` コピー・`AddThreadDetailsSpanProcessor` など具体的な高コストパスを特定した。プロファイリングの用途が「本番システムの実行時挙動把握」から「Java エージェント実装のボトルネック特定」まで広がることを示す。collapsed ファイルからの手動タグ付けで 5 タスク(MEMORY/TIME/CALL-TREE/METADATA/QUEUE)に分類する手法は、フレームグラフの機械的解析ではなくコード解析と組み合わせた半構造化アプローチ。(Source: [[@2026__ICPE__Benchmarking the Overhead of Distributed Tracing Agents]]) - **プロファイリングと LLM 推論最適化の接点**: GPU プロファイラは LLM 推論の[[カーネルフュージョン]]・[[コアレスドメモリアクセス]]・Attention 実装の最適化発見に使われる。[[eBPF]] ベースの非侵襲プロファイラ（[[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]）が LLM 推論演算子単位で侵襲なし計装を実現した。これは CNCF Whitepaper の「ギャップ 1: 自動/非侵襲計装」に対する部分的な回答と位置づけられる（Source: [[@2023__CNCF TAG Observability__Observability Whitepaper]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]]）。 ## 未解決の問い - プロファイルデータを LLM コード最適化エージェントのベンチマーク基盤として使う場合、プロファイル収集の時間軸(スナップショット vs 継続集計)と最適化対象関数の選択基準(CPU 占有率閾値、変更頻度)をどう設計すべきか。DODO は「1% 未満を刈り込む」シンプルなヒューリスティックだが、より体系的な基準は？ - 継続的プロファイリングのデータはどこに蓄積・検索されるべきか？ CNCF Whitepaper がログ/トレース/プロファイルの OSS DB 不足をギャップとして挙げているが、2025〜2026 年時点でのエコシステム成熟度は？ - GPU プロファイリングと CPU プロファイリングの統合ビューは標準化されつつあるか？ HPC・AI ワークロードでは GPU/CPU 境界のボトルネックが支配的であり、統合観測が重要になる。 ## 関連 - [[オブザーバビリティ]] — 5 シグナルのひとつ - [[テレメトリ]] — 収集・転送の基盤 - [[ハードウェアカウンタ]] — CPU/GPU の低レベル計測 - [[GPU観測性]] — GPU ワークロードのプロファイリング - [[eBPF]] — 非侵襲プロファイリングの実装基盤 - [[DODO]] — Datadog Continuous Profiler を LLM コード最適化のベンチマーク基盤として活用 - [[本番接地型ベンチマーク]] — CPU プロファイルをコード最適化評価に使う設計原則 ## 出典 - [[@2023__CNCF TAG Observability__Observability Whitepaper]] - [[@2026__Datadog__Production-Grounded Benchmarks for AI Code Optimization]]