解決策 1:
確かではありませんが、主に 1.00*n_cpu で .
負荷とは次のことを意味します。単一の CPU システムに複数のプロセスがある場合、それらは一見並列に実行されているように見えます。しかし、それは真実ではありません。実際に何が起こるか:カーネルはプロセスに 1/100 秒を与え、割り込みでその実行を中断します。そして、次の 1/100 秒を別のプロセスに渡します。
実際には、「どのプロセスが次の 1/100 秒間隔を取得する必要があるか?」という問題は、複雑なヒューリスティックによって決定されます。 タスクという名前です スケジューリング .
もちろん、ブロックされているプロセス (たとえば、ディスクから読み取るデータを待機しているプロセス) は、このタスクのスケジューリングから除外されます。
負荷の意味:現在、次の 1/100 秒の時間枠を待機しているプロセスの数。もちろん平均値です。これは、cat /proc/loadavg 内に複数の数字が表示されるためです。 .
マルチ CPU システムの状況は少し複雑です。複数の CPU があり、その時間枠を複数のプロセスに割り当てることができます。これにより、タスクのスケジューリングが少し複雑になりますが、それほど複雑ではありません。しかし、状況は同じです。
カーネルはインテリジェントで、最適な効率を得るためにシステム リソースを共有しようとしますが、それに近い状態です (小さな最適化があります。 cpu はキャッシュの考慮事項のためですが、それらは問題ではありません)。これは、負荷が 8 の場合、実際には 8 つのプロセスが次のタイム スライスを待っているためです。 8 つの CPU がある場合、これらのタイム スライスを CPU に 1 対 1 で与えることができるため、システムが最適に使用されます。
top が表示された場合 、実際に実行されているプロセスの数が驚くほど少ないことがわかります。それらは R でマークされたプロセスです。 そこの。あまりハードコアではないシステムでも、5 を下回ることがよくあります。これは、ディスクまたはネットワークからのデータを待機しているプロセスも中断されているためです (S でマークされています)。 上に）。負荷は CPU 使用率のみを示します。
ディスク負荷を測定するツールもあります。少なくとも CPU 使用率の監視として重要であるはずですが、専門のシステム管理者の世界ではあまり知られていません。
Windows ツールは、実際の CPU 数で負荷を分割することがよくあります。これにより、一部のプロの Windows システム管理者は、システム負荷をこの CPU で割った意味で使用します。彼らは正しくないので、あなたがこれを彼らに説明した後、おそらくもっと幸せになるでしょう.
マルチコア CPU は、事実上、同じシリコン チップ上の複数の CPU です。違いはありません。
ハイパースレッド化された CPU の場合、興味深い副作用があります。CPU をロードすると、ハイパースレッド化されたペアが遅くなります。しかし、これは通常のタスク スケジューリングが処理するより深いレイヤーで発生しますが、スケジューラーのプロセス移動の決定に影響を与える可能性があります (影響する必要があります)。
しかし、現在の観点 (システム負荷を決定するもの) からは、それも問題ではありません。
解決策 2:
負荷平均は、あなたが思っていることを意味するものではありません。瞬間的な CPU 使用率ではなく、実行を待機しているプロセスの数です。 通常 これは、多くのことが CPU を必要とするためですが、常にではありません。一般的な原因は、ディスクまたはネットワークの IO を待機しているプロセスです。
ps -e v を実行してみてください プロセス状態フラグを探します。
state The state is given by a sequence of characters, for example, "RWNA". The first character indicates the run state of the process:
D Marks a process in disk (or other short term, uninterruptible) wait.
I Marks a process that is idle (sleeping for longer than about 20 seconds).
L Marks a process that is waiting to acquire a lock.
R Marks a runnable process.
S Marks a process that is sleeping for less than about 20 seconds.
T Marks a stopped process.
W Marks an idle interrupt thread.
Z Marks a dead process (a "zombie").
これは ps からのものです マンページで詳細を確認できます - R および D プロセスはおそらく特に興味深いものです。
あらゆる種類の理由で負荷平均の「スパイク」が発生する可能性があるため、「このシステムはビジー状態ですか」以外の良い尺度にはなりません。負荷平均を CPU コアにマッピングすることに行き詰まっても、何の役にも立ちません。
解決策 3:
ハイパースレッディングは実際には 2 番目のコアではないため、コアが 200% になることはありませんが、特定のワークロードでは 100% を超えます。
したがって、最大負荷は約 4 から 6 の間のどこか不明です
(もちろん、特に IO を待機しているときに実行可能なプロセスを実際にカウントするため、過負荷の場合はさらに高くなる可能性があります)
解決策 4:
Linux システムでは、負荷を計算するために実行可能なキュー内のプロセスだけでなく、割り込み不可能なスリープ状態 (ウィキペディア) のプロセスもカウントされるため、多くのプロセスがディスクを待機している場合に負荷が急増します。
解決策 5:
24 コア Xeon システム (2 ソケット x 12 コア) でいくつかの実験を行いました。この場合、Linux がハイパースレッディングを設定する方法により、最大負荷は 48.0 です。
ただし、48 コアのスループットに相当するものは得られません。私が観察したことは、最初の 24 個の論理プロセッサでスループットの約 90% が得られることです。つまり、負荷が 24.0 まで実行された場合です。次に、残りの 24 個の論理プロセッサで約 10% の追加スループットが得られます (負荷は 48.0 まで実行されます)。別の考え方としては、24 コアで 48 スレッドを実行する場合、ハイパースレッディングを有効にした場合と無効にした場合で、約 10 ～ 20% のブーストが得られるということです。マーケティング担当者がほのめかしているような 100% のブーストではありません。
たとえば、この観察結果をテストする 1 つの方法は、48 スレッドを実行するプロセス (TBB またはハンドロール スレッド モデルを使用するなど) を用意し、次に実行することです
time numactl --physcpubind=0-23 ./myprocess
そして実行
time numactl --physcpubind=0-47 ./myprocess
後者は、約 10 ～ 20% 短い時間で実行できます。プロセスが高度に I/O ブロックされている場合、結果は異なる可能性があります。
前者は (各コアの) 1 つの論理プロセッサでのみスレッドを実行できるようにすることでハイパースレッディングを無効にしますが、後者は (各コアの) 2 つの論理プロセッサでスレッドを実行できるようにすることでハイパースレッディングを有効にします。
どちらの場合も、負荷は 48.0 と報告されるはずです ... ご覧のとおり、これは非常に誤解を招くものです。