管理

PIDSTAT Linux：個々のプロセスのCPUおよびメモリ使用量を分析する

と一緒に pidstat Linuxでは、プロセスごとのCPU、メモリ、I/O、スレッドのアクティビティを一定の間隔で測定し、その瞬間の状況ではなく傾向を把握しています。そうすることで、私は ボトルネック 確実に特定し、PIDまたはコマンドに割り当て、原因がCPU、RAM、I/O、あるいはコンテキスト切り替えのいずれであるかを判断する。.

中心点

インターバル測定: 単なる「その時点の状況」ではなく、プロセスごとの時系列データ。.
幅広いカバー範囲: CPU、メモリ、I/O、スレッド、およびコンテキストスイッチ。.
ターゲットを絞ったフィルタリング: PIDまたはコマンドを使用して、対象を注視する。.
使いやすさ: sysstat をインストールし、すぐに起動する。.
実用的なメリット: 負荷のピーク、リーク、I/Oのボトルネックを迅速に特定する。.

pidstatとは？簡単に説明すると

私はこうしている。 pidstat, 、個々のプロセスのリソース使用状況を時間軸に沿って可視化するためです。このツールは、パッケージの一部です sysstat そして、各プロセスごとにCPU、メモリ、I/O、スレッド、コンテキストスイッチに関する数値を提供します。 topとは異なり、一瞬のスナップショットではなく、一定間隔で継続的に計測されたデータが得られます。これにより、周期的なスパイク、持続的な負荷、あるいは徐々に増加する傾向といったパターンを把握できます。こうした時間軸上の情報は、原因を特定のプロセスに明確に特定するのに役立ち、一瞬のスナップショットがもたらすノイズに埋もれてしまうことを防いでくれます。.

設置と迅速な稼働開始

インストールする sysstat ディストリビューションのパッケージマネージャーを使ってインストールし、追加の設定なしで即座にpidstatを起動します。基本的な構文はシンプルです： pidstat [オプション] [間隔] [数]. オプションを指定しない場合、このツールは CPU- プロセスごとの値について、指定された間隔で測定を継続的に繰り返します。例： pidstat 2 10 2秒ごとに10回の実行結果を収集します。こうすることで、その後の分析に向けた信頼性の高いタイムラインを素早く構築できます。.

CPU分析：プロセスごとの負荷を可視化する

CPUに関する質問については、以下から始めます pidstat をもって -u, 、例えば pidstat -u 1 秒単位で表示されます。%usr、%system、%CPU の各列には、各プロセスが消費したユーザー時間とカーネル時間が表示されます。特定のアプリケーションに注目したい場合は、 -p 或いは -C 名前フィルター用。%systemが大幅に上昇した場合は、システムコールやI/Oの影響を確認します。%usrが支配的である場合は、ユーザー空間での処理が原因です。プロセスごとの詳細な分析については、必要に応じて以下も参照してください。プロセス会計, 、利用データを体系的に分析するために。.

メモリ使用量を重点的に確認する

RAMに関するトピックについては、 -r 次のような貴重な知見、例えば pidstat -r -p 1234 1. 仮想的に割り当てられたメモリと常駐メモリが数分間にわたってどのように変化するか、またページフォルトが増加するかどうかを監視しています。使用量が少しずつ着実に増加している場合は、リークの可能性を早期に検知できます。使用量が一定で、ごく短い期間だけ増加する場合は、正当な キャッシング 。インターバル測定を行うことで、外れ値を実際のトレンドから明確に区別しています。.

I/Oおよびコンテキスト切り替えの理解

と一緒に -d 各プロセスごとの読み書きアクティビティを表示し、それによってストレージでの待ち時間が長くなっている原因を特定します。高い転送レートと増加するレイテンシが組み合わさっている場合は、ストレージにボトルネックが存在している可能性が示唆されます。さらに、 -w 1秒あたりのコンテキスト切り替え回数。切り替えが過度になると、不要なオーバーヘッドが発生する可能性があるためだ。自発的な切り替え（vswch/s）が多い場合は同期処理が、強制的な切り替え（cswch/s）が多い場合はCPU時間をめぐる激しい競合が示唆されます。このようにして非効率なワークロードを特定し、的を絞って改善を図っています。.

スレッドを監視し、ホットスポットを見つける

を使うか？ -t, pidstatはプロセスごとにスレッドごとの値も提供します。これにより、アプリケーションの個々のワーカーが異常な挙動を示していないかを確認できます。Java、PHP-FPM、データベース、あるいはキューワーカーにおいて、CPUを独占したりメモリ使用量を増加させたりしているスレッドをこの方法で特定できます。不均衡を発見した場合は、スレッドプールやアフィニティなどを調整し、限界。この視点は、プロセスそのものだけでなく、その内部における並行性も最適化するために役立っています。.

主なオプションの概要

私は、特定の目的でコアスイッチを活用して、分析焦点を絞って操作し、出力を分かりやすく保つこと。以下の表は、主要なオプションと代表的な用途を簡潔にまとめたものです。これにより、CPU、メモリ、I/O、スレッド、フィルターに適したスイッチを素早く選択できます。例が掲載されているため、迷うことなくすぐに使い始めることができます。各行には、明確な ヒント 用途に応じて。.

オプション	機能	例
`-u`	プロセスごとのCPU使用率を表示する	`pidstat -u 1`
`-r`	メモリおよびページフォールトの値	`pidstat -r -p 1234 2`
`-d`	I/Oアクティビティの読み取り／書き込み	`pidstat -d 1`
`-w`	プロセスごとのコンテキストの切り替え	`pidstat -w -p 1234 1`
`-t`	スレッドの統計情報を表示する	`pidstat -t -p 1234 1`
`-p`	特定のプロセスIDに限定する	`pidstat -u -p 1234 1`
`-C`	コマンドによるプロセスのフィルタリング	`pidstat -C php-fpm 2`

フィルター、間隔、および的を絞った監視

私は以下の測定を計画しています インターバル, 、この問いに関連するもの：短距離走者は秒単位、長距離走者は分単位。以上 -p そして -C これにより、出力対象を関連するプロセスに絞り込み、コンソールの表示をすっきりさせることができます。. pidstat 2 10 短いテストには最適です。回数を指定せずに、中断するまで継続して測定します。定期的なチェックを行うために、スクリプトにコマンドを登録し、その結果を記録しています。 ベースライン システムの。このルーチンにより、負荷の問題が再び発生した際に時間を節約できます。.

top、ps などとの比較.

一目で把握するために、私は トップ 或いは ps, 、しかし、推移や詳細な分析にはpidstatを利用しています。間隔ごとの値があるおかげで、単なる症状を見るだけでなく、時間の経過に伴う原因を把握することができます。CPUのボトルネックについてより深く把握したい場合は、分析に Linux perf コールスタックのサンプリング用です。このように、単純な負荷値だけでは不十分な場合、私はプロセス統計とプロファイリングを組み合わせています。この組み合わせにより、迅速な手がかりと確かな診断.

日常生活に役立つ実践的なコツ

私は実績のあるコマンドをいくつか用意しておき、状況に応じてそれらを調整して 生産システム. CPU使用率（リアルタイム）： pidstat -u 1. 注目すべきストレージ： pidstat -r -p 2. I/Oのボトルネックを確認する： pidstat -d 1. 注目のスレッド： pidstat -t -p 1. より詳細なシステム計測を行う際には、補足として bpftrace のヒントカーネルのイベントでSpotlightが必要になった場合に、それを呼び出します。.

出力の正しい読み方：タイムラインとマルチコアシステム

pidstatが時刻の参照をどのように設定しているかに注目しています：その 最初の測定ブロック デフォルトでは、プロセスの開始時（またはシステムの起動時）からの平均値が表示されます。以降のすべてのブロックは、選択された インターバル. 。詳細な分析を行う際は、最初のブロックを無視し、時間的に比較可能な区間の値のみを考察することが多い。.

時点では マルチコアシステム 私は常に、利用可能なコア数を踏まえて%CPUを解釈しています。8コアのホスト上で、単一のプロセスが複数のスレッドにスケールアウトすれば、理論上最大800%に達する可能性があります。 %systemの値が高い場合は、システムコール、ロックの競合、またはI/Oの待機パスを疑います。一方、%usrの値が高い場合は、ユーザースペースでの計算負荷の高いルーチンが実行されていることを示唆しています。各行の先頭に付いているタイムスタンプにより、推移における外れ値が明確に識別でき、他のソースのログやメトリクスとの相関分析が容易になります。.

方法論：仮説の立案、測定区間の選定

私は決して手探りで始めることはなく、まず仮説原因について：「ユーザースペースでのCPUバウンド」、「I/Oキューの詰まり」、「メモリが継続的に増加」。これに基づいて測定間隔を決定する。短いスパイクの場合は1～2秒間隔を、 クロスカントリースキーヤー どちらかといえば10～60秒程度です。重要なのは、その時間を ダイナミクス システムの調整を行い、細部を損なうことなく、かつ不必要なノイズを過度に拾わないようにする。.

また、前後で測定も行っています 変更点 （例：リリース、設定のチューニング）を行い、メトリクスにその効果を反映させる。明確な ベースライン 各環境（DEV、STAGE、PROD）ごとに確認することで、通常のパターンからの実際の逸脱を見分けるのに役立ちます。.

継続的な記録と事後処理

把握しにくい問題については、一定期間記録を取り、後で分析します。例： pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log 30分間、2秒間隔でCPU、I/O、コンテキストスイッチ、スレッドのデータを収集します。構造化されたテキスト出力は、 グレップ, アック あるいは短いスクリプト 後処理, 、ピークをマークし、目立つPIDを抽出する。繰り返し観測については、次のように計画している 回転スケジュール また、スペースを節約するために、関連する時間帯のみを確保するようにしてください。.

複数の視点が必要な場合は、複数のツールを並行して起動するのではなく、1つの実行内でスイッチを組み合わせています。これにより、測定結果が同期また、分析を容易にします。.

コンテナ、ネームスペース、およびPID

コンテナ環境では、以下の点が適用されます： PIDには名前空間が割り当てられている. ホスト内で測定するとホストのPIDが表示され、コンテナ内で測定するとコンテナのPIDが表示されます。そのため、明確に区別するために、コマンド名でフィルタリングすることを好みます。 -C 再起動後に変更される単一のPIDを使用する場合とは異なります。ホスト側で作業する場合は、後で測定値を明確に特定できるよう、プロセスコンテキスト（例：ログ内のサービス名やポッド名など）を追加します。 ワークロード 割り当てる。長時間実行される記録については、PIDの落とし穴を避けるようにしている（PIDの再利用) これも、名前フィルターや、PIDの存続期間を記録する付随ログを通じて確認できます。.

生産の安全性を確保するための測定：オーバーヘッド、権利、データ保護

オーバーヘッド: pidstat は主に以下から読み取ります /proc また、測定にかかる負荷もごくわずかです。負荷の高いホストで測定間隔が非常に短い場合は、CPUへの影響をさらに軽減するために、間隔をわずかに延長します（例：1秒から2秒へ）。「あらゆる場所のあらゆるもの」を測定するのではなく、的を絞って測定します（フィルタ！）。.

権利とセキュリティ: システム構成によっては（hidepid に於いて /proc) では、すべてのユーザーに詳細が表示されるわけではありません。本番環境では、必要に応じて権限を上げて作業し、測定時間を短く抑え、完全な表示がされているかどうかを確認しています。 コマンドライン 機密性の高いパラメータが漏洩する恐れがあります。診断データを含むログは、安全に保存・削除される場所でのみ保管すべきです。.

典型的なパターンを素早く見分ける

1TP1値が高い一方で、%値は中程度: カーネルに近いホットスポット（システムコールの多用、ロックの競合、ネットワーク／ストレージドライバのパス）に関する指摘。これをI/O値やコンテキストスイッチと照らし合わせて分析している。.
強制的なコンテキスト切り替えが多数発生（cswch/s）: CPU時間の奪い合いが激しく、多くの場合、CPUリソースが不足しているか、アクティブなスレッドが多すぎるためです。スロットリングを行ったり、プールのサイズを調整したり、あるいは 親和性 チェックする。
多数の自発的な文脈切り替え (vswch/s): 顕著な同期、あるいは収量-ベースの待機ループ。ロック、バックオフ戦略、スレッドプールの挙動について検証しています。.
着実に増加するストレージ: リークの疑い。確認中。 ページの不具合 （特に majflt) が増加しているかどうか、また、負荷のピークが過ぎた後にそのプロセスがメモリを解放するかどうかを確認します。もし解放しない場合は、より長い間隔での測定結果を用いてそれを裏付けます。.
システム全体のスループットが低いにもかかわらず、I/O転送レートが高い: 待ち時間と併せて見ると、プロセスI/Oの値は、下位のストレージスタックにおけるボトルネックを示唆しています。私は、I/Oを最適化する対策（バッチ処理、キャッシュ、非同期I/O）を優先的に実施します。.
特定のスレッドが際立っていると -t 「ホットスレッド」を特定し、スレッドプールを調整するか、そのコードパスを重点的に調査します。.

実務におけるワークフロー

CPUボトルネックを特定する: まず pidstat -u 1 グローバルに、その後、対象を絞って -p 或いは -C. %usrが上昇した場合、以下のキーワードでホットスレッドを検索します。 -t その後、必要に応じてサンプリングプロファイラで分析します。1TP1システムが主流の場合は、I/Oやコンテキストスイッチについても確認します。.

メモリリークの確認: 数分間にわたり、 pidstat -r -p 5 観察している。負荷がかかった後も減少することなく、着実な増加傾向が確認されている。並行して、ページフォールト率やI/Oパターンがこの挙動を説明できるかどうかを検証している。正当な理由がないままこの傾向が続く場合、それは明らかな リークインジケーター.

I/Oのボトルネックを特定すると pidstat -d 1 書き込み／読み取りのホットスポットを特定します。少数のプロセスによって著しい書き込み負荷が発生している場合は、それらのフラッシュ／同期パスやバッチサイズに注目します。コンテキスト切り替えとの相関関係を分析することで、同時にCPUに負荷がかかっているかどうかを確認できます。.

スレッドの偏りを修正する: pidstat -t -p 1 スレッドごとの負荷とコンテキスト切り替えを表示してくれます。あるワーカーが他のワーカーよりも著しく高温になった場合は、プールのサイズやタスクの割り当てを調整するか、あるいは 親和性 を実行し、次の区間において分布が正規化されるかどうかを確認する。.

pidstatの限界と有用な補足機能

pidstat は次のように表示します何資源を消費し、いつそれは起こる――しかし、それだけでは自動的にその理由を説明するわけではないなぜコードパス内で。「なぜ」を解明するために、私は補足としてサンプリングプロファイラやカーネルトレースポイントを利用しています。メモリに関する問題については、pidstatは傾向を明らかにしますが、オブジェクトのライフサイクルまでは把握できません。したがって、私はpidstatを 第一対応者, 、これにより最小限の手間で問題箇所を絞り込むことができます。単純な負荷値だけでは不十分な場合は、前述のツールを用いて的を絞って分析を深めます。.

クイックスタート用チェックリスト

問いを明確にする: CPU、RAM、I/O、スレッド、それともコンテキストスイッチ？
間隔を選択する: スパイクは秒単位、トレンドは分単位。.
フィルターを設定する: -p 或いは -C 出力を簡潔に保つために活用する。.
まずは全体像を把握し、それから焦点を絞る: グローバルに開始し、目立つプロセスを抽出する。.
最初のブロックを配置する: 最初の行は開始時点からの平均値であり、その後は各区間の値を比較する。.
測定時間の制限: トレンド分析に必要なデータは十分に収集しつつ、ログの管理も徹底する。.
記録する: ベースライン、仮説、測定パラメータ、および観測結果を記録しておくこと――これこそが分析の再現性を確保する鍵となる。.

簡単にまとめると

と一緒に pidstat これにより、CPU、RAM、I/O、スレッド、コンテキストスイッチに関する時間軸ベースのプロセスデータを取得し、負荷パターンの真の原因を特定できます。フィルター、間隔、明確な指標を組み合わせることで、分析は的を絞り、再現性のあるものになります。その場限りの状況に惑わされることなくトレンドを把握し、適切な対策を講じることができます。次のようなコマンドを pidstat -u 1, -r, -d そして -w 一般的なケースを網羅しています。こうして、システムの透明性を保ち、迅速な意思決定と的確な診断を実現しています。 わかりやすい.