この記事は主に、CPU 関連のパフォーマンス指標、一般的な CPU パフォーマンスの問題と解決策を理解するのに役立ちます。
元のアドレス: https://zhuanlan.zhihu.com/p/180402964
システム負荷平均
序章
システム負荷平均: 実行可能または中断不可能な状態にあるプロセスの平均数です。
実行可能なプロセス: CPU を使用しているプロセス、または CPU の使用を待機しているプロセス
中断不可能な状態のプロセス: 何らかの IO アクセスを待機しており、通常はハードウェアと対話しており、中断できません (中断できない理由は、システム データの一貫性を保護し、データ読み取りエラーを防ぐためです)
システム負荷平均の表示
まず、top コマンドは次のようにプロセスの実行ステータスをチェックします。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10760 user 20 0 3061604 84832 5956 S 82.4 0.6 126:47.61 Process
29424 user 20 0 54060 2668 1360 R 17.6 0.0 0:00.03 **top**プログラムのステータス ステータス プロセスはRで実行可能、無中断動作はD（詳細は先頭の続きの説明で説明します）
トップシステム負荷平均を表示:
top - 13:09:42 up 888 days, 21:32, 8 users, load average: 19.95, 14.71, 14.01
Tasks: 642 total, 2 running, 640 sleeping, 0 stopped, 0 zombie
%Cpu0 : 37.5 us, 27.6 sy, 0.0 ni, 30.9 id, 0.0 wa, 0.0 hi, 3.6 si, 0.3 st
%Cpu1 : 34.1 us, 31.5 sy, 0.0 ni, 34.1 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st
...
KiB Mem : 14108016 total, 2919496 free, 6220236 used, 4968284 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6654506 avail Memここでの負荷平均は、過去 1 分間、5 分間、および 15 分間のシステムのシステムボトルネック負荷を示します。
稼働時間表示システムのボトルネック負荷
[root /home/user]# uptime
13:11:01 up 888 days, 21:33, 8 users, load average: 17.20, 14.85, 14.10CPUコア情報の表示
平均システム負荷は CPU コアの数と密接に関係しており、次のコマンドを使用して現在のマシンの CPU 情報を表示できます。
lscpu CPU 情報を表示します。
[root@Tencent-SNG /home/user_00]# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
...
L1d cache: 32K
L1i cache: 32K
L2 cache: 4096K
NUMA node0 CPU(s): 0-7 // NUMA架构信息cat /proc/cpuinfo を実行して、各 CPU コアの情報を表示します。
processor : 7 // 核编号7
vendor_id : GenuineIntel
cpu family : 6
model : 6
...システム負荷平均が高くなる理由
一般に、システム負荷平均が高いほど、CPU 使用率が高くなります。しかし、それらは必ずしも関連しているわけではありません。CPU 集中型のコンピューティング タスクが増えると、一般に平均システム負荷が増加しますが、IO 集中型タスクが増えると、平均システム負荷も増加します。ただし、この時点での CPU 使用率は必ずしも高いわけではありません。多くのプロセスが中断できない状態にあるため、非常に低い可能性があり、CPU スケジューリングを待機していると平均システム負荷も増加します。
したがって、システムの平均負荷が非常に高くても、CPU 使用率がそれほど高くない場合は、システムが IO ボトルネックに遭遇したかどうかを検討し、IO の読み取りおよび書き込み速度を最適化する必要があります。
したがって、システムがCPUボトルネックに陥っているかどうかは、CPU使用率やシステムのボトルネック負荷と合わせてチェックする必要があります（もちろん、他にも比較チェックする必要がある指標はあります。説明は後述します）。
ケースのトラブルシューティング
ストレスは、システム プレッシャーを適用し、システムにストレス テストを行うためのツールです。ストレス ツールを使用して CPU にプレッシャー テストを行うと、CPU の問題を特定してトラブルシューティングを行うことができます。
yum install stress // 安装stress工具ストレスコマンドは次を使用します。
// --cpu 8：8个进程不停的执行sqrt()计算操作
// --io 4：4个进程不同的执行sync()io操作（刷盘）
// --vm 2：2个进程不停的执行malloc()内存申请操作
// --vm-bytes 128M：限制1个执行malloc的进程申请内存大小
stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10sここでは主にCPU、IO、プロセスが多すぎる問題を検証します。
CPUの問題のトラブルシューティング
tress -c 1 を使用して高い CPU 負荷をシミュレートし、次のコマンドを使用して負荷の変化を観察します。
uptime : uptime を使用して、現時点のシステム負荷を表示します。
# -d 参数表示高亮显示变化的区域
$ watch -d uptime
... load average: 1.00, 0.75, 0.39mpstat : mpstat -P ALL 1 を使用して、1 秒あたりの各 CPU コアの変更情報を表示します。全体は top と似ています。利点は、1 秒あたりのデータ (カスタム) を出力して、データ変更の観察を容易にし、最後に平均データを出力できることです。
13:14:53 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
13:14:58 all 12.89 0.00 0.18 0.00 0.00 0.03 0.00 0.00 0.00 86.91
13:14:58 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
13:14:58 1 0.40 0.00 0.20 0.00 0.00 0.20 0.00 0.00 0.00 99.20上記の出力から、現在のシステム負荷が増加しており、コアの 1 つがフルで実行されており、主にユーザー モード タスクを実行しており、現時点ではそのほとんどがビジネス タスクであると結論付けることができます。したがって、現時点では、どのプロセスがシングルコア CPU をフル稼働させているのかを確認する必要があります。
pidstat : pidstat -u 1 を使用して、現在のシステム プロセスと CPU データを 1 秒ごとに出力します。
13:18:00 UID PID %usr %system %guest %CPU CPU Command
13:18:01 0 1 1.00 0.00 0.00 1.00 4 systemd
13:18:01 0 3150617 100.00 0.00 0.00 100.00 0 stress
...top : もちろん、最も便利な方法は、top コマンドを使用して負荷を表示することです。
top - 13:19:06 up 125 days, 20:01, 3 users, load average: 0.99, 0.63, 0.42
Tasks: 223 total, 2 running, 221 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14.5 us, 0.3 sy, 0.0 ni, 85.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16166056 total, 3118532 free, 9550108 used, 3497416 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6447640 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3150617 root 20 0 10384 120 0 R 100.0 0.0 4:36.89 stressこの時点で、ストレスが高い CPU を占有していることがわかります。
IOのトラブルシューティング
Stress -i 1 を使用して IO ボトルネック問題をシミュレートします。つまり、同期ディスク操作を無限ループで実行します。uptime : uptime を使用して、この時点のシステム負荷を表示します。
$ watch -d uptime
..., load average: 1.06, 0.58, 0.37mpstat : このときのIO消費量を確認しますが、実はここのCPUは基本的にsys、つまりシステム消費していることが分かりました。
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.33 0.00 12.64 0.13 0.00 0.00 0.00 0.00 0.00 86.90
Average: 0 0.00 0.00 99.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 1 0.00 0.00 0.33 0.00 0.00 0.00 0.00 0.00 0.00 99.67IOが発生しない問題:
iowait が発生できない問題は、この場合のストレスが sync() システム コールを使用し、その機能がバッファ メモリをディスクにリフレッシュすることであるためです。新しくインストールされた仮想マシンの場合、バッファーは比較的小さい可能性があり、大きな IO プレッシャーを生成できないため、そのほとんどがシステム コールによって消費されます。したがって、システムの CPU 使用率のみが増加することがわかります。解決策は、stress-ng -i 1 --hdd 1 --timeout 600 (--hdd は一時ファイルの読み取りおよび書き込みを意味します) など、より豊富なオプションをサポートする次世代のストレスであるtress-ng を使用することです。
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.25 0.00 0.44 26.22 0.00 0.00 0.00 0.00 0.00 73.09
Average: 0 0.00 0.00 1.02 98.98 0.00 0.00 0.00 0.00 0.00 0.00pidstat : 同上(省略)
CPU IO の増加により、システムの平均負荷が増加することがわかります。pidstat を使用して、どのプロセスが IO の増加を引き起こしているかを調べます。
top : ここでの top の使用は、依然として表示する最も包括的なパラメータであり、ストレスが IO の増加を引き起こす原因であると結論付けることができます。
pidstat には iowait オプションがありません。CentOS のデフォルトの sysstat が古すぎる可能性があり、使用するには 11.5.5 以降のバージョンにアップグレードする必要があります。
プロセスが多すぎる場合のトラブルシューティング
プロセスが多すぎる問題は非常に特殊で、システムが CPU の動作能力を超える多くのプロセスを実行すると、CPU を待機するプロセスが発生します。24 プロセスの実行をシミュレートするには、stress -c 24 を使用します (私の CPU は 8 コアです) uptime : 現時点でのシステム負荷を表示するには、uptime を使用します。
$ watch -d uptime
..., load average: 18.50, 7.13, 2.84mpstat : 同上(省略)
pidstat : 同上(省略)
この時点のシステム処理は深刻な過負荷になっており、平均負荷は18.50にも達していることがわかります。
top : top コマンドを使用して、現時点で実行状態にあるプロセスの数を表示することもできます。この数が大きい場合は、システムが実行中であり、実行を待機しているプロセスが多すぎることを意味します。
要約する
上記の問題と解決策を通じて、次のことが結論付けられます。
平均負荷が高くなるのは、CPU 負荷の高いプロセスが原因である可能性があります
平均負荷が高いことは、必ずしも CPU 使用率が高いことを意味するわけではなく、I/O がビジーであることを意味する場合もあります。
負荷が高いことがわかった場合は、mpstat や pidstat などのツールを使用して、負荷の原因の分析を支援できます。
概要ツール: mpstat、pidstat、top、uptime
CPUコンテキストスイッチ
CPU コンテキスト: CPU は、各タスクを実行するときに、タスクがどこにロードされ、実行が開始されるかを知る必要があります。つまり、システムは、CPU レジスタを含む、そのための CPU レジスタとプログラム カウンタ (Program Counter、PC) を事前に設定する必要があります。これを CPU コンテキストと呼びます。
CPU コンテキストの切り替え: CPU コンテキストの切り替えでは、最初に前のタスクの CPU コンテキスト (つまり、CPU レジスタとプログラム カウンタ) を保存し、次に新しいタスクのコンテキストをこれらのレジスタとプログラム カウンタにロードし、最後にプログラム カウンタが指す新しい位置にジャンプして新しいタスクを実行します。
CPU コンテキスト スイッチング:プロセス コンテキスト スイッチング、スレッド コンテキスト スイッチング、および割り込みコンテキスト スイッチングに分けられます。
プロセスコンテキストスイッチ
ユーザー モードからカーネル モードへの切り替えは、システム コールを通じて行う必要があります。システム コールでは、プロセス コンテキストの切り替え (特権モードの切り替え) が発生し、ユーザー モードに戻るときにもコンテキストの切り替えが発生します。
一般に、各コンテキスト スイッチには数十ナノ秒から数マイクロ秒の CPU 時間がかかります。スイッチが多い場合、レジスタ、カーネル スタック、仮想メモリなどのリソースの保存と復元に CPU 時間が浪費されやすく、平均的なシステム負荷の増加にもつながります。
Linux は各 CPU の準備完了キューを維持し、優先順位と CPU 待機時間に従って R 状態のプロセスを並べ替え、実行に最も必要な CPU プロセスを選択します。ここでプロセスを実行するには、プロセス コンテキストの切り替えのタイミングが関係します。
プロセス タイム スライスが使い果たされました。
プロセスのシステム リソースが不足しています (メモリ不足)。
プロセスはアクティブにスリープします。
優先度の高い処理が実行されます。
ハード割り込みが発生します。
スレッドコンテキストスイッチ
スレッドとプロセス:
プロセスにスレッドが 1 つしかない場合、プロセスとスレッドは等しいと考えることができます。
プロセスに複数のスレッドがある場合、これらのスレッドは仮想メモリやグローバル変数などの同じリソースを共有します。これらのリソースは、コンテキストの切り替え中に変更する必要はありません。
スレッドにはスタックやレジスタなどの独自のプライベート データもあり、コンテキストの切り替え中にこれらも保存する必要があります。
したがって、スレッド コンテキストの切り替えには 2 つの状況が含まれます。
異なるプロセスのスレッド、この状況はプロセスの切り替えに相当します。
共通処理のスレッド切り替えは、スレッドプライベートデータやレジスタなどの非共有データを切り替えるだけで済みます。
割り込みコンテキストスイッチ
割り込み処理は、プロセスの通常のスケジューリングと実行を中断し、代わりに割り込みハンドラーを呼び出してデバイス イベントに応答します。他のプロセスを中断する場合、中断が終了した後もプロセスを元の状態から再開できるように、プロセスの現在の状態を保存する必要があります。
同じ CPU の場合、割り込み処理の優先順位がプロセスよりも高いため、割り込みコンテキストの切り替えがプロセス コンテキストの切り替えと同時に発生することはありません。割り込みは通常のプロセスのスケジューリングと実行を中断するため、ほとんどの割り込みハンドラーは実行をできるだけ早く終了できるように短く簡潔になっています。
システムコンテキストスイッチの表示
vmstat : このツールは、システムのメモリ、CPU コンテキストの切り替え、および割り込み時間を表示できます。
// 每隔1秒输出
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 157256 3241604 5144444 0 0 20 0 26503 33960 18 7 75 0 0
17 0 0 159984 3241708 5144452 0 0 12 0 29560 37696 15 10 75 0 0
6 0 0 162044 3241816 5144456 0 0 8 120 30683 38861 17 10 73 0 0cs : 1 秒あたりのコンテキスト スイッチの数。
in : 1 秒あたりの割り込み数。
r : レディキューの長さ、CPU を実行中または待機しているプロセス。
b : ハードウェアとの対話など、中断できないスリープ状態にあるプロセスの数。
pidstat : pidstat -w オプションを使用して、特定のプロセスのコンテキスト スイッチの数を表示します。
$ pidstat -w -p 3217281 1
10:19:13 UID PID cswch/s nvcswch/s Command
10:19:14 0 3217281 0.00 18.00 stress
10:19:15 0 3217281 0.00 18.00 stress
10:19:16 0 3217281 0.00 28.71 stressこのうち、cswch/s と nvcswch/s は、自発的コンテキスト切り替えと非自発的コンテキスト切り替えを表します。
自発的コンテキスト切り替え: プロセスが必要なリソースを取得できないことによって引き起こされるコンテキスト切り替えを指します。たとえば、I/O やメモリなどのシステム リソースが不足している場合、自発的なコンテキスト切り替えが発生します。
非自発的コンテキストスイッチング: タイムスライスの期限切れなどの理由により、システムによってプロセスが強制的にスケジュールされたために発生するコンテキストスイッチングを指します。たとえば、多数のプロセスが CPU をめぐって競合している場合、不随意なコンテキスト スイッチが発生する傾向があります。
ケースのトラブルシューティング
ここでは、sysbench ツールを使用してコンテキスト切り替え問題をシミュレートします。
まず、vmstat 1 を使用して、現在のコンテキスト切り替え情報を表示します。
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 514540 3364828 5323356 0 0 10 16 0 0 4 1 95 0 0
1 0 0 514316 3364932 5323408 0 0 8 0 27900 34809 17 10 73 0 0
1 0 0 507036 3365008 5323500 0 0 8 0 23750 30058 19 9 72 0 0次に、sysbench --threads=64 --max-time=300 スレッドを実行して、タスクを実行する 64 スレッドをシミュレートします。このとき、vmstat 1 でコンテキスト スイッチング情報を再度確認します。
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 318792 3385728 5474272 0 0 10 16 0 0 4 1 95 0 0
1 0 0 307492 3385756 5474316 0 0 8 0 15710 20569 20 8 72 0 0
1 0 0 330032 3385824 5474376 0 0 8 16 21573 26844 19 9 72 0 0
2 0 0 321264 3385876 5474396 0 0 12 0 21218 26100 20 7 73 0 0
6 0 0 320172 3385932 5474440 0 0 12 0 19363 23969 19 8 73 0 0
14 0 0 323488 3385980 5474828 0 0 64 788 111647 3745536 24 61 15 0 0
14 0 0 323576 3386028 5474856 0 0 8 0 118383 4317546 25 64 11 0 0
16 0 0 315560 3386100 5475056 0 0 8 16 115253 4553099 22 68 9 0 0次のことがはっきりと観察できます。
この時点で現CSとINが大幅に増えました。
sy+us の CPU 使用率が 90% を超えています。
r レディキューの長さが 16 に達し、CPU コアの数を 8 つ超えます。
cs コンテキスト切り替えの問題を分析する
pidstat を使用して、現在の CPU 情報と特定のプロセス コンテキストの切り替え情報を表示します。
// -w表示查看进程切换信息，-u查看CPU信息，-t查看线程切换信息
$ pidstat -w -u -t 1
10:35:01 UID PID %usr %system %guest %CPU CPU Command
10:35:02 0 3383478 67.33 100.00 0.00 100.00 1 sysbench
10:35:01 UID PID cswch/s nvcswch/s Command
10:45:39 0 3509357 - 1.00 0.00 kworker/2:2
10:45:39 0 - 3509357 1.00 0.00 |__kworker/2:2
10:45:39 0 - 3509702 38478.00 45587.00 |__sysbench
10:45:39 0 - 3509703 39913.00 41565.00 |__sysbenchしたがって、多くの sysbench スレッドに多くのコンテキスト スイッチがあることがわかります。
割り込み問題の解析
システムの watch -d cat /proc/softirqs および watch -d cat /proc/interrupts を表示して、システムのソフト割り込みとハード割り込み (カーネル割り込み) を表示できます。ここでは主に /proc/interrupts を観察します。
$ watch -d cat /proc/interrupts
RES: 900997016 912023527 904378994 902594579 899800739 897500263 895024925 895452133 Rescheduling interruptsここでは、アイドル状態の CPU が目覚めて新しいタスクの実行をスケジュールすることを示す再スケジュール割り込み (RES) の数が増加していることがわかります。
要約する
自発的なコンテキストの切り替えが増えており、プロセスがリソースを待っていることや、I/O などの他の問題が発生した可能性があることを示しています。
さらに多くの非自発的なコンテキスト スイッチがあり、プロセスが強制的にスケジュールされている、つまりすべてのプロセスが CPU をめぐって競合していることを示しており、CPU が実際にボトルネックになっていることを示しています。
割り込みの数が増加する場合は、CPU が割り込みハンドラーによって占有されていることを意味するため、/proc/interrupts ファイルを参照して特定の割り込みタイプを分析する必要があります。
CPU使用率
システム負荷とコンテキスト切り替え情報に加えて、CPU の問題を最も直感的に示す指標は CPU 使用率情報です。Linux は、/proc 仮想ファイル システムを通じてシステムの内部ステータス情報をユーザー コントロールに提供します。/proc/stat は CPU およびタスク情報の統計です。
$ cat /proc/stat | grep cpu
cpu 6392076667 1160 3371352191 52468445328 3266914 37086 36028236 20721765 0 0
cpu0 889532957 175 493755012 6424323330 2180394 37079 17095455 3852990 0 0
...ここでの各列の意味は次のとおりです。
user (通常は us と省略されます) は、ユーザー モードの CPU 時間を表します。以下のナイスタイムは含まれませんが、ゲストタイムは含まれますのでご了承ください。
nice (通常は ni と省略されます) は、低優先度のユーザー モード CPU 時間を表します。つまり、プロセスの nice 値が 1 ～ 19 の間に調整された場合の CPU 時間を表します。ここで、nice に指定できる値の範囲は -20 ～ 19 であることに注意してください。値が大きいほど、優先度は低くなります。
system (sys と略されることが多い) は、カーネル モードの CPU 時間を表します。
idle (多くの場合 id と省略されます) は、アイドル時間を表します。I/O の待機時間 (iowait) は含まれないことに注意してください。
iowait (多くの場合 wa と省略されます) は、I/O を待機している CPU 時間を表します。
irq (hi と略されることが多い) は、ハード割り込みを処理する CPU 時間を表します。
Softirq (si と略されることが多い) は、Softirq を処理する CPU 時間を表します。
スチール (通常は st と省略されます) は、システムが仮想マシンで実行されているときに他の仮想マシンが占有する CPU 時間を表します。
ゲスト (通常はゲストと省略されます) は、仮想化を通じて他のオペレーティング システムを実行する時間、つまり仮想マシンを実行する CPU 時間を表します。
guest_nice (gnice と略されることが多い)。仮想マシンが低い優先順位で実行されている時間を表します。
ここでは、top、ps、pidstat などのツールを使用してこれらのデータを簡単にクエリでき、CPU 使用率が高いプロセスを簡単に確認できます。ここでは、これらのツールを使用してプロセスを事前に特定できますが、問題の特定の原因を検索し続けるには、他の方法が必要です。
ここでは、perf top を使用してホットスポット データを簡単に表示したり、perf Record を使用して現在のデータを保存し、後で perf レポートで表示したりできます。
CPU使用率のトラブルシューティング
CPU 使用率の問題とトラブルシューティングのアイデアの概要は次のとおりです。
ユーザー CPU と Nice CPU が高い場合は、ユーザー モード プロセスがより多くの CPU を占有していることを意味するため、プロセスのパフォーマンスの問題のトラブルシューティングに重点を置く必要があります。
システムの CPU が高いことは、カーネル モードがより多くの CPU を占有していることを示しているため、カーネル スレッドまたはシステム コールのパフォーマンスの問題のトラブルシューティングに重点を置く必要があります。
I/O 待機 CPU の値が高く、I/O の待機時間が比較的長いことを示しているため、システム ストレージに I/O の問題があるかどうかを確認することに重点を置く必要があります。
ソフト割り込みとハード割り込みの数が多いということは、ソフト割り込みまたはハード割り込みの処理プログラムがより多くの CPU を占有していることを示しているため、カーネル内の割り込みサービス プログラムのチェックに重点を置く必要があります。
CPU トラブルシューティング ルーチン
CPU使用率
CPU 使用率には主に次の側面が含まれます。
ユーザーの CPU 使用率。ユーザー モードの CPU 使用率 (ユーザー) と低優先度のユーザー モードの CPU 使用率 (ニース) を含み、CPU がユーザー モードで実行されている時間の割合を示します。ユーザーの CPU 使用率が高い場合は、通常、アプリケーションがビジー状態であることを示します。
システム CPU 使用率。CPU がカーネル モードで実行されている時間の割合を示します (割り込みを除く)。システムの CPU 使用率が高い場合は、コアがビジーであることを示します。
I/O を待機している CPU 使用率 (一般に iowait とも呼ばれます) は、I/O を待機している時間の割合を示します。iowait が高い場合は、通常、システムとハードウェア デバイス間の I/O 対話時間が比較的長いことを示します。
ソフト割り込みとハード割り込みの CPU 使用率は、カーネルがそれぞれソフト割り込みハンドラーとハード割り込みハンドラーを呼び出す時間の割合を示します。使用率が高いということは、通常、システムの停止回数が多いことを示しています。
仮想化環境で使用されるスチール CPU 使用率 (スチール) とゲスト CPU 使用率 (ゲスト) に加えて、それらはそれぞれ、他の仮想マシンによって占有されている CPU 時間の割合と、ゲスト仮想マシンを実行している CPU 時間の割合を表します。
平均負荷
これはシステム全体の負荷を反映しており、過去 1 分間、過去 5 分間、過去 15 分間の平均負荷を表示できます。
コンテキストスイッチ
コンテキストスイッチングは 2 つのメトリクスに焦点を当てます。
リソースの取得失敗による自発的なコンテキスト切り替え。
システム強制スケジューリングによって引き起こされる不随意のコンテキスト切り替え。
CPUキャッシュヒット率
CPUのアクセス速度はメモリアクセスに比べてはるかに速いため、CPUがメモリにアクセスする際には必然的にメモリの応答を待つことになります。両者の速度差を調整するために登場したのがCPUキャッシュ（多値キャッシュ）です。CPU キャッシュ ヒット率が高いほど、パフォーマンスが向上します。次のツールを使用して、CPU キャッシュ ヒット率、ツール アドレス、プロジェクト アドレス perf-toolsを表示できます。
# ./cachestat -t
Counting cache functions... Output every 1 seconds.
TIME HITS MISSES DIRTIES RATIO BUFFERS_MB CACHE_MB
08:28:57 415 0 0 100.0% 1 191
08:28:58 411 0 0 100.0% 1 191
08:28:59 362 97 0 78.9% 0 8
08:29:00 411 0 0 100.0% 0 9
08:29:01 775 20489 0 3.6% 0 89
08:29:02 411 0 0 100.0% 0 89
08:29:03 6069 0 0 100.0% 0 89
08:29:04 15249 0 0 100.0% 0 89
08:29:05 411 0 0 100.0% 0 89
08:29:06 411 0 0 100.0% 0 89
08:29:07 411 0 3 100.0% 0 89
[...]要約する
性能指標チェックツール経由（CPU関連）
パフォーマンス インジケーター ツールの説明負荷平均稼働時間
topuptime は、単純に最近の期間の平均負荷を表示します。
トップ その他のインジケーターを表示 CPU 使用率 vmstat
mpstat
上
サール
/proc/stat
top、vmstat、mpstat は現在の状態を動的に表示することしかできませんが、sar は履歴を表示できます。
/proc/stat は、他のパフォーマンス ツールのプロセス CPU 使用率のデータ ソースです。
pidstat
ps
hトップ
上に
top と ps はプロセス CPU をソート モードで表示できますが、pidstat はソートして表示できません
htop と atop は、あらゆる種類のデータを異なる色で表示し、より直感的です システム コンテキストの切り替え vmstat は、現時点でのコンテキストの切り替え、実行ステータス、および中断できないプロセスの数を表示します プロセス コンテキストの切り替え pidstat は、プロセス コンテキストの切り替え情報を含む多くの項目を表示します ソフト割り込み top
/proc/softirqs
mpstattop はソフト割り込みの CPU 使用率を表示できます
/proc/softirqs および mpstat は、各 CPU ハード割り込みに関する累積情報を表示できます vmstat
/proc/interruptsvmstat 割り込みの総数情報を表示します。
/proc/interrupts 各 CPU コアのさまざまな割り込みの累積情報ネットワーク dstat を表示します。
サール
tcpdumpdstat と sar は、ネットワーク全体の送受信状況をより詳細に表示します。
tcpdump 提供动态抓取数据包的能力IOdstat、sar2 者都提供了详细的 IO 整体情况CPU 信息/proc/cpuinfo
lscpu都可以查看 CPU 信息系统分析perf
execsnoopperf 分析各种内核函数调用、热点函数信息
execsnoop 监控短时进程
根据工具查性能指标(CPU 相关)
性能工具CPU 性能指标uptime5、10、15 分钟内的平均负载展示top平均负载、运行队列、CPU 各项使用率、进程状态和 CPU 使用率htoptop 增强版，以不同颜色区分不同类型进程，展示更直观atopCPU、内存、磁盘、网络资源全访问监控，十分齐全vmstat系统整体 CPU 使用率、上下文切换次数、中断次数，还包括处于运行(r)和不可中断状态(b)的进程数量pidstat进程、线程(-t)的每个 CPU 占用信息，中断上下文切换次数/proc/softirqs展示每个 CPU 上的软中断类型及次数/proc/inerrupts展示每个 CPU 上的硬中断类型及次数ps每个进程的状态和 CPU 使用率pstree进程的父子关系展示dstat系统整体 CPU 使用率(以及相关 IO、网络信息)sar系统整体 CPU 使用率，以及使用率历史信息strace跟踪进程的系统调用perfCPU 性能事件分析，例如：函数调用链、CPU 缓存命中率、CPU 调度等execsnoop短时进程分析
CPU 问题排查方向
有了以上性能工具，在实际遇到问题时我们并不可能全部性能工具跑一遍，这样效率也太低了，所以这里可以先运行几个常用的工具 top、vmstat、pidstat 分析系统大概的运行情况然后在具体定位原因。
top 系统CPU => vmstat 上下文切换次数 => pidstat 非自愿上下文切换次数 => 各类进程分析工具(perf strace ps execsnoop pstack)
top 用户CPU => pidstat 用户CPU => 一般是CPU计算型任务
top 僵尸进程 => 各类进程分析工具(perf strace ps execsnoop pstack)
top 平均负载 => vmstat 运行状态进程数 => pidstat 用户CPU => 各类进程分析工具(perf strace ps execsnoop pstack)
top 等待IO CPU => vmstat 不可中断状态进程数 => IO分析工具(dstat、sar -d)
top 硬中断 => vmstat 中断次数 => 查看具体中断类型(/proc/interrupts)
top 软中断 => 查看具体中断类型(/proc/softirqs) => 网络分析工具(sar -n、tcpdump) 或者 SCHED(pidstat 非自愿上下文切换)CPU 问题优化方向
性能优化往往是多方面的，CPU、内存、网络等都是有关联的，这里暂且给出 CPU 优化的思路，以供参考。
程序优化
基本优化：程序逻辑的优化比如减少循环次数、减少内存分配，减少递归等等。
编译器优化：开启编译器优化选项例如gcc -O2对程序代码优化。
算法优化：降低苏研发复杂度，例如使用nlogn的排序算法，使用logn的查找算法等。
异步处理：例如把轮询改为通知方式
多线程代替多进程：某些场景下多线程可以代替多进程，因为上下文切换成本较低
缓存：包括多级缓存的使用（略）加快数据访问
系统优化
CPU 绑定：绑定到一个或多个 CPU 上，可以提高 CPU 缓存命中率，减少跨 CPU 调度带来的上下文切换问题
CPU 独占：跟 CPU 绑定类似，进一步将 CPU 分组，并通过 CPU 亲和性机制为其分配进程。
优先级调整：使用 nice 调整进程的优先级，适当降低非核心应用的优先级，增高核心应用的优先级，可以确保核心应用得到优先处理。
为进程设置资源限制：使用 Linux cgroups 来设置进程的 CPU 使用上限，可以防止由于某个应用自身的问题，而耗尽系统资源。
NUMA 优化：支持 NUMA 的处理器会被划分为多个 Node，每个 Node 有本地的内存空间，这样 CPU 可以直接访问本地空间内存。
中断负载均衡：无论是软中断还是硬中断，它们的中断处理程序都可能会耗费大量的 CPU。开启 irqbalance 服务或者配置 smp_affinity，就可以把中断处理过程自动负载均衡到多个 CPU 上。
参考
极客时间：Linux 性能优化实战
更多干货尽在腾讯技术，官方微信/QQ交流群已建立，交流讨论可加：Journeylife1900、711094866（备注腾讯技术） 。
推荐阅读
Linux CPU性能优化方法
