Python profiling.sampling 技術ガイド: Tachyon、GIL、フレームグラフ、本番プロファイル

Python 3.15 は、パフォーマンス エンジニアリングのための有意義な新しいサーフェスを追加します。profiling.sampling、Tachyon ベースの統計プロファイラーで、ライブ Python プロセスに接続し、さまざまなクロックでサンプリングし、対話型ビューと再生可能なビューの両方を公開できます。それは単なる「別のプロファイラー」ではありません。これにより、標準の Python ツールが運用環境のデバッグ、事後分析、共有パフォーマンス ワークフローに参加する方法が変わります。

この記事は、CPU プロファイリング、コール スタック、GIL、同時実行サービス、実稼働サービスに精通していることを前提としています。目的は、コマンドのヘルプを繰り返すことではありません。それは、「profiling.sampling」を技術マップ上に配置することです。つまり、使用するモデル、そのフラグが示す決定、トレースよりもそれを優先する時期、サンプリングに依然として存在するバイアス、すべてのパフォーマンス インシデントを再現不可能な 1 回限りのキャプチャにせずに統合する方法などです。

パッケージとしての「プロファイリング」からバックエンドとしての Tachyon まで

PEP 799 は、何年にもわたって構築されてきた移行を正式に決定しました。 Python は、歴史的な名前でプロファイリング ツールを散在させるのではなく、専用の profiling パッケージを導入し、従来の決定論的プロファイラーの最新の代替として profiling.tracing を追加し、低侵入の統計処理に profiling.sampling を使用します。 profile ドキュメントにはすでにその分割が反映されています。profile は 3.15 で非推奨となり、開発とテストには profiling.tracing が推奨され、運用デバッグには profiling.sampling が推奨されます。

サンプリング バックエンドは Tachyon です。文書化されたインターフェイスは、意図的に CLI 指向および成果物指向になっています (接続、観察、記録、再生)。これにより、予想されるユースケースについて何かがわかります。これはプロセス検査ツールであり、ベンチマーク ハーネスの関数呼び出しに関する単なるヘルパーではありません。

ドキュメントには、プロファイリングされたプロセスはインストルメンテーションを必要としないため「オーバーヘッドなしで」実行されるとも記載されています。正確な読み方はスローガンよりも狭いです。サンプラー自体は依然として外部プロセスとしてリソースを消費し、観測は物理的に無料になることはありません。なくなるのは、プロセス内のイベントフックのオーバーヘッドです。このコストこそが、測定対象を変更せずに実際の運用ワークロードに対して確定的トレーサーを使用することを困難にするコストです。

キャプチャ モデル: アタッチ、権限、操作境界

プロファイラは、PID によって既存のプロセスに接続します。正規の例は次のとおりです。

python -m profiling.sampling live <pid>

ユーザーには適切な権限が必要です。別のユーザーのプロセスにアタッチするには、管理者権限が必要な場合があります。これは制作上の脚注ではありません。成熟した使用法では、誰がどのホストに接続できるか、アーティファクトがどのように保持されるか、およびアクションがどのように監査されるかを定義する必要があります。スタック データを検査できるプロファイラーは運用上強力であるため、他の診断機能と同様に管理する必要があります。

コマンド ファミリは適切に選択されています。対話型の探索には「live」、ターミナルの概要には「top」、永続的なキャプチャには「record」、後で確認するために「replay」を使用します。実際の事件では、通常、「記録」と「再生」が最も防御可能なワークフローです。証拠を保存し、比較をサポートし、コラボレーションを可能にし、スパイクまたはワーカー プロセスがなくなった後も存続します。

クロック: cpu と wall は異なる質問に答えます

-- Clock オプションは、多くのユーザーが期待するよりも重要な意味を持ちます。 cpu は実際の CPU 実行をサンプリングします。 「wall」サンプルはリアルタイムで経過します。つまり、待機、ブロック、および CPU を使用していない時間が表示されたままになります。間違ったクロックを選択すると、誤った操作上の質問に対して技術的に正しい答えが得られる可能性があります。

圧縮によってコアが飽和するために API が遅い場合、CPU プロファイルにホットスポットが直接表示される可能性があります。スレッドがデータベース、キュー、ミューテックス、または外部依存関係で待機しているために速度が遅い場合、経過時間はユーザーが経験する遅延に近くなります。混合システムの場合、どちらが「本当のプロファイル」であるかを議論するよりも、両方をキャプチャする方が有益であることがよくあります。

「wall」について文書化されている「–subprocesses」オプションは、最新の Python デプロイメントにとって重要です。ワーカー、プール、ヘルパー バイナリ、ハイブリッド アーキテクチャは、多くの場合、作業を子プロセスにプッシュします。子を無視するプロファイルでは、リクエスト パスによって認識される合計コストではなく、コストの最も目に見える部分のみが記述される場合があります。

サンプリング周波数: 分解能、コスト、安定性

「profiling.sampling」は「–frequency」を公開します。文書化されたデフォルトは 100 Hz、許容範囲は 1 ～ 1000 Hz です。サンプルが増えれば自動的に分析が向上するわけではありません。

100 Hz では、30 秒のキャプチャで約 3000 件の観測が得られます。これは通常、永続的な動作を持つサービスの安定したホット パスを明らかにするのに十分です。周波数を上げると、イベントの短縮や時間分解能の向上に役立つ場合がありますが、データ量とシステムの混乱が増加します。大まかな分散のみが必要な長時間実行のワークロードの場合は、この値を下げるだけで十分な場合があります。正しい選択は、「高いほど安全であるに違いない」という反射ではなく、研究対象の現象の寿命に依存します。

サンプリングバイアスは依然として存在します。非常に短い作業、サンプリング期間に合わせたバースト、またはウィンドウ内のワークロードの変化は、見逃されたり過剰に表現されたりする可能性があります。美しいフレーム グラフがあっても、キャプチャが不十分な場合は役に立ちません。繰り返し、複数のウィンドウ、およびサービス メトリックとの相関関係は、依然として優れたエンジニアリング プラクティスの一部です。

ビュー: flamegraph、heatmap、gil、functions、stack をいつ使用するか

各ビューは、質問に一致する場合に役立ちます。

「フレームグラフ」

これは階層と集中にとって最も強力な最初のビューです。幅はサンプル周波数を表します。高さはスタックの深さを表します。これは、リクエストを支配する予期しない幅の広いパス、シリアル化レイヤー、パーサー、フレームワーク ラッパー、またはビジネス ループを検出するのに優れています。また、他のチームがシステムのどこに時間が入るのかを理解する必要がある場合にも、これは最も伝わりやすいビューです。

ヒートマップ

ヒートマップは、ウォームアップ、ガベージ コレクション、バッチ フェーズ、起動時の影響、定期的な劣化や負荷バーストなど、時間の経過とともに動作が変化する場合に最適です。集約はこれらの遷移を平坦化できます。ヒートマップはそれらを明らかにします。

「ギル」

GIL ビューは、キャプチャを有意義に共有するためにインタープリタ ロックを保持している関数を表面化するのに役立ちます。マルチスレッド コードでは、「スレッドがあること」と「有用な並列進行を取得すること」が区別されます。これはアーキテクチャ分析に代わるものではありませんが、インタプリタの競合が問題の一部である場合、検索を短縮します。

関数

フラット テーブルは、ユーザー、ライブラリ、システム機能などの優先順位を並べ替え、比較し、伝達するのに最適です。自己時間と合計貢献度。直接コストと呼び出し元主導のコスト。フレーム グラフよりも因果関係は少ないですが、高速で操作が便利です。

「スタック」

スタック ビューは、ライブ待機、ブロック検査、または迅速な操作読み取りなど、集計統計よりもスレッドごとの即時のスナップショットが重要な場合に適しています。

GIL: ツールが表示できるものと判断できないもの

このモジュールを使用すると、Python で繰り返される「GIL によって制限されているのですか?」という質問がより親しみやすくなります。 「gil」ビューは、プロファイルの高いシェアのロックを保持している関数を明らかにできます。これは、CPU に依存する作業がスレッド内で実行される場合、ネイティブ拡張機能がロックの解放に失敗する場合、またはコードの一部が予期せず進行状況をシリアル化する場合に役立ちます。

しかし、結論は自動的に得られるものではありません。 GIL シェアが高いというだけでは、システムがプロセス、非同期、またはネイティブ拡張機能に移行する必要があることを証明するものではありません。まず、スループット、レイテンシー、CPU 使用率、キューの深さ、および実際のサービス目標と相関させます。一部の I/O バウンドのワークロードでは、信号は重要ではない場合があります。他のケースでは、CPU 負荷の高い 1 つのホットスポットが、ほぼすべてのスケーリングの失敗の原因となります。

「profiling.sampling」は、メトリクスと組み合わせると最も強力になり、必要に応じて、sys.monitoring や制御されたトレースなどの対象を絞ったインストルメンテーションと組み合わせることができます。サンプリングにより、どこを見るべきかがわかります。有向計測は、より狭い仮説を証明するのに役立ちます。

profiling.tracing、timeit、および可観測性との比較

Python 3.15 では、ツールの分割がより明確になります。

• profiling.sampling: ライブプロセス検査、低侵入、生産適合性、時間分散、およびホット パス。
• profiling.tracing: 決定論的な呼び出しレベルの詳細。開発、テスト、および制御された分析に強力です。
• timeit: システム全体の診断ではなく、再現可能なミクロ比較。
• メトリクス、ログ、分散トレース: サービスの動作、コンポーネントの相関関係、リクエストレベルのコンテキスト。

典型的な間違いは、1 つのツールですべての質問に答えようとすることです。より良いワークフローはそれらを連鎖させます。遅延アラートはメトリクスにつながります。メトリクスは、1 つのワーカー プールでの CPU の上昇を示します。サンプリング プロファイルはホット パスを識別します。制御されたトレースまたは「timeit」実験により、リファクタリングが検証されます。その後、デプロイメントがメトリクスによって再度確認されます。

プロファイル ファイル、再現性、データ ガバナンス

record はバイナリ プロファイルを書き込み、replay は後でそれを開きます。それは便利のように聞こえますが、大規模な組織では分析の品質が変わります。記録されたプロファイルはチケットに添付し、リリース間で比較し、別のエンジニアによってレビューされ、回帰の証拠として保存されます。

プロファイルでは、モジュール名、パス、シンボル、関数構造、アーキテクチャ上の手がかりを公開することができます。これらを無害なログとして扱うべきではありません。元の環境の外に保存されている場合は、アクセス、分類、および保存ポリシーに属します。規制された環境では、アーティファクトに個人データが含まれていない場合でも、機密性の高い実装の詳細が明らかになることもあります。

賢明な生産統合

成熟した統合とは、サンプリングを常にオンにしておくという意味ではありません。これは、トリガーとプロシージャを定義することを意味します。

• 持続的な遅延インシデントまたは再現可能な回帰中にキャプチャします。
• 現象に適した頻度で、宣言された短いウィンドウを使用します。
• Python のバージョン、アプリケーションのリリース、ホスト、クロック、周波数、継続時間、およびおおよその負荷を記録します。
• ベースラインなしではプロファイルが解釈されないように、コンテキスト メトリックの横にプロファイルを保存します。
• 直観に頼るのではなく、修正後にキャプチャを繰り返して効果を実証します。

Kubernetes またはエフェメラル プラットフォームでは、チームはツールがどこに存在するか (ポリシーに応じて特権診断コンテナー、制御されたノード セッション、または一時的なサイドカー モデル) を決定する必要もあります。 Python ドキュメントでは、プロファイラーのセマンティクスが定義されています。運用アーキテクチャは依然としてチームの責任です。

解釈の罠

よくある 5 つの間違いが繰り返されます。

1. 幅を罪悪感と誤解する 幅の広い関数は、非効率的な作業ではなく、必要な作業を表す場合があります。
2. ワークロードの現実性を無視します。 非現実的なトラフィックの下で取得されたプロファイルは、別のシステムを表します。
3. 互換性のないキャプチャの比較。 クロック、周波数、またはウィンドウを変更して、何も変更がないかのようにパーセンテージを比較することは、脆弱な分析です。
4. 呼び出し元を考慮せずにセルフ時間を最適化する 場合によっては、関数がローカルでどのように実装されるかではなく、関数が呼び出される頻度が問題になることがあります。
5. 1 つのキャプチャを評決として扱う パフォーマンス作業では、繰り返しと文脈が 1 つの劇的なイメージよりも重要です。

事実、解釈、予測

確認された事実

• Python 3.15.0b1 ドキュメントでは、Tachyon ベースの統計プロファイラーとして profiling.sampling について説明しています。
• このツールは「ライブ」、「トップ」、「記録」、「再生」をサポートしています。 「CPU」と「壁」。そしてビュー flamegraph、heatmap、gil、functions、および stack。
• PEP 799 は profiling パッケージを作成し、その下に最新のプロファイラー スタックを再編成しました。
• profile は 3.15 で非推奨になり、cProfile は profiling.tracing の下位互換性のあるエイリアスとして残ります。

技術的な解釈

• 主な変化は、単にサンプラーの存在ではなく、外部ツールのみに依存せずに生産プロセスを検査するための正式に文書化されたパスです。
• 「記録」および「再生」ワークフローは、アドホックなパフォーマンス調査における 2 つの歴史的な弱点である再現性と共同レビューを促進します。

合理的な予測

• API と形式が 3.15 サイクル中に安定すると、内部ツール、SRE プレイブック、およびインシデント ドキュメントが再生可能なプロファイルを中心に標準化される可能性があります。
• 新しいパッケージは、Python 内でのベンチマーク、トレース、サンプリングを分離するための、より明確な教育的エントリ ポイントにもなる可能性があります。

結論

「profiling.sampling」は、高レベルの可観測性と詳細な追跡の間の実際のギャップを埋めます。パフォーマンス エンジニアリングの場合、その価値は摩擦の軽減にあります。つまり、同じ成果物を添付し、サンプリングし、永続化し、再生し、議論します。統計的なバイアスを取り除いたり、判断に取って代わるものではありませんが、直感、再現不可能なキャプチャ、異種ツールへの依存は軽減されます。

実際的な推奨事項は簡単です。ライブプロセス配布の質問やホットパスに使用します。制御された詳細については「profiling.tracing」を維持してください。細かい決定には「timeit」を使用します。そして、すべてのキャプチャに関する操作コンテキストを保持します。優れたプロファイラーは優れたメソッドに取って代わるものではありません。その方法がより効果的になります。

よくある質問

profiling.sampling は cProfile を置き換えますか?

完全にではありません。 cProfile は、profiling.tracing の下位互換性のあるエイリアスとして引き続き利用できます。サンプリングとトレースはさまざまな質問に答えます。

最初にどの時計を使用すればよいですか?

CPU の消費が疑われる場合は、「cpu」から始めます。ユーザーに見える遅延、待機またはブロックを調査する場合は、「壁」もキャプチャします。

常に 100 Hz で十分ですか?

常にそうとは限りませんが、これが賢明な出発点です。イベントの期間、許容可能なコスト、必要な解決策に基づいて調整します。

任意のプロセスにアタッチできますか?

オペレーティング システムがアクセスを許可している場合のみ。別のユーザーが所有するプロセスを検査するには管理者権限が必要になる可能性があることが Python ドキュメントで説明されています。

「gil」ビューは、スレッドを放棄すべきであることを証明していますか?

いいえ、GILの保有濃度を示します。アーキテクチャの決定には、依然としてスループット、レイテンシー、ワークロードの分析が必要です。

ソース

• Python 3.15: profiling.sampling。
• PEP 799: 専用プロファイリング パッケージ。
• Python 3.15: profile と profiling.tracing への移行。
• Python 3.15: sys.monitoring。
• Python 3.15: timeit。
• ブレンダン グレッグ: フレーム グラフ。