Linuxのトラブルシューティングにおけるstraceとperf

Linuxサーバーの動作が遅い、クラッシュする、あるいはCPU使用率が異常に高くなっている場合で、アプリケーションログでは原因が特定できないときは、2つのツールがその原因のほとんどを解明してくれます。 strace は、プロセスがカーネルに何を要求しているかを示します。 perf は、CPU がどこで時間を費やしているかを教えてくれます。これらを組み合わせることで、「なぜ停止しているのか」や「何をしているのか」という疑問に、他のどのツールよりも手軽に答えを出すことができます。

この記事では、それぞれのツールをいつ使用すべきか、インストール方法、実際に実行するコマンド、そして稼働中のサーバーでオーバーヘッドを管理可能な範囲に抑える方法について解説します。

straceとperfの使い分け

使い分けは簡単です。 perf は、CPUがビジー状態であり、どの関数が原因かを特定する必要がある場合に使用します。 strace は、プロセスがハングアップしたり、クラッシュしたり、奇妙なエラーを返したり、ログでは説明がつかないような動作をしている場合に使用します。

perf は、設定可能な頻度でカーネルのハードウェアカウンタをサンプリングするため、オーバーヘッドは通常1%未満であり、本番環境で実行しても安全です。 strace は ptraceを介してすべてのシステムコールをインターセプトするため、対象プロセスの処理速度が10倍から100倍遅くなる可能性があります。稼働中のシステムでは控えめに使用し、常にフィルタを適用してください。

strace と perf のインストール

どちらのツールも標準リポジトリに含まれています。straceは ptrace syscallに依存しており、これは長年にわたりすべての最新カーネルに組み込まれています。perfは perf_events インターフェースを使用しており、実行中のカーネルに適合するパッケージが必要です。

Ubuntu または Debian の場合:

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

RHEL、AlmaLinux、または Fedora の場合:

sudo dnf install strace perf

この $(uname -r) ビットは重要です。異なるカーネルバージョンに対してビルドされた perf バイナリは、混乱を招く出力を生成したり、イベントを黙って破棄したりする可能性があります。 perf --version および strace -V で確認してください。

perfが16進数のアドレスの代わりに関数名を表示するには、デバッグシンボルが必要です。関連する -dbg または -debuginfo パッケージ（例： libc6-dbg Debianの場合）、GCCで -g を使用して独自のバイナリをコンパイルしてください。

コンテナ内では、 strace には --cap-add=SYS_PTRACE と perf が必要です --cap-add=SYS_ADMIN が必要です。これらがなければ、ツールはバグのように見える形で動作しなくなります。

strace を使用したシステムコールの追跡

実行 strace command を実行すると、プロセスの起動時からトレースが行われます。実行中のプロセスにアタッチするには、 strace -p PIDを使用します。マルチスレッドやフォークを行うプロセスについては、子プロセスを追跡するために -f を追加して子プロセスを追跡してください。そうしないと、アクティビティの大部分を見逃してしまいます。

出力行は戻り値で終わります。 -1 ENOENT は、プロセスが要求したファイルが存在しないことを意味します。 -1 EACCES は権限の問題を示します。これら2つのエラーだけで、本番環境のバグの驚くほど大きな割合を占めています。

最も有用なフラグは -e trace=GROUPです。これは、出力を指定されたシステムコールのカテゴリに限定し、ノイズを管理可能な範囲に抑えます。

負荷の高いサーバーでは、 strace -c -p PID を実行して10～20秒間実行します。 -c このフラグを指定すると、プロセスから切り離した際に、システムコール回数、合計時間、エラーの概要が表示されます。これにより、ターミナルをエラーで埋め尽くすことなく、どのカテゴリを詳しく調べるべきかがわかります。その後、絞り込んだフィルタで再接続してください。

知っておくと便利なその他のフラグ： -T 各呼び出しにかかった時間を記録し、 -Z 失敗した呼び出しのみを表示し、 -o file ターミナルではなくログに書き出す（処理が激しいプロセスでは、こちらの方がはるかに高速です）。

perf を使用した CPU プロファイリング

perf には、ほとんどの場合に使用する 4 つのコマンドがあります。

まずは perf stat -p PID から概要を確認しましょう。注目すべき数値：

• IPC（1サイクルあたりの命令数）が1.0未満：CPUがストールしており、通常はメモリアクセスが原因です。
• LLCロードミスが多すぎる：ワーキングセットがキャッシュに収まっていないため、CPUがRAMを待機している。
• コンテキストスイッチ回数が多すぎる：スレッドがディスクやネットワークでブロックし続けるI/Oバウンドなワークロードでは典型的な現象です。

何か異常が見られる場合は、 perf record -F 99 -g -p PID -- sleep 30。 -F 99 99 Hzでサンプリングを行います。これはホットな関数を見つけるには十分であり、100 Hzのような整数倍でカーネルタイマーとの同期を避けることができます。 -g フラグはコールグラフをキャプチャするため、 perf report を使用すると、関数へのどのパスが原因であるかを確認できます。

「 perf reportの「Overhead」列は、総サンプル数に占める割合を示しています。 _int_malloc または memcpy は、割り当て負荷が高いことを意味します。自身の関数の一つでオーバーヘッドが高い場合は、それが探していたホットスポットです。

関数名の代わりに16進数のアドレスが表示されている場合は、バイナリがストリップされているか、デバッグシンボルが欠落しています。対応する -dbg パッケージをインストールするか、バイナリを -g.

稼働中のサーバーにおける実用的なワークフロー

稼働中のサーバーで実際に発生したインシデントに対する手順は、以下の通りです：

1. まず、手軽なツールで症状を確認します： top, vmstat, iostat。VM上で作業している場合は、 st (steal) 列を確認してください。5%を超える値があれば、ボトルネックはコードではなくハイパーバイザーです。
2. CPU使用率が高い場合は、 perf top を数秒間実行し、その後 perf record -F 99 -g -p PID -- sleep 30 問題のあるプロセスに対して`ps`を実行してください。99 Hzで30秒間キャプチャすると、約1.7 MBのデータが生成されます。
3. プロセスがハングアップしている、動作が遅い、またはエラーを返している場合は、 strace -c -p PID を10秒間実行し、サマリーを確認してください。特定のシステムコールカテゴリが突出している場合は、 strace -e trace=GROUP -T -p PID.
4. 疑わしいシステムコールや関数が見つかったら、デタッチしてください。本番環境では、どちらのツールも必要以上に長時間実行し続けないでください。

2つの注意点があります。 strace 出力には環境変数、ファイルパス、ソケットから読み込まれたバイトなどが含まれる可能性があるため、チーム外に共有する前にログをサニタイズしてください。また、これを定期的に行う場合は、次のステップとして bpftrace およびより広範な eBPF ツールキットを検討してください。これらは、同様の可視性を提供し、オーバーヘッドは 1% 未満で、最初から本番環境向けに構築されています。

詳細な診断アクセスが重要であり、共有インフラの利用が不可能なワークロードを実行する場合は、当社の専用サーバーをご検討ください。