LinuxでのハイパースレッディングによるCPU負荷測定
マルチコアハイパースレッディング対応CPUの実際の使用法を取得するにはどうすればよいですか？
たとえば、4つの仮想コアを表現する2コアCPUについて考えてみましょう。
仮想コアの1つのコアが完全に使用されているため、シングルスレッドのワークロードはtopで100％として表示されます。 CPUとtopは、4つの実際のコアがあるように、期待どおりに機能します。
ただし、2つのスレッドを使用すると、事態は厄介になります。すべてが正常に機能する場合、それらは2つの実際のコアにバランスが取れているため、200％の使用率が得られます。100％の2倍と2つのアイドル仮想コアであり、使用可能なすべてのCPUパワーを使用しています。 。私には大丈夫らしい。
ただし、2つのスレッドが単一の実際のコアで実行される場合、100％の2倍を使用しているように表示され、仮想コアの使用率は200％になります。しかし、実際には、1つのコアが2つのスレッドでパワーを共有し、合計CPUパワーの半分しか使用していません。
したがって、topで示される使用数は、合計CPUワークロードの測定には使用できません。
また、ハイパースレッディングが実際のコアで2つの仮想のバランスをどのように取っているのか疑問に思います。 2つのスレッドのサイクル数が異なる場合、仮想コアは「適応」して、実際の負荷が異なっていても、両方が100％の負荷を示すようになりますか？
OracleのMartinTegtmeierは、昨年について興味深いブログ投稿を書いています： https://blogs.Oracle.com/solaris/cpu-utilization-of-multi-threaded-architectures-explained-v2
短い答え。ハイパースレッディングは、全体的なCPU使用率/ CPUアイドル率を報告するtopの機能を実際に混乱させます。
最悪の場合、コアあたり100％の使用率で2つのスレッドを実行する2コア4仮想コアCPUは、CPUをほぼ飽和させる可能性があります。 （実行ポートの使用状況によって異なります。CPUでまったく異なるコンピューティングリソースを使用するスレッドのみが、現在のスレッドのパフォーマンスに影響を与えることなく実行できます。）ただし、この場合、topは50％のアイドル状態を報告します。
コアの使用率は、システムの負荷とは大きく異なります。コア使用率は、コアが何かを計算したり、命令を待ったりしている量を示しているだけです。 CPUが何かを計算している任意の時間に対応する100％にすることができます。
ただし、負荷は別のものです。負荷は、通常、プロセスがリソースを待機する必要があるかどうかを判断するために測定されます。プロセスがリソースを待機していない場合は、非常にパフォーマンスの高いシステムが表示されます。ただし、システムの速度は遅いがCPU使用率が低い場合があります。これは通常、一部のプロセスがリソースを待機していて、CPUを解放していないことを意味します。この種のシナリオでは、CPU使用率が高くなることはありませんが、システムがその容量をはるかに超えている可能性があります。
Linuxシステムでは、負荷平均はシステムの全体的なパフォーマンスを測定するための計算値です。負荷平均の値は、並列コンピューティングリソース、具体的にはコアと比較する必要があります。したがって、4つの物理コアを備えたシステムの負荷平均が4以上であれば、一部のプロセスはリソースを待機すると安全に言えます。
CPU使用率が100％か10％かは重要ではありません。負荷平均は200または300にもなる可能性があり、これらの場合、システムはほとんど応答しなくなります。
通常の動作状態では、サーバーの平均負荷は長期間にわたってコアの数を超えてはなりません。私の意見では、短いスパイクは重要ではありません。 w出力に表示される3つの数値はload avです。 1/5/15分間。
私の意見では、上記の答えはどれも満足のいくものではありません。
次のリンクで参照している記事は、この質問に答えるのに適していると思います。 http://perfdynamics.blogspot.ch/2014/01/monitoring-cpu-utilization-under-hyper.html ==
見積もり：
HTの背後にある考え方は、現在実行中のアプリが停止したときに別のアプリケーションスレッドを実行できるようにすることです。分岐予測の誤り、パイプラインのバブルなどが原因です。これを可能にするには、別のポートまたはASレジスタが必要です。そのレジスタは、HTが有効になるとOSから見えるようになります。ただし、OS（およびフードチェーンから使用しているパフォーマンスツールまで）は、プロセッサ容量の2倍、つまり各ASポートで100％のCPUが利用可能であると考えています。
しかし、内部的にはまだoneの実行ユニットしかありません。HTが有効になる前に開始した単一の物理コアです。違いは、2つのASポート間で何らかの方法で共有されていることです。シングルコアが2つのポート間でどのように切り替えられるかは非常に複雑ですが、ポーリングされたキューの観点から最も簡単に理解できます。私はGCaPクラスでその詳細レベルに入ります。
私が持っているベストケースのテスト測定では、各HTポートがビジー状態になるのは平均で75％を超えることはなく、OSによって予想される200％の総容量の150％になることもありません。私が以前に言及した「不足している」50％の容量は幻想です。 Intelは、一般的なアプリケーションでは120％から130％の範囲の何かが期待できると主張しています。
実際、オペレーティングシステムは各仮想コアで100％に達することができると確信していますが、それは間違いありません。私はちょうどした：
mvn clean install -DskipTests -T 5
そして、8つの仮想コアと4つの物理コアがすべて100％のCPU使用率になったことを保証できます。そして、私は間違いなく私のマシンに8つのコアを持っていません。
簡単に言うと、合計CPU負荷が100％を超える場合、物理コアを正確に100％使用して、最大で、おそらく非常に正確に、次のように想定できます。つまり、物理CORE1をオペレーティングシステムのCPU1とCPU2に分割している場合、CPU 1では合計使用率が50％、CPU 2では合計使用率が50％になります。これは、実際の生活ではおそらくそのCPUに100％の合計使用量のプレッシャーをかけます。あなたはそれを使い果たしました。
しかしもちろん、そのシステム監視ツールのオペレーティングシステムは、それがあなたに幻想を売り込んでいることを知りません。オペレーティングシステムとリソースの管理方法の観点から、これら2つの仮想コアのそれぞれがまだ50％アイドル状態であると考えられるため、実行するタスクがさらにある場合は、それらを2つのコアに均一に分散しようとします。 。したがって、CPU使用率が100％を超えると、CPU使用率の期間中に、CPUのタイムスライスを取得するための変更がなかった、その期間に実行するキューに入れられた作業が常に存在します。最終的にはそれを取得しますが、実行がスケジュールされていても、実際には実行されていないスレッドが常に存在します。
ありがとう