パフォーマンス分析LinuxサーバーのCPU使用率

CPUメトリック

1.インデックス範囲

1.1ユーザーモードのCPU使用率+システムモードのCPU使用率

妥当な値:60〜85%。マルチユーザーシステムでus + sy時間が85%を超えると、プロセスが実行キューで待機するのに時間がかかる場合があり、応答時間とビジネススループットが低下します。大きすぎる、それは多くのCPU時間を消費し、他のソフトウェアとハ​​ードウェアの要因をさらに分析する必要があるユーザープロセスがあることを意味します; syが大きすぎる、システム管理に多くの時間が費やされたことを示し、特定のシステム内のサブシステムにはボトルネックがあり、他のソフトウェアおよびハードウェアの要因をさらに分析する必要があります。

1.2わ(待つ)

参照値:waの値が25%未満および25%を超える場合は、ディスクサブシステムのバランスが適切に取れていないか、ディスクを集中的に使用するワークロードの結果である可能性があります。ディスクまたはその他のIに問題がある可能性があります。システムの/o。iostat/SAR-Cコマンドを使用してさらに分析できます。

1.3アイドル(アイドル)

参照値:40より大きい、rが4より大きい場合、idが40より小さい場合は、CPUの負荷が非常に大きいことを意味します。

1.4 r

参照値:4未満、キューが4より大きい場合、システムのCPUまたはメモリに問題がある可能性があることを示します。rが4より大きい場合、idが40より小さい場合は、 CPUは高負荷です。キューが長くなると、CPUスケジューリングの実行を待機しているキュー内のプロセスが費やす時間が長くなります

1.5CPUのボトルネックを判断する方法

非常に遅い応答時間(遅い応答時間)

CPUアイドル時間はゼロです(ゼロパーセントアイドルCPU)

ユーザーがCPU時間を占有しすぎる(ユーザーCPUの割合が高い)

システムが高すぎるとCPU時間が占有されます(システムCPUの割合が高い)

長い間、非常に長い実行中のプロセスキューがあります(時間の経過とともに大きな実行キューサイズが維持されます)

2.CPU使用率を確認する方法

2.1topコマンドを使用して表示します

データは/ proc / statファイルから取得されます
ここに画像の説明を挿入

%us =(User time + Nice time)/CPU时间*100%
%sy=(System time + Hardirq time +Softirq time)/ CPU时间*100%
%id=(Idle time)/CPU时间*100%
%ni=(Nice time)/CPU时间*100%
%wa=(Waiting time)/CPU时间*100%
%hi=(Hardirq time)/CPU时间*100%
%si=(Softirq time)/CPU时间*100%
%st=(Steal time)/CPU时间*100%

注:デフォルトでは、topコマンドは3秒ごとに更新されます。top -d0.1やtop-d 0.01など、top -d <更新間隔>を使用して更新頻度を指定することもできます。topを実行するときに、「s」キーを押して時間間隔を変更することもできます。

2.2vmstatを使用した表示
ここに画像の説明を挿入

rは実行キューのサイズを表し、bはIO待機のためにブロックされたスレッドの数を表し、inは割り込みの数を表し、csはコンテキストスイッチの数を表します。

2.3その他の表示方法

Iostat、sar -q、sar –u等

[記事の利点]技術交換グループを追加するには、C / C ++ Linuxサーバー開発/アーキテクト学習資料が必要です:960994558私は、より良いと思ういくつかの学習本を整理し、大きな工場からの質問にインタビューし、興味深いプロジェクトと人気のある技術教育をその中で共有するビデオ資料(C / C ++、Linux、Nginx、ZeroMQ、MySQL、Redis、fastdfs、MongoDB、ZK、ストリーミングメディア、CDN、P2P、K8S、Docker、TCP / IP、coroutine、DPDKなどを含む)、必要がありますあなたはそれを自分で追加することができます!ここに画像の説明を挿入

3.CPUの紹介

3.1カーネル内の時間

HZは、システムクロックが1秒間にクロック割り込みを送信する回数です。カーネルをコンパイルする前にHZを構成できるため、次のコマンドを使用して現在のシステムクロック割り込み頻度を表示できますuname -r。cat / boot / config- | grep CONFIG_HZ

ティックは、システムクロックの各「ティック」の時間であり、その値は(1 / HZ)秒です。つまり、2つの連続するクロック割り込み間の時間間隔です。

jiffiesは、システムが起動してからのティック数をカウントするために使用されます。つまり、この変数の値は、システムクロックがクロック割り込みを生成するたびに1回増加します。

3.2CPU時間構成

CPUの動作時間は、ユーザーモード時間、システムモード時間、アイドルモード時間の3つの部分で構成されます。具体的な構成は次のとおりです。

CPU時間Dユーザー時間、システム時間、ナイス時間、アイドル時間、待機時間、ハードワーク時間、ソフト時間、スチール時間

空闲态时间==idle time

用户态时间==user time+ Nice time。

内核态时间==system time+ Hardirq time+ Softirq time。

user time。指CPU在用户态执行进程的时间。

system time。指CPU在内核运行的时间。

nice time。指系统花费在调整进程优先级上的时间。

idle time。系统处于空闲期,等待进程运行。

waiting time。指CPU花费在等待I/O操作上的总时间,与blokced相似。

steal time。指当前CPU被强制(involuntary wait )等待另外虚拟的CPU处理完毕时花费的时间,此时 hypervisor 在为另一个虚拟处理器服务。

Softirq time 、Hardirq time。分别对应系统在处理软硬中断时候所花费的CPU时间。

3.3ユーザーモードのCPU使用率

%usr。ユーザーモードで費やされたCPU時間の割合を示します。ユーザーがCPUを使用するプロセスには、cpuが通常のユーザープロセスを実行し、cpuがnicedプロセスを実行し、cpuがリアルタイムプロセスを実行します。Linuxプロセスは、ユーザーモードまたはシステム(カーネル)モードで実行できます。プロセスがカーネルコードで実行されている場合はカーネルモードと呼ばれ、プロセスがユーザー自身のコードを実行している場合はユーザーであると言われます。モード。ユーザーモードで実行すると、プロセスは独自のアプリケーションコードで実行され、計算の実行、メモリの管理、変数の設定にカーネルリソースを必要としません。

3.4システムモードのCPU使用率

カーネルプロセス(kprocs)およびカーネルリソースにアクセスする必要があるその他のプロセスによって消費されるCPUリソースを含む、システムモードで費やされたCPU時間の割合を示します。システムでCPUを使用するプロセスには、システム呼び出しおよびI / O管理(割り込みとドライバー)、メモリ管理(ページングとスワッピング)に使用され、プロセス管理(コンテキストの切り替えとプロセスの開始)に使用されます。プロセスにカーネルリソースが必要な場合は、システム呼び出しを実行する必要があるため、システムモードに切り替えます。利用可能です。

3.5%wa(待つ)

ローカルディスクI / OとNFSのロードを一時停止するディスクのCPUのアイドル率を示します。これはI / Oを待機しているプロセスのためにアイドル状態になっているCPUの比率です。I/ Oには主に次のものが含まれます。ブロックI / O 、I / O、raw I / O、VMページング/スワピン。待機の実行中に未処理のディスクI / Oが少なくとも1つある場合、イベントはI / O待機時間として分類されます。ディスクへのI / O要求により、要求が完了するまで呼び出しプロセスがブロック(またはスリープ)します。 。プロセスのI / O要求が完了すると、プロセスは実行キューに配置されます。I / Oが迅速に完了すると、プロセスはより多くのCPU時間を使用できます。

3.6%id(アイドル)

上記のWIO以外のアイドル状態は、ローカルディスクI / OがないときにCPUがアイドル状態または待機している時間の割合を示します。実行するスレッドがない場合(実行キューが空の場合)、システムはwaitと呼ばれるスレッドをディスパッチします。これはidlekprocと呼ばれます。psレポートにこのスレッドの合計時間が長いことが示されている場合は、他のスレッドを実行する準備ができていない、またはCPUでの実行を待機していない期間があることを示しています。したがって、システムはほとんどアイドル状態であるか、新しいタスクを待機しています。

3.7 r(runq-sz)

実行中のプロセスキューの長さ。実行可能な状態のプロセス数のサイズについては、これらのプロセスはメモリ内で準備ができています

4.コンセプト紹介

4.1ユーザーモード+カーネルモード

一般的に、CPUで実行されているプロセスは、ユーザーモードとカーネルモードの両方で2つの動作モードを持つことができます(つまり、プロセスはユーザーモードとカーネルモードでそれぞれ動作しますが、カーネルモードで動作しているのはこのプロセスです。プロセスが切り替えられない限り)。通常、オペレーティングシステムは仮想アドレス空間をユーザー空間とカーネル空間に分割します。たとえば、x86プラットフォーム上のLinuxシステムの仮想アドレス空間は0x00000000 0xffffffff、最初の3GB(0x00000000 0xbfffffff)はユーザー空間、最後はユーザー空間です。 1GB(0xc0000000〜0xffffffff)がカーネル空間です。ユーザープログラムはユーザースペースに読み込まれ、ユーザーモードで実行されます。カーネル内のデータにアクセスしたり、カーネルコードにジャンプして実行したりすることはできません。これにより、カーネルを保護できます。プロセスが不正なアドレスにアクセスした場合、カーネルとシステム全体の安定性に影響を与えることなく、多くてもこのプロセスはクラッシュします。CPUが割り込みまたは例外を生成すると、割り込みまたは例外サービスの都市西部にジャンプするだけでなく、モードをユーザーモードから特権モードに自動的に切り替えるため、割り込みまたは例外サーバープログラムはカーネルにジャンプできます。実行用のコード。実際、カーネル全体はさまざまな割り込みハンドラーと例外ハンドラーで構成されています。つまり、通常の状況では、プロセッサはユーザープログラムをユーザーモードで実行し、割り込みまたは例外が発生した場合、プロセッサは特権モードに切り替えてカーネルプログラムを実行し、次にユーザーモードに戻って続行します。割り込みや例外を処理した後、ユーザープログラムを実行する(例:ユーザープロセスA)カーネルシステムコールを呼び出して現在のクロックティックカウントを取得するユーザープロセスAのシステムコール命令を実行すると、IPなどの現在のレジスタステータス現在のユーザープロセスのCSが保存され、カーネルスペース(つまり、カーネルコード領域)にジャンプします。)Yingのようなシステムコール関数を実行して、現在のクロックティックを取得します。実行後、IRET命令でプロセスAに戻り(つまり、対応するレジスタへの入力時に保存された情報をリセット)、CS:EIPアドレスからプロセスAの命令を実行します。

プロセスが作成されると、プロセスの制御ブロックの作成に加えて、プロセスのカーネルスタックもカーネル内に作成されます。プロセスがシステムコール(fopen()やopen()など)を介してカーネルに入った後)、プロセッサは特権レベルにあります。最上位(レベル0)のカーネルコードで実行されます。プロセスがカーネル状態の場合、実行されたカーネルコードは、現在のプロセスのカーネルスタックを使用し、コンテキストを指します。プロセスの。

カーネルモードの権限は、ユーザーモードの権限よりも高くなっています。

ユーザーレベル。システムユーザーは、実行中のアプリケーションやシステムコマンドなど、オペレーティングシステムと対話できます。ユーザーレベルは、システム呼び出しインターフェイス(カーネルレベル)を介してカーネルレベルにアクセスします。オペレーティングシステムは自動的にいくつかの機能を実行し、それらは主にハードウェア上で動作します

4.2プロセスのスケジューリング

プロセスがCPUを占有して、実際に実行状態になるようにする場合は、プロセス全体でスケジュールする必要があります。プロセススケジューリングメカニズムには、主にスケジューリング方法、スケジューリングタイミング、およびスケジューリング戦略が含まれます。

1.1。スケジューリング方法

Linuxカーネルのスケジューリング方法は、基本的に「プリエンプティブ優先」方法を採用しています。つまり、プロセスが任意であるかどうかに関係なく、特定の条件下(タイムスライスの枯渇やI / Oの待機など)でユーザーモードで実行されている場合です。 )、コアは一時的に操作を奪い、他のプロセスが操作に入るようにスケジュールすることができます。ただし、プロセスがカーネルモードで実行するように切り替えられると、上記の制限なしで実行が継続され、ユーザーモードに戻るまでプロセスのスケジューリングは行われません。

Linuxシステムのスケジューリング戦略は、基本的にUnixの優先度ベースのスケジューリングを継承します。つまり、コアはシステム内の各プロセスの優先度を計算し、その優先度はCPUを使用する権利を取得するプロセスの適格性を反映します。つまり、優先度の高いプロセスには実行の優先度が与えられます。コアは、プロセスレディキューから最も優先度の高いプロセスを選択し、それにCPUタイムスライスを割り当てて、動作させます。実行中のプロセス中、現在のプロセスの優先度は時間とともに低下し、「負のフィードバック」効果を実現します。一定期間後、元の下位レベルのプロセスは比較的「アップグレード」され、実行される可能性があります。すべてのプロセスの優先度が0になると、すべてのプロセスの優先度が再計算されます。

2.2。スケジューリング戦略

Linuxシステムは、さまざまなタイプのプロセスに対して3つの異なるスケジューリング戦略、つまりSCHED_FIFO、SCHED_RR、およびSCHED_OTHERを提供します。

SCHED_FIFOは、リアルタイムプロセスに適しています。時間要件が比較的強く、各実行に必要な時間は比較的短いです。このプロセスの実行開始がスケジュールされたら、CPUを自発的に解放するか、優先されるまで実行する必要があります。上位プロセスは、実行されるまで実行をプリエンプトします。

SCHED_RRは「タイムスライスローテーション方式」に対応しており、実行ごとに長時間を要するリアルタイムプロセスに適しています。実行中のプロセスにはタイムスライス(200ミリ秒など)が割り当てられます。タイムスライスが使い果たされると、CPUは別のプロセスによってプリエンプトされ、プロセスは同じ優先度キューの最後に送り返されます。SCHED_OTHERは、インタラクティブなタイムシェアリングプロセスに適した従来のUnixスケジューリング戦略です。このタイプのプロセスの優先度は、2つの要因によって異なります。1つの要因は、プロセスの残り時間の割り当てです。プロセスが割り当てられた時間を使い果たした場合、対応する優先度は0です。もう1つは、継承されるプロセス優先度番号niceです。 Unixシステムから優先順位番号が小さいほど、優先順位は高くなります。

niceの値の範囲は19〜20です。ユーザーはniceコマンドを使用して、プロセスのnice値を設定できます。ただし、一般ユーザーは正の値しか設定できないため、優先度を積極的に下げます。特権ユーザーのみがniceの値を負の数に設定できます。プロセスの優先順位は、上記の2つの合計です。コアは、ユーザーモードプロセスの優先度を動的に調整します。このように、プロセスは、タスクの作成から完了まで、複数のフィードバックループを通過する必要があります。プロセスが再度実行されるようにスケジュールされると、最後のブレークポイントから実行が続行されます。リアルタイムプロセスの場合、優先度の値は(1000 +正の値を設定)であるため、少なくとも1000です。したがって、リアルタイムプロセスの優先度は、他のタイプのプロセスの優先度よりも高くなります。さらに、時間の割り当てと適切な値は、リアルタイムプロセスの優先度とは関係ありません。準備完了状態のシステムにリアルタイムプロセスがある場合、すべてのリアルタイムプロセスが完了するまで、非リアルタイムプロセスの実行をスケジュールすることはできません。非リアルタイムプロセスは、 CPU。

バックグラウンドコマンド(gcc f1.c&などのコマンドの最後にアンパサンドが付いている)はバックグラウンドプロセス(バックグラウンドジョブとも呼ばれます)に対応し、バックグラウンドプロセスの優先度はインタラクティブなものよりも低くなります(フォアグラウンド)プロセス。したがって、バックグラウンドプロセスは、現在システムで実行されている対話型プロセスがない場合にのみ実行されるようにスケジュールされます。バックグラウンドプロセスは、多くの場合、バッチで実行するようにスケジュールされています。

3.3。スケジュールのタイミング

コアプロセスのスケジューリングのタイミングには、次の状況があります。

(1)現在のプロセスは、システムコールnanosleep()またはpause()を呼び出して、自身をスリープ状態にし、一定期間CPUを使用する権利を積極的に放棄します。

(2)プロセスが終了し、CPUの使用が永久に放棄されます。

(3)クロック割り込みハンドラの実行中に、現在のプロセスが長時間継続して実行されていることがわかりました。

(4)スリープ状態のプロセスをウェイクアップすると、ウェイクアップされたプロセスは現在のプロセスよりも実行する資格があることがわかります。

(5)プロセスは、システムコールを実行することにより、スケジューリング戦略を変更したり、自身の優先度(niceコマンドなど)を減らしたりして、即時のスケジューリングを引き起こします。

4.4。スケジューリングアルゴリズム

プロセススケジューリングのアルゴリズムは、頻繁なスケジューリング中のシステムオーバーヘッドを削減するために、比較的単純である必要があります。Linuxがプロセススケジューリングを実行すると、最初にレディキュー内のすべてのプロセスが検索され、メモリ内で最も優先度の高いプロセスが選択されます。キューにリアルタイムプロセスがある場合、リアルタイムプロセスが最初に実行されます。実行するのに最も必要なプロセスが現在のプロセスでない場合、現在のプロセスは一時停止され、プログラムカウンタやCPUレジスタなど、そのシーンに関連するすべてのマシン状態が保存され、シーンが再開されます。選択したプロセス。

4.3ユーザーレベルのスレッドとカーネルレベルのスレッド

Linux、FreeBSD、Solarisなどの多くのUnixライクなシステムでは、プロセスは常にオペレーティングシステムのカーネル呼び出しの最小単位であり、プログラム開発にもマルチプロセスモデルが採用されています。その後、スレッドの概念が導入されました。スレッドには2つの概念があります。

ユーザーレベルのスレッド(ULT)。アプリケーションプロセスは、スレッドライブラリを使用して作成および管理します。カーネルにスレッドを実装しません。ユーザーモードでマルチスレッドをシミュレートするだけです。オペレーティングシステムコアに依存せず、オペレーティングシステムカーネルはマルチスレッドの存在。

カーネルレベルのスレッド(KLT)。カーネルでサポートされるスレッドまたは軽量プロセスとも呼ばれます。カーネルは、各スレッドのコアスペースにスレッド制御ブロックを設定して、スレッドID、レジスタ値、ステータス、優先度、およびスレッドの他の情報を登録します。作成など、スレッドに対するすべての操作、キャンセル、および切り替えはすべて、システム関数呼び出しを介してカーネル内の対応する処理プログラムによって完了されます。カーネルは、プロセスとスレッドのコンテキスト切り替えおよびスレッド切り替えを維持します。Unixのようなシステムは、通常、プロセスの実装を変更することによって実装されます。これは不完全に使用される可能性があります。プロセス作成メソッドは、データスペースを共有するプロセスを作成します。Linuxでは、このシステム呼び出しはclone()であり、FreeBSDではrfork()です。

5.よくある誤解

5.1 CPU使用率が高いということは、CPUリソースが不十分であることを意味します

CPUカウンターが範囲内にない場合、他のリソースも原因となるため、必ずしもCPUリソースが不足しているとは限りません。たとえば、メモリが不足している場合、CPUはメモリ管理でビジー状態になります。 CPUの使用率が100%である可能性があります。

上記の欠陥は​​、議論を指摘することを歓迎します、気分が良い友人、あなたのサポートを得ることを望んでいます

おすすめ

転載: blog.csdn.net/weixin_52622200/article/details/113058528