「Linux CPU使用率とロードアベレージ」の編集履歴（バックアップ）一覧はこちら
追加された行は緑色になります。
削除された行は赤色になります。
ttp://www.itmedia.co.jp/enterprise/articles/0802/22/news074.html
CPU負荷の確認
http://d.hatena.ne.jp/naoya/20070222/1172116665
http://d.hatena.ne.jp/naoya/20070518/1179492085
ロードアベレージは、過去1min、5min、15minの間の実行待ちプロセス数の平均値
run queueに溜まったタスク(task_struck≒プロセス)の数を、ハードウェアクロックの割り込み毎に数え上げ、単位時間での平均値を出している。
-> 実装 kernel/timer.c
static inline void calc_load(unsigned long ticks)
static unsigned long count_active_tasks(void)
ロードアベレージ→/proc/loadavg
top や sar がデフォルトで示すCPU使用率はCPU数(コア数)で割り算をしている
ロードアベレージは割り算をしていない
http://oshiete.goo.ne.jp/qa/1480201.html
Ｑ：
CPU使用率とロードアベレージ
Linuxのtopコマンド等で出力されるCPU使用率とロードアベレージの違いを教えてください。
また、ロードアベレージをCPU使用率に換算することは可能でしょうか？
可能であれば方法を教えてください。
Ａ：
ロードアベレージは、最も簡単に説明すると、実行プロセス数の平均だ。説明によっては実行待ちプロセス数や実行可能プロセス数となっているが、正確には実行プロセス数(実行中プロセス数＋実行可能プロセス数)だ。つまり、I/O待ちのプロセスはカウントされない。
ここで、たとえば、1秒間に10回実行プロセス数をカウントすると、1分間では600回カウントする。カウントした時に、毎回3、4、5あたりをうろう ろしていると、平均値としては4ぐらいになる。これがロードアベレージだ。正確に、Linuxが1秒に何回カウントしているかは知らんが、どちらにせよ
(カウントした時のロード数1＋...カウントした時のロード数n)/カウント数
という計算式になるので、1分に何回カウントしたかはあまり重要な数字ではない(もちろん1分に1回やら数回やらというのは困るが)。ロードの平均値を取っているのでロードアベレージだ。
ロードアベレージは、「システム負荷率」と表現される事が多い。負荷ってCPU使用率じゃないのと思うかも知れないが、例えば、CPUが1個のマシンに おいて、CPU使用率が常に100%の状態が1時間続いたと仮定して、その間ロードアベレージが常に1だったとすると、システムの負荷は0という事にな る。なぜかと言うと1個のプロセスが常にCPUを占有している状態だからで、それは1個のプロセスが理想的にCPUを使いつづけた状態だからだ。
つまり、ロードアベレージが負荷と表現されるのは、「CPUが割り当てられたらすぐ実行できるのに実行できないプロセスの割合」だからかな。
別のモデルを考える。I/Oを行わず、常にCPUによる処理をしている3つのプロセスがあり、システムプロセスを含め、それ以外のプロセスは一切動作し ないとすると、ロードアベレージは常に3になる。CPUが1個だと3、2個だと3、3個だと3、4個だと3だ。変わってCPU利用率はCPUが1個だと 100%、2個だと100%、3個だと100%、4個だと75%となる。
もちろん、ロードアベレージが3でも、CPUが1個だと常に2つのプロセスが実行可能(CPU割り当て待ち)となるが、3個だと3つのプロセスが全て実 行中になる。なので、CPU利用率は1個でも3個でも同じ100%だが、3個だと十分仕事をさばけている状態だし、1個だとさばけていないよね。CPU利 用率だけでは分からないって事。なのでロードアベレージが存在するわけだ。
そういう訳で、「ロードアベレージの理想値=CPUの個数」または、「ロードアベレージがCPUの個数を超えなければシステムは良好」などと説明されている訳だな。
ロードアベレージ、ＣＰＵ負荷に関するエントリ
http://www.drk7.jp/MT/archives/001300.html
http://blog.livedoor.jp/ld_directors/archives/50851887.html#
http://blogs.sun.com/yappri/entry/loadavg
http://itpro.nikkeibp.co.jp/article/Watcher/20060404/234528/
