CPUあたりの負荷平均が0-1（または0-1024）であることがわかっています。たとえば、使用量の多いクアッドコアの負荷平均は4.0以上です。 （例：仕事が多い場合）私はそれが100以上のように大きくなることができることを知っています。
また、これはCPU使用率（つまり100％を超える可能性があります）ではなく、CPUのパフォーマンスを反映していることも理解しています。
ところで、なぜシステムのCPU数に自動的に分割されないのですか？
これは歴史的な質問に近いです。なぜ：
(load)
いいえ：
(load) / (# of cores)
すべてのCPUを考慮しますか？なぜCPUごとに？すべてのCPUに対してこれを持つことは、最初にシステムにCPUがどれだけあるかを調べ、次に数字を分割して意味のある数字を取得する必要があることを意味します。これは、さまざまなシステムを管理する際の面倒な作業です。
これはLinux用です。
答え1
負荷平均は、CPU時間を使用するか、CPU時間を待つプロセス以上をカバーします。また、中断のない省電力状態（通常はディスクI / Oを待つことを意味）のプロセスもカバーしています。
CPUの数で割ると、奇妙な（しばしば役に立たない）数が出ます。システムに単一のディスクで待機している4つのコアと7つのプロセスがある場合、負荷平均は定義に従って1.75に収束します。しかし、この数字は何の意味もありません。 I / Oバインディングワークロードを測定するときにコア数で割ると、意味のない結果が得られます。
もちろん、CPUを待っている平均プロセス数と中断することなく、省電力モードの平均プロセス数を計算できます。これら2つの数の合計は、既存の負荷平均です。場合によっては、CPUが待機しているプロセスの平均数をCPUの数で割った値も意味のある数値になることがあります。
ただし、無中断スリープモードの平均プロセス数をディスク数で割ることは意味がありません。結局のところ、無停電スリープモードであっても、どのディスクが待っているかを意味するわけではなく、ディスクが仮想デバイスに含まれるべきかどうかはわかりません。
答え2
あなたは言っていませんが、私はこれがLinux用であると仮定しています。 CPU固有の記録理由を探していますが、質問によれば、実際のカーネルジョブキューではなく、CPU使用率の点で負荷平均がまだ考慮されていることがわかりました。各 CPU の使用率を表示するには、top などのプログラムで CPU 使用率を表示できます。
4つのCPUコアがある場合、これはコアが4つのCPUに対して4つのジョブを同時にキューに入れることができることを意味します。そのため、4つのバッグといくつかの手荷物を運ぶことができます。カーネルが実行中のジョブの後にさらにジョブをキューに追加すると、数値は4より大きくなります。 0〜100％の範囲はまったくなく、作業負荷に応じて必要に応じてその数値が高くなります。失敗したネットワークファイルシステムのIO作業バックログが原因で、負荷が15,000以上に増加することがわかりました。実際、この数字は1024に達した後にリセットされます。