技術情報

bcc toolsの実践：eBPFを用いたLinuxパフォーマンスエンジニアリングの実践ガイド

私がどのようにしているかを、順を追って説明します。 bcc ツール eBPFを活用して、Linuxサーバー上のボトルネックを迅速に特定・解消しています。その際、実用的なワークフローを採用し、カーネル内の実際のレイテンシを測定するとともに、CPU、I/O、ネットワークからのイベントを統合して、 クリア 原因分析。.

中心点

イービーピーエフ オーバーヘッドを抑えつつ、詳細なトレースを実現します。.
bcc ツール CPU、I/O、ネットワーク、およびプロセスを網羅しています。.
生産現場に近い アプリを変更することなく利用可能です。.
チェックリスト スタート用に10種類のツールが付属しています。.
セキュリティ Verifierと明確なポリシーを通じて。.

LinuxのパフォーマンスエンジニアリングにおいてeBPFが選ばれる理由

に手を伸ばす。 イービーピーエフ, 、カーネルイベントを確実かつ選択的に、しかもオーバーヘッドを最小限に抑えて計測したいからです。従来のツールは合計値を表示するものの、スレッドが待機している理由や、パケットが再送信される理由、あるいはI/Oがハングアップする理由などを説明することはめったにありません。eBPFはこのギャップを埋めてくれます。 具体的な イベント。プログラムはカーネル上で実行され、Verifierが事前に検証を行うため、再起動せずに起動できます。これにより、ユーザーランドからの呼び出しとカーネルパスを関連付け、即座に最適化を行える全体像を把握できます。この仕組みについてさらに詳しく知りたい方は、私の短い入門記事に概要がまとめられています。 eBPFのパフォーマンス分析, 、トレースとオブザーバビリティの連携について概説したものです。.

bccツールとは何ですか？また、どこで見つけることができますか？

仝 bcc tools は eBPF を基盤とした既製の診断プログラムであり、通常は /usr/share/bcc/tools ディレクトリに配置されています。私はこれらをシェルから直接実行し、明確な標準出力を得ることができ、アプリケーションを改造する必要もありません。このツールセットは、プロセス、システムコール、ファイルシステム、ブロックI/O、ネットワーク、スケジューラ、プロファイリングを網羅しており、以下の用途に適しています。 生産的な 分析。意図的にトレーシングを有効にしているため、その影響は小さく、監視による測定誤差も最小限に抑えられます。より詳細な分析が必要な場合は、独自のeBPFをツールに追加したり、サンプリングプロファイルを併用したりしています。.

インストールと要件

私は bcc 一般的なディストリビューションでは、パッケージ管理システム（bcc-tools または bpfcc-tools）を介してツールをインストールできます。必要なのは、eBPF をサポートするカーネル（4.x 以降、できれば 4.9 以上）、有効化された BPF 機能、およびプログラムを読み込むための十分な権限です。本番サーバーでは、後の測定結果に支障が出ないよう、事前にテスト環境でカーネルおよびディストリビューションのeBPF対応状況を検証しています。 信頼できる 実行されます。eBPFを完全に無効化するセキュリティプロファイルについては、適切なポリシーを設定することで防止しています。セットアップと操作に関する実用的な概要については、以下の簡潔な説明を参照してください。 eBPF解析ツール.

開始前：システムおよびセキュリティの確認

本番環境で測定を行う前に、ホストの基本機能を検証します。これにより、誤った開始を回避し、再現性のある結果を得ることができます。.

カーネルの機能をチェックする： uname -r および利用可能なBPF関数（例：フィーチャーチェックなど）。重要なものとしては、kprobes/tracepoints、BTF（安定した型情報の取得用）、およびperfイベントが挙げられる。.
権限とポリシー：eBPFの読み込みを許可されるのは権限を持つユーザーのみ（CAP_BPF/CAP_SYS_ADMIN または同等のポリシー）であることを確認し、LSMプロファイルによって読み込みがブロックされないようにします。.
システムパラメータ： kernel.unprivileged_bpf_disabled 通常、本番環境ではアクティブになっています。そのため、私は意図的に、セキュリティ対策が施されたセッションから作業を行い、明確な監査記録を残すようにしています。.
透過的なパス：私は次のようなディレクトリを /sys/kernel/debug/tracing そして /sys/fs/bpf 測定後にアーティファクトを整理することを念頭に置いている。.

こうした衛生管理により、副作用を招くことなく、的を絞った再現性のある測定を行うことができます。.

実践ガイド：最初の10のツール

パフォーマンスを素早く確認するために、私は決まった手順を踏んでいます。これにより、CPU、I/O、ネットワークのいずれが原因かを明確に絞り込み、スタックやタイミングをさらに深く調べるべきかどうかを判断します。以下の表には、各ツールの主な機能と、それを使って明らかにしたい点が示されています。まずは実行時間を短く抑え、疑わしい点が見つかり次第、測定を繰り返します。 確認する そうしたい。そうすることで、見落としを防ぎ、緊急事態の際に時間を無駄にすることもない。事件.

工具	観察された	典型的な質問
execsnoop	新しいプロセス	負担を生み出すような、短期間の仕事は誰が始めたりするのでしょうか？
opensnoop	ファイルの開く操作	どのパスが常に開かれたり、ログに記録されたりしていますか？
ext4は遅い（xfs、btrfs、zfs*）	低速なFS操作	どのリクエストが、ボリュームごとに高いレイテンシを示していますか？
バイオレイテンシー	ブロックI/Oの分散	散発的な、あるいは持続的なレイテンシーのピークはありますか？
biosnoop	個別のI/Oリクエスト	どのようなプロセスが特定の機器を機能不全に陥らせるのでしょうか？
cachestat	ページキャッシュの動作	RAMを増やした方が良いのか、それともアプリに不具合が生じるのか？
tcpconnect	新しいTCP接続	誰が、どのサービスを、どのくらいの頻度で利用しているのか？
tcpaccept	承認された接続	どのサーバーソケットに高い負荷がかかっているか？
tcpretrans	再送信	パケット損失は、経路の不安定さを示唆しているのでしょうか？
runqlat	スケジューラの遅延	スレッドはCPU時間を待ちすぎているのか？

も使っている。 プロフィール これを使って、ユーザースペースやカーネルスペースのホットスポットを特定し、コールスタックを集約します。これにより、コストのかかる正規表現や非効率なドライバ、スピンロックなどを発見し、コードや設定でそれらを解消しています。サンプリング間隔を短く設定し、複数の実行結果を比較することで、外れ値を 目に見える 。全体像と詳細を兼ね備えたこのアプローチのおかげで、分析にかかる時間を大幅に節約できます。その後、同じ負荷条件下で最適化の結果を再度テストします。.

拡張機能：オフCPU、ロック、および待機時間を可視化する

すべての高いレイテンシがCPUに起因するわけではありません。多くの場合、スレッドは「オフCPU」状態でI/O、ロック、またはウェイクアップを待機しています。このような場合、bccの追加ツールやプロファイルが役立ちます：

オフCPU分析：スレッドがCPU上で実行されていない時間を計測し、そこに至るスタックを特定します。これにより、計算時間と待機時間を区別し、ブロック要因を明らかにします。.
ロックの競合：特に重要なカーネルおよびユーザースペースのロックに注目しています。保持時間が長い場合や競合率が高い場合は、シリアライゼーションポイントが存在することを示唆しているため、それらを解消します（例：シャーディング、粒度の微調整、データ構造の変更など）。.
ウェイクアップパス：「ウェイクアップされた」時点から「再び実行中」になるまでのレイテンシは、スケジューリングや優先順位の問題、あるいはワーカープールが大きすぎることを明らかにする。.

私はこれらのシグナルを以下と相関分析しています runqlat そして バイオレイテンシー, 、メモリ、I/O、スケジューラに起因する原因を区別するため。.

測定の衛生管理：フィルター、測定時間、閾値

eBPFの測定結果を再現性のあるものにするため、私は次の3つの基本ルールに従って作業しています：

簡潔かつ的確に：ツールは最初は短時間（例えば10～30秒）だけ実行し、不審なPID、コンテナ、またはソケットに焦点を当てます。.
閾値の設定：「*slower」ツールを使用する際は、ノイズを減らし、問題のある呼び出しのみを確認できるよう、わずかなレイテンシを除外するようにしています。.
レート制限：イベントレートを低く抑えるために、選択的なフィルタ（プロセス名、TID、ポートなど）を使用しています。これにより、オーバーヘッドを最小限に抑え、イベントのドロップを防ぐことができます。.

あるパターンが見えてきて初めて、実行期間を延長したり、範囲を拡大したりします。そうすることで、私は クリーン そして、信頼性の高いサンプリング。.

実務シナリオ 1：原因不明のCPU負荷の高まり

CPUの表示値が常に高い値を示している場合は、次のように実行します。 execsnoop, 、短命なプロセスを特定するためです。その後、runqlat を使用して、スレッドが CPU 時間を待機している時間を測定し、ランキューが溢れていないか、あるいは優先順位が適切でないかを確認します。待機時間が顕著になった場合は、スレッドプールを変更したり、cron ジョブのタイミングを調整したりして、スケジューラが グラブ ことができます。profile を使ってスタックを収集し、ライブラリや自身のコード内の真のホットスポットを特定します。これらの情報を統合して初めて、制限、ガベージコレクション、アフィニティ、あるいはコンパイラフラグに関する判断を下すことができます。.

実運用シナリオ 2：I/O レイテンシと動作の重いアプリケーション

ユーザーからCPU使用率が低いのに動作が重くなるという苦情があった場合、私は以下で確認します。 ext4は遅い プロセスごとの低速なファイルシステム呼び出し。次に、biolatency を使用してデバイスごとのブロック I/O 時間の分布を確認し、散発的なピークや持続的なボトルネックを特定します。 biosnoop を使用すると、個々のサービスが不健全なほど多くの小さな書き込みを発生させ、それによってキューイングを引き起こし、他のプロセスの動作を遅らせているかどうかを確認できます。cachestat を使用すると、ページキャッシュがヒットしているか、あるいはミスが発生しているかを確認できます。 支配する そして、RAMを増やせば改善されるだろう。最終的には、バッチ書き込み、バッファの拡大、あるいはより高速なストレージへの移行のどれが効果的かを判断することになる。.

実践シナリオ 3：ネットワークパスとマイクロサービス

分散環境では、まず以下から始めます。 tcpconnect, 、サービス間の接続確立状況を測定します。その後、tcpaccept を使用して、どのサーバーソケットに特に多くの着信があるか、またリスナー側の制限が機能しているかを確認します。さらに、`tcpretrans` を使用して再送信を検出し、タイムアウトやリトライの設定を調整する前に、トランスポートの問題とアプリケーションのエラーを区別します。これら3つの指標により、ネットワーク、アプリケーション、あるいはアップストリームサービスのいずれが レイテンシー を実行します。その後、バックオフ戦略、キープアライブ値、ロードバランサーの設定、およびバッファサイズを調整します。.

eBPFの運用上の安全性と信頼性

私はただ 信頼できる ツールを使用し、独自のeBPFプログラムはまずステージング環境でテストします。カーネル・ベリファイアは不具合のあるプログラムをブロックしますが、メモリ使用量が適切に制限されるよう、マップとバッファに対して追加の制限を設けています。挙動や副作用を把握し、必要に応じて迅速に対応できるよう、ロギングは保存しています。ポリシーにより、eBPFをロードできるユーザーを定義することで、プラットフォームチームが管理権限を保持し、セキュリティ要件が遵守されるようにしています。これらのルールにより、本番環境でのトレースが 信頼できる そのまま残り、予期せぬ事態を引き起こさない。.

コンテナおよびKubernetes環境

コンテナ環境では、体系的な問題とポッド固有の影響を区別しています。そのため、cgroup、ネームスペース、またはPID範囲に基づいて測定値をフィルタリングしています。多くのbccツールでは、プロセス名やIDによるフィルタリングが可能です。あるいは、ホスト上で計測を行い、cgroupに基づいてイベントをワークロードに割り当てることもあります。重要：

PID ネームスペース：ホストとコンテナでは PID が異なります。私は ID をマッピングするか、プロセス名やポートに基づいてフィルタリングしています。.
リソースクォータ：CFSクォータによるCPUスロットリングは、システム負荷が最大に達していないにもかかわらず、待ち時間が長くなるという現象として現れます。私はこれを以下の方法で確認しています。 runqlat 比率に関する指標と組み合わせて。.
ネットワークネームスペース：ソケット分析を行う際は、正しいネームスペースに注意を払っています。ホストインターフェースで測定を行い、PodのIPアドレスやポートと照合しています。.

これにより、多数のワークロードが密接に並行して実行されている場合でも、測定結果の信頼性が保たれます。.

オブザーバビリティ・スタックへの統合

モニタリングを置き換えるのではなく、次のようなもので補完しています イービーピーエフ. bccツールは深さを提供してくれる一方で、メトリクスシステム、ログ、APMは広さを示してくれます。これらを組み合わせることで、一貫性のある全体像が浮かび上がります。必要に応じてbccからのトレースをログパイプラインに転送し、インシデント発生時にはスナップショットをトリガーし、調査結果をチーム内で共有しています。特定のプロファイルを分析する際は、メトリクスからのタイムラインに加え、サンプリングも活用して、異常を有形になります。さらにスクリプトを好む方は、ホスティングにおけるbpftrace ミニスクリプトを使って、その場での質問に手っ取り早く答える方法。.

よくある落とし穴――そして私がそれをどう乗り越えているか

Noisy Neighbor：個々のジョブが、短時間ではあるものの集中的な負荷を発生させる。. execsnoop プラス プロフィール これらのパターンを確実に特定します。私はそれらにタイムボックスを設定するか、クォータを用いて切り分けます。.
NUMAとアフィニティ：空きコアがあるにもかかわらずレイテンシが高い場合は、クロスNUMAアクセスが疑われる。CPUアフィニティ、メモリバインディング、IRQの割り当てを確認する。.
IRQ/SoftIRQのボトルネック：ネットワーク負荷によりksoftirqdカーネルが飽和する可能性がある。再送信を監視し、RSS/キューを介してIRQを分散させ、RPS/XPSを調整している。.
ページキャッシュの影響：コールドスタートの処理速度が低下する。ウォームアップ期間を考慮に入れて比較する cachestat-負荷前後の値。.
カーネルのアップデート：バージョンが大幅に変更されると、Kprobesも変更される可能性があります。私は安定したトレースポイントを優先し、事前にテストを行い、最小限のセットを用意しておくようにしています。.

実績のある業務プロセス

インシデント・スナップショット：60～120秒間の複合実行（execsnoop、runqlat、biolatency、tcpretrans、profile）。その後、目立つサブシステムに焦点を当てます。.
ベースラインのルーチン：主要経路（例：ストレージおよびネットワークのプロファイル）について、毎週簡単な測定を行う。これにより、異常を早期に検知できる。.
変更の検証：設定変更の前後で同じ測定ポイントを比較し、その影響を定量的に把握します。.

継続的なLinuxパフォーマンスエンジニアリング

私はパフォーマンスを、単なるものではなく、継続的なプロセスとして捉えています。 単発アクション. CI/CDでは、eBPFベースの簡易チェックを組み込み、回帰を早期に検知して、ロールアウト前に阻止しています。メンテナンスウィンドウでは、負荷がかかった状態での典型的な処理パスを測定し、ベースラインを構築して、許容可能なレイテンシの範囲を文書化しています。これにより、逸脱を迅速に検知でき、インシデント発生時の当て推量を減らすことができます。比較データがあるためです。 利用可能. このルーチンにより、利用可能性、コスト管理、ユーザー体験が直接向上します。.

ミニケーススタディ：12分で症状から原因を突き止める

あるAPIクラスターで、RPSに変化がないにもかかわらず、99パーセンタイルのレイテンシが上昇していることが報告されました。そこで、インシデントのスナップショットを取得します： tcpconnect 接続の確立に異常は見られず、, tcpretrans 低いまま――ネットワークはそうではないようだ。. runqlat 待ち時間は短いものの、頻繁に発生すると報告されています；; プロフィール JSONシリアライズ形式でホットスポットを表示します。並行して、 cachestat ピーク時にキャッシュヒット率が低下する。この相関関係から、多数の小さなペイロードが同期してシリアル化され、即座に書き込まれていることが示唆される。.

以下の方法で検証します ext4は遅い, これは、APIプロセスにおいて同じボリューム上で数ミリ秒にわたるfsyncが発生していることを示している；; バイオレイテンシー 影響を受けたデバイスにおいて、散発的なキューのピークが発生していることが確認された。対策：書き込みのバッチ処理、バッファの拡大、および影響の少ないポイントでの非同期フラッシュ。ロールアウト後、99パーセンタイルのレイテンシは35 %低下し、キャッシュヒット率は回復し、 runqlat 再び狭い分布を示している。.

実践のためのまとめ

と一緒に bcc tools や eBPF を使えば、アプリケーションを変更することなく、短時間で CPU、I/O、ネットワークの状況を確認できます。 execsnoop、opensnoop、ext4slower、biolatency、biosnoop、cachestat、tcpconnect、tcpaccept、tcpretrans、runqlatからなるチェックリストは、理にかなった出発点となります。さらに、profile を使用してホットスポットを可視化し、コードパスの負荷を軽減します。適切なポリシー、ロギング、および制限を設定することで、カーネル内での使用は セーフ かつ理解しやすいものです。この手法を一貫して適用すれば、パフォーマンスの問題をより迅速に解決し、キャパシティをより適切に計画し、リクエストあたりのコストを削減することができます。.