2.0.概要
この章では、システムレベルの Linux パフォーマンス ツールの概要を説明します。これらのツールは、パフォーマンスの問題を追跡する際の最初の防御線となります。システム全体がどのように動作しているか、どの部分の動作が低下しているかを示すことができます。
1. CPU 使用率など、システムレベルのパフォーマンスの基本的な指標を理解します。
2. これらのシステムレベルのパフォーマンス指標を取得できるツールを理解します。
2.1CPU パフォーマンス統計
統計の意味を複数回 (ツールごとに 1 回) 説明する必要がないように、すべてのツールについて説明する前にこの情報を 1 回説明します。
2.1.1 実行キューの統計
プロセスが実行可能で、プロセッサの使用を待機している場合、プロセスは実行キューを形成します。実行キューが長いほど、待機しているプロセスが多くなります。通常、パフォーマンス ツールは、実行可能なプロセスの数と、I/O を待機しているブロックされたプロセスの数を示します。もう 1 つの一般的なシステム統計は負荷平均です。システムの負荷は、実行中のプロセスと実行可能なプロセスの合計数です。たとえば、実行中のプロセスが 2 つ、実行可能なプロセスが 3 つある場合、システム負荷は 5 になります。負荷平均は、一定期間内の負荷の量です。一般に、平均ロード時間は 1 分、5 分、15 分です。これにより、時間の経過とともに負荷がどのように変化するかを観察できます。
2.1.2 コンテキストの切り替え
最新のプロセッサでは、一度に 1 つのプロセスまたはスレッドしか実行できません。一部のプロセッサ (ハイパースレッド プロセッサなど) は実際には複数のプロセスを同時に実行できますが、Linux はそれらを複数のシングル スレッド プロセッサとして扱います。特定の単一プロセッサが複数のタスクを同時に実行しているかのような錯覚を作り出すには、Linux カーネルが異なるプロセス間を常に切り替える必要があります。異なるプロセス間のこの種の切り替えは、コンテキスト スイッチと呼ばれます。これが発生すると、CPU は古いプロセスのすべてのコンテキスト情報を保存し、新しいプロセスのすべてのコンテキスト情報を取り出す必要があるからです。コンテキストには、プロセスが実行している命令、プロセスに割り当てられたメモリ、プロセスによって開かれたファイルなど、Linux が新しいプロセスを追跡するための大量の情報が含まれています。これらのコンテキスト切り替えには大量の情報の移動が含まれるため、コンテキスト切り替えのオーバーヘッドがかなり大きくなる可能性があります。コンテキスト切り替えの数を最小限に抑えることをお勧めします。
コンテキストの切り替えを回避するには、コンテキストの切り替えがどのように発生するかを理解することが重要です。まず、コンテキストの切り替えはカーネルのスケジューリングの結果である可能性があります。各プロセスにプロセッサ時間を公平に割り当てるために、カーネルは実行中のプロセスを定期的に中断し、適切な状況下では、カーネル スケジューラは現在のプロセスの実行を継続するのではなく、別のプロセスを開始することを決定します。このような定期的またはスケジュールされた割り込みが発生するたびに、システムはコンテキストの切り替えを実行する場合があります。1 秒あたりのスケジュールされた割り込みの数は、アーキテクチャとカーネルのバージョンに関係します。割り込みの頻度を確認する簡単な方法は、/proc/interrupts ファイルを使用することです。このファイルを使用すると、既知の期間内に発生する割り込みの数を判断できます。リスト 2.1 に示すとおりです。
リスト 2.1 では、カーネルにタイマーの開始回数を要求し、10 秒待ってから再度要求します。これは、このマシンではタイマーが (24070093-24060043) 割り込み/(10 秒)、つまり約 1000 割り込み/秒の頻度で開始されることを意味します。タイマー割り込みよりもコンテキストの切り替えが大幅に多い場合、これらの切り替えは、I/O 要求またはその他の長時間実行されるシステム コール (スリープなど) によって引き起こされる可能性が高くなります。アプリケーションがすぐに完了できない操作を要求すると、カーネルは操作を開始し、要求しているプロセスを保存し、準備ができている別のプロセスに切り替えようとします。これにより、プロセッサが可能な限りビジー状態に保たれます。
2.1.3 中断
さらに、プロセッサはハードウェア デバイスから定期的に割り込みを受け取ります。これらの割り込みは通常、カーネルによる処理が必要なイベントがデバイスに発生したときにトリガーされます。たとえば、ディスク コントローラがドライブからのデータ ブロックのフェッチを完了し、それをカーネルに提供する準備ができている場合、ディスク コントローラは割り込みをトリガーします。カーネルが受信した各割り込みについて、対応する登録された割り込みハンドラーがある場合はプログラムが実行され、そうでない場合は割り込みは無視されます。これらの割り込みハンドラーはシステム内で高い優先順位を持っており、通常は非常に高速に実行されます。場合によっては、割り込みハンドラーには実行すべき作業がありますが、高い優先順位は必要ないため、いわゆるソフト割り込みハンドラーである「下半分」 (下半分) を開始できます。割り込みが多数ある場合、カーネルは割り込みの処理に多くの時間を費やします。/proc/interrupts ファイルを見ると、どの CPU でどの割り込みがトリガーされたかを確認できます。
2.1.4 CPU使用率
CPU 使用率は単純な概念です。CPU は常に、次の 7 つの動作のうち 1 つを実行できます。
(1) CPU はアイドル状態になることができます。これは、プロセッサが実際には作業を行わず、タスクの実行を待機していることを意味します。
(2) CPU はユーザー コード、つまり指定された「ユーザー」時間だけ実行できます。
(3) CPU は Linux カーネルでアプリケーション コードを実行できます。これは「システム」時間です。
(4) CPU は、「フレンドリー」なユーザーコード、または一般プロセスよりも優先度が低く設定されたユーザーコードを実行できます。
(5) CPU は iowait 状態になる可能性があります。つまり、システムは I/O (ディスクまたはネットワークなど) が完了するのを待っています。
(6) CPU は irq 状態になる可能性があります。つまり、CPU は優先度の高いコードでハードウェア割り込みを処理しています。
(7) CPU は、softirq モードにすることができます。つまり、システムは割り込みによってもトリガーされるカーネル コードを実行しますが、より低い優先順位 (コードの下半分) で実行されます。
ほとんどのパフォーマンス ツールは、これらの値を合計 CPU 時間のパーセンテージとして表します。これらの時間の範囲は 0% から 100% ですが、3 つすべてを合計すると 100% になります。システムの割合が高いシステムは、ほとんどの時間がコアに費やされていることを示します。opprofile などのツールは、どこに時間が費やされているかを判断するのに役立ちます。「ユーザー」時間が長いシステムは、ほとんどの時間をアプリケーションの実行に費やします。次の章では、パフォーマンス ツールを使用して上記の状況で問題を追跡する方法を説明します。システムが動作しているはずのときに iowait 状態で長時間を費やす場合は、デバイスからの I/O を待機している可能性があります。速度低下の原因は、ディスク、ネットワーク カード、またはその他のデバイスである可能性があります。
2.2Linux パフォーマンス ツール: CPU
次に、前述の情報を抽出できるパフォーマンス ツールについて説明します。
2.2.1vmstat (仮想メモリ統計)
vmstat は仮想メモリ統計を指し、その名前はシステムの仮想メモリのパフォーマンス情報を知ることができることを示しています。幸いなことに、実際にはそれ以上のことができます。vmstat は、システム全体のパフォーマンスに関する次のような大まかな情報を取得できる非常に便利なコマンドです。
1. 実行中のプロセスの数。
2.CPU使用率。
3.CPU が受信した割り込みの数。
4. スケジューラによって実行されたコンテキスト切り替えの数。
これは、システムのパフォーマンスの概要を把握するための優れたツールです。
2.2.1.1CPU パフォーマンス関連のオプション
vmstat は、コマンド ライン vmstat [-n] [-S] [delay [count]] から呼び出すことができます。vmstat は、サンプリング モードと平均化モードの 2 つのモードで実行されます。パラメーターが指定されていない場合、vmstat 統計は平均モードで実行され、vmstat はシステムの起動以降のすべての統計データの平均を表示します。ただし、遅延が指定されている場合、最初のサンプルはシステム起動以降の平均値のままですが、vmstat は遅延秒単位でシステムをサンプリングし、統計を表示します。表 2-1 では、vmstat オプションについて説明します。
vmstat によって提供されるさまざまな統計出力情報を使用して、システム パフォーマンスのさまざまな側面を追跡できます。表 2-2 では、CPU パフォーマンスに関連する出力について説明します。次の章では、メモリのパフォーマンスに関連する出力について説明します。
vmstat は、オーバーヘッドの少ないシステム パフォーマンスの優れたビューを提供します。すべてのパフォーマンス統計はテキスト形式で表示され、標準出力に出力されるため、テスト中や後のプロセス中に生成されたデータをキャプチャしてプロットするのに便利です。vmstat はオーバーヘッドが非常に低いため、非常に負荷の高いサーバーであっても、システムの状態を一目で監視する必要がある場合には、コンソールまたはウィンドウで継続的に実行することが実用的です。
2.2.1.2 使用例
リスト 2.2 に示すように、コマンド ライン パラメーターを指定せずに vmstat を実行すると、表示されるのは、システムの起動以降に記録された統計の平均です。「CPU 使用率」列の sy、wa、および id によると、この例は、システムが起動以来基本的にアイドル状態であることを示しています。起動時から、CPU は時間の 5% をユーザー アプリケーション コードの実行に費やし、時間の 1% をシステム コードの実行に費やし、残りの 94% はアイドル状態になります。
vmstat は、システム起動時から統計を開始することでシステム負荷を特定するのに役立ちますが、リスト 2.3 に示すように、vmstat はサンプリング モードで実行するときに最も役立ちます。サンプリング モードでは、vmstat は、遅延パラメータで指定された間隔でシステム統計を出力し、サンプル数は count で指定されます。リスト 2.3 の最初の行の統計は前と同じで、システムの開始以来の平均ですが、定期的にサンプリングされています。この例では、システムのアクティビティはほとんど示されていません。列 b の下の 0 を見ると、実行時にブロックされたプロセスがないことがわかります。r 列を見ると、vmstat がデータをサンプリングしたときに実行中のプロセスの数が 1 未満であったこともわかります。
vmstat は、特定の負荷またはテスト条件下でのシステムの動作を記録する優れた方法です。vmstat を使用してシステムの動作を表示し、Linux tee コマンドを使用して結果をファイルに出力できます。(第 8 章で tee コマンドについて詳しく説明します。) 遅延パラメーターのみを渡すと、vmstat は無限にサンプリングします。テストの開始前に vmstat を開始し、テストの終了後に vmstat を終了します。出力ファイルはスプレッドシートの形式にすることができ、システムが負荷やさまざまなシステム イベントにどのように反応するかを確認するために使用できます。リスト 2.4 は、このアプローチの出力を示しています。この例では、システム上で発生した割り込みとコンテキストの切り替えを確認できます。割り込みとコンテキストスイッチの合計数は、それぞれ in 列と cs 列で確認できます。コンテキストスイッチの数は割り込みの数よりも少ないです。スケジューラは、タイマー割り込みが発生するよりも少ない頻度でプロセスを切り替えます。これは、システムが基本的にアイドル状態であり、タイマー割り込みが発生するほとんどの場合、スケジューラには実行する作業がないため、アイドル プロセスから切り替える必要がないことが原因であると考えられます。
vmstat の最新バージョンでは、リスト 2.5 に示すように、さまざまなシステム統計に関するより詳細な情報を抽出することもできます。次の章ではメモリ統計について説明しますが、今度は CPU 統計を見てみましょう。最初のデータセット「CPU ティック」は、システムが起動してからの CPU 時間を示します。「ティック」は時間単位です。合理化された vmstat 出力には 4 つの CPU 状態 (us、sy、id、および wa) のみが表示されますが、ここではすべての CPU ティックの分布が表示されます。さらに、割り込みとコンテキストスイッチの合計数も確認できます。新たに追加されたのはフォークです。これは、システムの起動以降に作成された新しいプロセスの数を大まかに表します。
vmstat は、Linux システムのパフォーマンスに関する豊富な情報を提供します。これは、システムの問題を調査する際の中心的なツールの 1 つです。
2.2.2トップ(バージョン2.0.x)
一番上は Linux システム監視ツールの Swiss Army Knife です。かなりの量の全体的なシステム パフォーマンス情報を 1 つの画面に表示するのが得意です。表示は対話的に変更することもできるため、システムの実行中に特定の問題が繰り返し発生する場合は、上部に表示される情報を変更できます。デフォルトでは、top は CPU を最も多く消費するプロセスのリストとして降順で表示されます。これにより、どのプログラムが CPU を占有しているのかをすぐに見つけることができます。top は、指定された遅延 (初期値は 3 秒) に従ってこのリストを定期的に更新します。
2.2.2.1CPU パフォーマンス関連のオプション
top は、次のコマンド ラインで呼び出されます。 top [d late] [C] [H] [i] [n iter] [b]top には、実際には、コマンド ライン オプションとランタイム オプションの 2 つのモードのオプションがあります。コマンド ライン オプションは、top がその情報をどのように表示するかを決定します。表 2-3 に示すコマンド ライン オプションは、top によって表示されるパフォーマンス統計の種類と頻度に影響します。
トップを実行するとき、特定の問題を調査するために、観察結果をわずかに調整する必要がある場合があります。上部の出力は高度にカスタマイズ可能です。表 2-4 に示すオプションにより、トップ ランニング中に表示される統計を変更できます。
表 2-5 に示すオプションは、さまざまなシステムレベル情報の表示をオンまたはオフにします。不要な統計をオフにすると、より多くのプロセスを画面上に表示し続けることができます。
表 2-6 では、top でサポートされるさまざまな並べ替えモードについて説明します。メモリ消費量による並べ替えは、どのプロセスが最も多くのメモリを消費しているかを調べるのに特に役立ちます。
特定のプロセスに関する情報を提供することに加えて、top はシステム全体の情報も提供します。表 2-7 にこれらの統計を示します。
top は、実行中のさまざまなプロセスに関する豊富な情報を提供し、リソースの大量消費を特定する優れた方法です。
2.2.2.2 使用例
リスト 2.6 は、top を実行する例です。起動すると、終了するまで定期的に画面が更新されます。この例は、top が生成できるシステム全体の統計の一部を示しています。初め。1 分、5 分、15 分のシステム負荷平均が表示されます。システムがビジー状態になっていることがわかります (doom-3.x86 のせいで)。CPU は時間の 90% をユーザー コードに費やします。別のサービスでは、ユーザー コードに時間の約 13% しか費やしませんでした。最後に、73 のプロセスがスリープ状態で、3 つのプロセスのみが実行されていることがわかります。
ここで、top の実行中に F キーを押して、リスト 2.7 に示すように構成インターフェースをポップアップ表示します。代表的なキー (A は PID、B は PPID など) を押すと、画面上のこれらの統計の表示が切り替わります。必要な統計情報をすべて選択したら、Enter キーを押して上部の最初のインターフェイスに戻り、選択した統計情報の現在の値が表示されます。統計を構成する場合、現在選択されているすべてのフィールドは、「現在のフィールドの順序」行に大文字で表示され、名前の横にアスタリスク (*) が表示されます。
実際の測定: F を押して対話型設定に入り、スペースを使用して選択と選択を解除し、上矢印と下矢印を使用して別の項目を選択し、Esc を使用して確認してトップ表示ページに戻ります。
top のカスタマイズ可能性を示すために、リスト 2.8 では、CPU 使用率に関連する最上位のオプションのみを表示する、高度に構成可能な出力インターフェイスを示します。
上部では、さまざまなプロセスがこれらのリソースをどのように消費するかに焦点を当てて、システム リソースの使用状況の概要を示します。その出力形式はユーザーには使いやすく、ツールには不向きであるため、システムと直接対話する場合に最適です。
2.2.3 トップ(バージョン 3.xx)
最近、最新バージョンで提供されるトップが完全に変更され、その結果、多くのコマンド ラインと対話型オプションが変更されました。基本的な考え方は似ていますが、top が合理化され、いくつかの異なる表示モードが追加されました。同様に、「top」は降順リストとして表示され、CPU を最も多く消費するプロセスが先頭になります。
2.2.3.1CPU パフォーマンス関連のオプション
次のコマンド ラインを使用して、top:top [-d late] [-n iter] [-i] [-b] を呼び出します。実際、top にはコマンド ライン オプションとランタイム オプションという 2 つのモードのオプションがあります。コマンド ライン オプションは、top がその情報をどのように表示するかを決定します。表 2-8 に示されているコマンド ライン オプションは、top によって表示されるパフォーマンス統計の種類と頻度に影響します。
top を実行するとき、特定の問題を調査するために観察をわずかに調整することが必要になる場合があります。最上位の 2.x バージョンと同様、その出力は高度にカスタマイズ可能です。表 2-9 に、top の実行中に表示される統計を変更するオプションを示します。
表 2-10 に示すオプションは、さまざまなシステムレベル情報の表示をオンまたはオフにします。不要な統計をオフにすると、より多くのプロセスを画面上に表示し続けることができます。
topv2.x と同様に、top v3.x は、特定のプロセスに関する情報に加えて、システム全体の情報を提供します。表 2-11 にこれらの統計を示します。
top は、実行中のさまざまなプロセスに関する豊富な情報を提供し、リソースの大量消費を特定する優れた方法です。top v.3 は、top を簡素化し、同じデータのいくつかの異なるビューを追加します。
2.2.3.2 使用例
リスト 2.9 は、top v3.0 を実行する例です。同様に、終了するまで画面が定期的に更新されます。統計は上位の v2.x と同じですが、名前がわずかに変更されています。
ここで、top の実行中に f キーを押して、リスト 2.10 に示すように構成インターフェースを表示します。代表的なキー（A は PID、B は PPID など）を押すと、画面上のこれらの統計の表示が切り替わります。必要な統計情報をすべて選択したら、Enter キーを押して上部の最初のインターフェイスに戻り、選択した統計情報の現在の値が表示されます。統計を構成する場合、現在選択されているすべてのフィールドは、「現在のフィールドの順序」行に大文字で表示され、名前の横にアスタリスク (*) が表示されます。ほとんどの統計は同じですが、名前が若干変更されていることに注意してください。
リスト 2.11 は、新しいトップ出力モードを示しています。このモードでは、多くの異なる統計が分類され、同じ画面に表示されます。
top v3.x は、top に対してもう少しシンプルなインターフェイスを提供します。これは、top のいくつかの側面を簡素化し、システム内の多くのリソース消費者を示す優れた「概要」情報画面を提供します。
2.2.4 procinfo (/proc ファイルシステムからの情報の表示)
vmstat と同様、procinfo もシステムの全体的な情報特性の概要を提供します。vmstat と同じ情報の一部が提供されますが、CPU が各デバイスから受信した割り込みの数も提供されます。その出力形式は vmstat よりもわずかに読みやすいですが、より多くの画面スペースを必要とします。
2.2.4.1CPU パフォーマンス関連のオプション
procinfo の呼び出しコマンド ラインは次のとおりです: procinfo [-f] [-d] [-D] [-n sec] [·f file]。表 2-12 では、procinfo 表示サンプルの出力と頻度を変更するためのさまざまなオプションについて説明します。
表 2-13 は、procinfo によって収集された CPU 統計を示します。
vmstat や top と同様、procinfo はオーバーヘッドの低いコマンドで、コンソールまたは画面ウィンドウから単独で実行するのに適しています。これは、システムの健全性とパフォーマンスをよく反映しています。
2.2.4.2 使用例
コマンド オプションを指定せずに procinfo を呼び出すと、リスト 2.12 に示す出力が生成されます。パラメーターを指定しないと、procinfo はステータス情報を 1 画面だけ表示して終了します。-n 2 番目のオプションを使用すると、procinfo を定期的に更新でき、より便利になります。これにより、システム パフォーマンスの変化をリアルタイムで確認できます。
リスト 2.12 からわかるように、procinfo はシステムの概要をわかりやすく示しています。ユーザー時間、ナイス時間、システム時間、アイドル時間を見てみると、システムがそれほどビジーではないことがわかります。注目すべき興味深い現象は、システムが実行中 (稼働時間として表される) よりもアイドル状態で費やした時間の方が長いことを procinfo が示していることです。これは、システムには実際に 4 つの CPU が搭載されているため、実測時間の 1 日に対して CPU 時間が 4 日経過することになります。負荷平均は、システムの最近の作業が比較的少ないことを証明します。時間の経過とともに、平均して、システムで実行可能なプロセスは 1 つ未満になりました。負荷平均 0.47 は、単一プロセスが実行可能な状態にあった時間は 47% のみであることを意味します。4 つの CPU を備えたシステムの場合、多くの CPU パワーが無駄になります。
procinfo を使用すると、システム内のどのデバイスが割り込みを引き起こしているのかを把握できます。グラフィックス カード (nvidia)、ハードディスク コントローラー (ide0)、イーサネット デバイス (eth0)、およびサウンド カード (es1371) の割り込み数が比較的多いことがわかります。このような状況は通常、デスクトップ ワークステーションで発生します。procinfo の利点は、多くのシステムレベルのパフォーマンス統計を 1 つの画面に表示し、システムの全体的なパフォーマンスを理解できることです。ネットワークとディスクのパフォーマンスに関する詳細な情報はありませんが、CPU とメモリのパフォーマンスに関する統計については十分な詳細が提供されます。重要な制限の 1 つは、CPU が iowait、irq、または Softirq モードの場合に procinfo が報告しないことです。
2.2.5 gnome-システムモニター
gnome-system-monitor は、多くの点で top のグラフィカル バージョンであると言えます。個々のプロセスをグラフィカルに監視し、表示されたグラフに基づいてシステム負荷を観察できます。
2.2.5.1CPU パフォーマンス関連のオプション
gnome-system-monitor は、Gnome メニューから呼び出すことができます。(Red Hat 9 以降では、メニューから [システム ツール] → [システム モニター] を選択します。) ただし、コマンド gnome-system-monitor を使用して呼び出すこともできます。gnome-system-monitor には、CPU パフォーマンスの測定に影響を与える関連コマンド ライン オプションがありません。ただし、表示される統計の一部は、gnome-system-monitor の [編集] → [設定] メニュー項目を選択することで変更できます。
2.2.5.2 使用例
gnome-system-monitor を起動すると、図 2-1 のようなウィンドウが作成されます。このウィンドウには、特定のプロセスによって使用される CPU とメモリの合計量に関する情報が表示されます。また、プロセス間の親子関係に関する情報も表示されます。図 2-2 は、システム負荷とメモリ使用量のグラフを示しています。この時点から、gnome-system-monitor を上位から実際に区別できるようになります。システムの現在の状態を簡単に表示し、以前の状態と比較できます。gnome-system-monitor によって提供されるデータのグラフィカルなビューにより、システムのステータスと時間の経過に伴う動作の変化を簡単かつ迅速に判断できるようになります。また、システムレベルのプロセス情報の参照も容易になります。
](https://img-blog.csdnimg.cn/a8612aeda95f40a0871b312f22a41602.png)
2.2.6.mpstat (マルチプロセッサ統計)
mpstat は、時間の経過に伴う CPU の動作を表示する非常に単純なコマンドです。mpstat の最大の利点は、統計の横に時間が表示されるので、CPU 使用率と時間の関係を確認できることです。複数の CPU またはハイパースレッド CPU がある場合、mpstat は CPU 使用率をプロセッサごとに分析することもできるため、1 つのプロセッサが他のプロセッサよりも多くの作業を実行しているかどうかを確認できます。監視したい単一のプロセッサを選択することも、mpstat にすべてのプロセッサを監視するように依頼することもできます。
2.2.6.1CPU パフォーマンス関連のオプション
mpstat は、コマンド ライン mpstat [-P { cpu | ALL } ] [delay [count]] を使用して呼び出すことができます。前と同様に、[遅延] はサンプリング間隔を指定し、[カウント] はサンプル数を指定します。表 2-14 では、mpstat コマンド ライン オプションの意味を説明します。
mpstat は他の CPU パフォーマンス ツールと同様の情報を提供しますが、特定のシステム内の個々のプロセッサごとに情報を分類できます。表 2-15 に、mpstat でサポートされるオプションを示します。
mpstat は、各プロセッサのパフォーマンスの内訳を提供する優れたツールです。mpstat は CPU ごとの内訳を提供するため、過負荷になっているプロセッサがあるかどうかを特定できます。
2.2.6.2 使用例
まず、リスト 2.13 に示すように、mpstat にプロセッサ番号 0 の CPU の統計を表示するよう依頼します。
リスト 2.14 は、ロードされていない一般的なハイパースレッド CPU で同じコマンドを使用した結果を示しています。すべての CPU 統計が表示されます。出力で興味深いのは、CPU の 1 つがすべての割り込みを処理しているように見えることです。システムの I/O 負荷が高く、すべての割り込みが 1 つのプロセッサによって処理される場合、他の CPU が待機している間に 1 つの CPU が過負荷になるため、これがボトルネックになる可能性があります。1 つの CPU がすべての割り込みの処理でビジーで時間がなく、同時に他のプロセッサがアイドル状態である場合、mpstat を使用するとこの状況を見つけることができます。
mpstat を使用すると、CPU が完全に利用されているかどうか、および使用率が比較的バランスが取れているかどうかを判断できます。各 CPU が処理する割り込みの数を調べることで、不均衡を見つけることができます。割り込みルーティングの制御方法の詳細については、Documentation/IRQ-affinity.txt にあるカーネル ソース コードを参照してください。
2.2.7 sar (システムアクティビティレポート)
sar は別の方法を使用してシステム データを収集します。sar は、収集したシステム パフォーマンス データをバイナリ ファイルに効果的に記録し、後で再生できるようにします。sar は、システム実行情報を記録するオーバーヘッドの低い方法です。sar コマンドを使用すると、パフォーマンス情報を記録したり、以前に記録した情報を再生したり、現在のシステムのリアルタイム情報を表示したりできます。sar コマンドの出力は、データベースにインポートしたり、他の Linux コマンドに供給して処理したりしやすいようにフォーマットできます。
2.2.7.1CPU パフォーマンス関連のオプション
sar は、コマンド ライン sar [options] [delay [count]] を使用して呼び出すことができます。sar のレポートは Linux のさまざまな領域をカバーしていますが、その統計は 2 つの異なる形式で提供されます。一連の統計は、サンプリング時の瞬時値です。もう 1 つのセットは、最後のサンプル以降の変更です。表 2-16 では、sar コマンド ライン オプションについて説明します。
sar によって提供されるシステムレベルの CPU パフォーマンス統計のセットは、プロセス ツールで表示されるものと似ています (名前は異なります)。表 2-17 に示すとおりです。
sar の最も重要な利点の 1 つは、後で取得して確認できるように、さまざまなタイプのタイムスタンプ付きシステム データをログ ファイルに保存できることです。この機能は、特定のマシンが特定の時間に失敗した理由を調べようとする場合に非常に便利であることがわかります。
2.2.7.2 使用例
リスト 2.15 に示す最初のコマンドは、1 秒あたり 3 つの CPU サンプルを必要とし、結果はバイナリ ファイル /tmp/apache_test に保存されます。このコマンドには視覚的な出力はなく、完了すると戻ります。
情報が /tmp/apache_test ファイルに保存されると、さまざまな形式で表示できます。リスト 2.16 に示すように、デフォルトの形式は人間が判読できる形式です。このリストには、他のシステム監視コマンドと同様の情報が表示され、特定の時点でプロセッサがどのように時間を消費しているかを確認できます。
ただし、リスト 2.17 に示すように、sar はリレーショナル データベースに簡単にインポートできる形式で統計を出力することもできます。これは、大量のパフォーマンス データを保存するのに役立ちます。このパフォーマンス データは、リレーショナル データベースにインポートされると、すべてのリレーショナル データベース ツールを使用して分析できます。
最後に、sar には、awk、perl、python、grep などの標準 Linux ツールで簡単に解析できる統計出力形式があります。リスト 2.18 に示すように、この出力をスクリプトに入力すると、興味深いイベントがトリガーされ、さまざまな傾向についてデータが分析される可能性もあります。
sar は、情報をファイルに記録するだけでなく、リアルタイムのシステム監視にも使用できます。リスト 2.19 に示す例では、CPU 状態が 1 秒間隔で 3 回サンプリングされます。
デフォルトの表示の目的は CPU 情報を表示することですが、他の情報を表示することもできます。たとえば、sar は、1 秒あたりのコンテキスト スイッチの数とスワップされたメモリ ページの数を表示できます。リスト 2.20 では、sar は 1 秒間隔で情報を 2 回サンプリングします。今回は sar に 1 秒あたりのコンテキストスイッチの数と作成されたプロセスの数を表示させます。また、sar に負荷平均に関する情報を提供するように依頼しました。この例のマシンのメモリには 163 のプロセスがありますが、どれも実行されていないことがわかります。過去 1 分間に、平均 1.12 個のプロセスが実行を待機していました。
ご覧のとおり、sar はさまざまなパフォーマンス統計を記録できる強力なツールです。パフォーマンス データを簡単に抽出して分析できる Linux フレンドリーなインターフェイスを提供します。
2.2.8.oプロファイル
oprofile は、ほとんどすべての最新のプロセッサーに搭載されているパフォーマンス カウンターを使用して、システム全体および個々のプロセスの CPU 時間の消費を追跡するパフォーマンス ツールキットです。opprofile は、CPU サイクルがどこで消費されているかを測定するだけでなく、CPU 実行に関する非常に低レベルの情報も測定できます。基礎となるプロセッサによってサポートされるイベントに応じて、浮動小数点演算だけでなく、キャッシュ ミス、分岐予測ミス、メモリ参照も測定できます。oprofile は、発生するすべてのイベントを記録するのではなく、プロセッサ パフォーマンス ハードウェアと連携してすべての count イベントをサンプリングします (count は、oprofile の起動時にユーザーが指定した数値です)。count の値が小さいほど、結果の精度が高くなり、oprofile のオーバーヘッドが大きくなります。count が適切な値に保たれている場合、oprofile は実行オーバーヘッドが非常に低いだけでなく、驚くほどの正確さでシステム パフォーマンスを記述することもできます。サンプリングは非常に強力ですが、使用する際には注意すべき微妙な落とし穴がいくつかあります。
まず、サンプリングによって、時間の 90% を特定のルーチンに費やしていることがわかるかもしれませんが、その理由はわかりません。特定のルーチンが大量のサイクルを消費する理由は 2 つ考えられます。まず、このルーチンがボトルネックになる可能性があり、その実行に時間がかかります。ただし、ルーチンの実行時間は妥当であるにもかかわらず、呼び出される回数が非常に多いという可能性もあります。どちらに該当するかを調べる方法は通常 2 つあります。1 つはサンプルを見て特に人気のある行を見つける方法、もう 1 つはルーチンが呼び出される回数をカウントするコードを作成する方法です。サンプリングに関する 2 番目の問題は、関数がどこから呼び出されているかを完全に確信できないことです。それが何度も呼び出されることを把握し、それを呼び出すすべての関数を追跡したとしても、そのうちのどの関数が呼び出しの大部分を完了するかは必ずしも明らかではありません。
2.2.8.1.CPU パフォーマンス関連のオプション
oprofile は実際には、CPU パフォーマンス統計を収集するために連携して動作する一連のコンポーネントです。oprofile には 3 つの主要な部分があります。
1.oprofile コア モジュールはプロセッサを制御し、サンプリングを許可または無効にします。
2. oprofile バックグラウンド モジュールはサンプルを収集し、ディスクに保存します。
3. oprofile レポート ツールは、収集されたサンプルを取得し、システム上で実行されているアプリケーションとの関係をユーザーに示します。
oprofile ツールキットは、opcontrol コマンド内のドライバーおよびバックグラウンド操作を隠します。opcontrol コマンドは、プロセッサによってサンプリングされたイベントを選択し、サンプリングを開始するために使用されます。バックグラウンド制御を実行する場合、コマンド ライン opcontrol [-start] [-stop] [–dump] を使用して opcontrol を呼び出すことができます。このオプション (プロファイリング デーモン) を制御すると、サンプリングの開始と停止、およびデーモンのメモリからディスクへのサンプルのインポートが可能になります。サンプリング時、oprofile バックグラウンド モジュールは内部バッファに大量のサンプルを保存します。ただし、ディスクに書き込まれた (またはインポートされた) サンプルのみを分析できます。ディスクへの書き込みはコストがかかる可能性があるため、oprofile はこの操作を定期的にのみ実行します。その結果、テストを実行して oprofile で分析した後、結果がすぐに得られず、バッファーがバックグラウンドでディスクに書き込まれるまで待つ必要がある場合があります。これは、プロファイリングをすぐに開始したい場合にイライラする可能性があるため、opcontrol コマンドを使用して、oprofile バックエンドの内部バッファからディスクへのサンプルのインポートを無効にすることができます。これにより、テスト完了後すぐにパフォーマンス調査を開始できます。
表 2-18 では、バックグラウンド操作の制御を可能にする opcontrol プログラム オプションについて説明します。
デフォルトでは、oprofile は、実行しているプロセッサーとコアにとって適切な特定の頻度でイベントを選択します。ただし、デフォルトのイベントよりも多くのイベントを監視できます。
イベントをリストして選択すると、opcontrol [-list-events] [-event=:name:count:unitmask:kernel:user:] コマンド ラインを使用して opcontrol が呼び出されます。
イベントの説明を使用すると、どのイベントをサンプリングするか、そのイベントをサンプリングする頻度、およびサンプリングをカーネル空間で行うか、ユーザー空間で行うか、またはその両方で行うかを選択できます。表 2-19 では、サンプリング用にさまざまなイベントを選択できる opcontrol コマンド ライン オプションについて説明します。
サンプルを収集して保存した後、oprofile は、収集されたサンプルを表示できる別のツール opreport を提供します。opreport の呼び出しコマンド ラインは次のとおりです。 opreport [-r] [-t] 一般に、opreport はすべてのシステムによって収集されたサンプルと、これらのサンプルを生成した実行可能プログラム (カーネルを含む) を表示します。サンプル数が最も多い実行可能スレッドが最初にランク付けされ、次にサンプルを持つすべての実行可能スレッドが続きます。
一般的なシステムでは、大部分のサンプルを含む少数の実行可能スレッドがリストの先頭にありますが、多数の実行可能スレッドは少数のサンプルしか提供しません。この状況に対して、opreport ではしきい値を設定でき、サンプル数のパーセンテージがしきい値以上である実行可能スレッドのみを表示できます。同時に、opreport は実行可能なスレッドの表示順序を逆にすることもでき、サンプル数が最も多いスレッドが最後に表示されます。こうすることで、最も重要なデータが最後に表示されるため、画面上でスクロールすることがなくなります。表 2-20 では、サンプル出力の形式をカスタマイズできる opreport コマンドライン オプションについて説明します。
繰り返しますが、oprofile は複雑なツールであり、指定されたオプションは oprofile の基本機能のみです。後続の章では、oprofile の詳細な機能について学習します。
2.2.8.2 使用例
oprofile は非常に強力なツールですが、インストールが少し難しいです。付録 B では、いくつかの主要な Linux ディストリビューションに oprofile をインストールして実行する方法を読者にガイドします。opprofile を使用するには、まず分析に従ってセットアップする必要があります。リスト 2.21 に示す最初のコマンドは、opcontrol コマンドを使用して、非圧縮カーネル イメージがどこにあるかを oprofile ツールキットに伝えます。oprofile は、サンプルをカーネル内の正確な関数に割り当てることができるように、このファイルの場所を知る必要があります。
現在のカーネルへのパスを設定したら、分析を開始できます。リスト 2.22 のコマンドは、デフォルト イベントでサンプリングを開始するように oprofile に指示します。このイベントはプロセッサによって異なりますが、現在のプロセッサの場合、このイベントは CPU CLK_UNHALTED です。このイベントは、プロセッサが停止していない限り、すべての CPU サイクルをサンプリングします。233869 は、233869 個のイベントごとに、プロセッサによって実行されている命令がサンプリングされることを意味します。
サンプリングが開始されたので、サンプリング結果を分析したいと思います。リスト 2.23 では、レポート ツールを使用してシステム内で何が起こっているかを調べます。opreport は、これまでに分析された内容を報告します。
分析は短期間継続していますが、サンプルが見つからないことが opreport に示された場合、分析は停止します。これは、opreport コマンドがディスク上のサンプルを検索するのに対し、oprofile デーモンはサンプルをメモリに保存し、定期的にディスクにダンプするために発生します。opreport からサンプル リストをリクエストすると、ディスク上でサンプル リストが見つからないため、サンプルが見つからなかったと報告されます。この問題を軽減するには、opcontrol に dump オプションを追加することで、バックグラウンド プログラムにサンプルを即座にダンプさせることができます (リスト 2.24 に示すように、このコマンドを使用すると、収集されたサンプルを表示できます)。
サンプルをディスクにダンプした後、リスト 2.25 に示すように、oprofile にレポートを作成するよう再度要求します。今回も結果が出ました。レポートには、サンプルが収集されたプロセッサに関する情報と、プロセッサが監視するイベントの種類に関する情報が含まれます。次に、レポートはイベントの発生数を降順に並べ替え、イベントが発生した実行可能ファイルをリストします。Linux カーネルが総クロックの 50%、emacs が 14%、libc が 12% を占めていることがわかります。実行可能ファイルをさらに深く掘り下げて、どの関数が常に使用しているかを判断できます。これについては第 4 章で説明します。
opprofile を開始したとき、opcontrol が選択したデフォルトのイベントを使用しました。各プロセッサには、監視できる非常に豊富なイベントのセットがあります。リスト 2.26 では、opcontrol に、特定の CPU で利用可能なすべてのイベントをリストするよう依頼しています。このリストは非常に長いですが、CPU_CLK UNHALTED に加えて、DATA_MEM_REFS と DCU_LINES_IN も監視できることがわかります。これらはメモリ サブシステムによって引き起こされるストレージ イベントであり、後続の章で説明します。
監視対象のイベントを指定する必要があるコマンドは少し面倒に思えますが、幸いなことに、oprofile のグラフィカル コマンド oprof_start を使用して、グラフィカルにサンプリングを開始および停止することもできます。これにより、コマンドラインで監視したいイベントを指定する正確な方法を理解する必要がなく、必要なイベントをグラフィカルに選択できるようになります。図 2-3 に示す op_control の例では、DATA_MEM_REFS イベントと L2_LD イベントの両方を監視することを oprofile に伝えます。DATA_MEM_REFS イベントは、どのアプリケーションが大量のメモリ サブシステムを使用しているか、どのアプリケーションが L2 キャッシュを使用しているかを知ることができます。このプロセッサに特有の点として、そのハードウェアにはサンプリングに使用できるカウンタが 2 つしかないため、同時に使用できるイベントは 2 つだけです。oprofile のグラフィカル インターフェイスを使用してサンプルを収集した後、データを分析できるようになります。リスト 2.27 に示すように、サイクルを監視するときに使用されるのと同様の形式で、収集したサンプルの分析を表示するように opreport に依頼します。この例では、libmad ライブラリがシステム全体のデータ メモリ アクセスの 31% を占め、メモリ サブシステムの最大のユーザーとなっていることがわかります。
opreport によって提供される出力には、サンプリングされたイベントを含むすべてのシステム ライブラリと実行可能プログラムが表示されます。すべてのイベントがログに記録されるわけではないことに注意してください。これは、サンプリングを行っており、実際にログに記録されるのはイベントのサブセットだけであるためです。特定のライブラリまたは実行可能ファイルがパフォーマンスの問題である場合、コストのかかるイベントが何度も発生する可能性が高いため、通常、これは問題にはなりません。サンプリングがランダムな場合、これらのコストが高いということは、最終的にはイベントもサンプリング コードによってキャプチャされることを意味します。
2.3 この章の概要
この章では、CPU 使用率に関するシステム レベルのパフォーマンス メトリックに焦点を当てます。これらのメトリックは主に、特定のアプリケーションではなく、オペレーティング システムとマシンがどのように実行されているかを示します。この章では、sar や vmstat などのパフォーマンス ツールを使用して、実行中のシステムからシステム レベルのパフォーマンス情報を抽出する方法を説明します。これらのツールは、システムの問題を診断する際の防御の第一線となります。これらは、システムのパフォーマンスや、どのサブシステムまたはアプリケーションにストレスがかかっているかを判断するのに役立ちます。次の章では、システム全体のメモリ使用量を分析できるシステム レベルのパフォーマンス ツールに焦点を当てます。