Linux性能モニタリング:CPU(二)

Linux性能モニタリング:CPU(二)
CPUの占有は主にどのようなリソースがCPUの上で実行されているかに依存し、例えばファイルをコピーするのは通常CPUの占有量が少ない.大部分の仕事はDMA(DirectMemory Access)によって完成されるため、コピーが完了した後に中断してCPUにコピーが完了したことを知らせるだけである.科学計算は通常多くのCPUを占有し、大部分の計算作業はCPU上で完成しなければならない.メモリ、ハードディスクなどのサブシステムは一時的なデータ記憶作業しかしない.CPUのパフォーマンスを監視し理解するには、割り込み、プロセススケジューリング、プロセスコンテキストの切り替え、実行可能なキューなど、オペレーティングシステムの基本的な知識が必要です.例を用いてこれらの概念と彼らの関係を簡単に紹介して、CPUはとても罪がなくて、苦労して恨んでいるアルバイトの子で、毎時毎刻すべて仕事がしています(プロセス、スレッド)、そして自分で1枚の仕事のリスト(実行可能なキュー)を持っていて、ボス(プロセスのスケジューリング)が彼が何をするべきかを決めて、彼はボスとコミュニケーションしてボスの考えを得てそして直ちに自分の仕事(コンテキストの切り替え)を調整する必要があります.一部の仕事が终わったら、すぐにボスに报告(中断)しなければならないので、アルバイト(CPU)は自分のやるべき仕事をする以外に、コミュニケーションと报告に多くの时間と精力を費やしています.
CPUも1种のハードウェアの资源で、いかなるその他のハードウェアの设备と同じにドライバと管理のプログラムを必要として使うことができて、私达はカーネルのプロセスのスケジューリングをCPUの管理のプログラムと见なすことができて、CPUの资源を管理して分配して、合理的にプロセスを手配してCPUを奪い取って、そしてどの进程がCPUを使うべきで、どのプロセスが待つべきかを决めます.オペレーティングシステムのカーネル内のプロセススケジューリングは主に2種類のリソースをスケジューリングするために使用されます:プロセス(またはスレッド)と割り込み、プロセススケジューリングは異なるリソースに異なる優先度を割り当て、優先度が最も高いのはハードウェア割り込みで、次いでカーネル(システム)プロセスで、最後にユーザープロセスです.各CPUは、実行可能なスレッドを格納するための実行可能なキューを維持しています.スレッドはスリープ状態(blockedがIOを待っている)か実行可能状態であり,CPUの現在の負荷が高すぎて新しい要求が絶えないとプロセススケジューリングが一時的に対応できない場合があり,このときスレッドを実行可能キューに一時的に置かざるを得ない.VpSeeはここで性能モニタリングについて議論しますが、性能については言及していませんが、これらの概念は性能モニタリングと何の関係がありますか?関係が重大である.もしあなたがボスなら、アルバイトの効率(性能)をどうチェックしますか?私たちは一般的に、アルバイトをサボっているかどうかを判断します.

アルバイトはどれだけの任務を受け入れ、完成したかをボスに報告した(中断).

アルバイトとボスは各仕事の仕事の進度を交流し、協議する(コンテキスト切替);

アルバイトのリストがいっぱい並んでいるのではないでしょうか.

アルバイトの効率はどうなのか、サボっているのか(CPU利用率).

今、アルバイトをCPUに変えて、私たちはこれらの重要なパラメータを見ることができます:中断、コンテキストの切り替え、実行可能なキュー、CPUの利用率を監視することができます.

ベースライン

上一篇Linux性能监视:(一)性能监视の前にベースラインを知る必要があると述べましたが、CPU性能を监视するベースラインは何ですか?通常、私たちのシステムは以下の目標に達することを期待しています.

CPU利用率は、CPUが100%利用率を有する場合、65%-70%User Time、30%-35%System Time、0%-5%Idle Timeというバランスに達するべきである.

コンテキスト切替、コンテキスト切替はCPU利用率と結びつけて見るべきで、上のCPU利用率のバランスを保つことができれば、大量のコンテキスト切替は受け入れられる.

はキューを実行できます.各実行可能キューには1～3個以上のスレッド(プロセッサごと)があるべきではありません.たとえば、デュアルプロセッサシステムの実行可能キューには6個以上のスレッドがあるべきではありません.

vmstat

vmstatはシステム全体の性能を表示する小さなツールであり、コンパクトでheavyの場合でも良好に動作し、時間間隔で連続的な性能データを収集することができる.

				$ 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  1    140 2787980 336304 3531996  0    0     0   128 1166 5033  3  3 70 25  0
 0  1    140 2788296 336304 3531996  0    0     0     0 1194 5605  3  3 69 25  0
 0  1    140 2788436 336304 3531996  0    0     0     0 1249 8036  5  4 67 25  0
 0  1    140 2782688 336304 3531996  0    0     0     0 1333 7792  6  6 64 25  0
 3  1    140 2779292 336304 3531992  0    0     0    28 1323 7087  4  5 67 25  0
		

パラメータの説明:

r、実行可能キューのスレッド数、これらのスレッドはいずれも実行可能状態であるが、CPUは一時的に使用できない.

b、blockedされたプロセス数は、IOリクエストを待っている.

in、処理された割り込み数

cs、システム上でコンテキスト切替を行っている数

us、ユーザーがCPUを占有する割合

sys、カーネルと割り込みがCPUを占有する割合

waは、実行可能なすべてのスレッドがblockedされた後、IOを待っているとき、CPUがアイドルである割合

である.

id、CPUが完全に空いている割合

2つの現実の例を挙げて実際に分析してみましょう.

				$ 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
 4  0    140 2915476 341288 3951700  0    0     0     0 1057  523 19 81  0  0  0
 4  0    140 2915724 341296 3951700  0    0     0     0 1048  546 19 81  0  0  0
 4  0    140 2915848 341296 3951700  0    0     0     0 1044  514 18 82  0  0  0
 4  0    140 2915848 341296 3951700  0    0     0    24 1044  564 20 80  0  0  0
 4  0    140 2915848 341296 3951700  0    0     0     0 1060  546 18 82  0  0  0
		

上のデータからいくつかの点がわかります.

interrupts(in)は非常に高く、context switch(cs)は比較的低く、このCPUが絶えずリソースを要求していることを示している.

user time(us)は80%以上を維持し、コンテキスト切替が低い(cs)ことは、あるプロセスがCPUを占領している可能性があることを示している.

run queue(r)はちょうど4つです.

				$ 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
14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0
17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0
20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0
17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0
16  0    140 2904580 341912 3952108  0    0     0     0 1055 9808 34 65  1  0  0
		

上のデータからいくつかの点がわかります.

context switch(cs)はinterrupts(in)よりずっと高く、カーネルがプロセスを切り替えざるを得ないことを示しています.

さらに観察すると、system time(sy)は高く、user time(us)は低く、高周波度のコンテキスト切替(cs)を加えて、実行中のアプリケーションが大量のシステム呼び出し(system call)を呼び出したことを示している.

run queue(r)は14スレッド以上であり、このテストマシンのハードウェア構成(クアッドコア)に従い、12スレッド以内に保つべきである.

mpstat

mpstatはvmstatと同様で、異なるのはmpstatが複数のプロセッサのデータを出力できることであり、以下の出力はCPU 1とCPU 2が基本的に役に立たず、システムがより多くのタスクを処理するのに十分な能力を持っていることを示している.

				$ mpstat -P ALL 1
Linux 2.6.18-164.el5 (vpsee) 	11/13/2009

02:24:33 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
02:24:34 PM  all    5.26    0.00    4.01   25.06    0.00    0.00    0.00   65.66   1446.00
02:24:34 PM    0    7.00    0.00    8.00    0.00    0.00    0.00    0.00   85.00   1001.00
02:24:34 PM    1   13.00    0.00    8.00    0.00    0.00    0.00    0.00   79.00    444.00
02:24:34 PM    2    0.00    0.00    0.00  100.00    0.00    0.00    0.00    0.00      0.00
02:24:34 PM    3    0.99    0.00    0.99    0.00    0.00    0.00    0.00   98.02      0.00
		

ps

どのようにあるプログラムを見て、プロセスはどれだけのCPU資源を占有しましたか?次は、1台のサーバでのFirefoxの動作です.現在、2人のユーザーのみがFirefoxを使用しています.

				$ while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'firefox'; sleep 1; done

  PID  NI PRI %CPU PSR COMMAND
 7252   0  24  3.2   3 firefox
 9846   0  24  8.8   0 firefox
 7252   0  24  3.2   2 firefox
 9846   0  24  8.8   0 firefox
 7252   0  24  3.2   2 firefox