J’ai entendu dire beaucoup de choses sur l’interprétation de la load average affichée par la commande top sous Linux.
Tout d’abord, un petit rappel de ce que nous indiquent les trois champs de load average:
0.15 représente la charge moyenne de la dernière minute.
0.27 représente la charge moyenne des cinq dernières minutes.
0.07 représente la charge moyenne des quinze dernières minutes.
Ce qui revient souvent et qui est compris de travers, c’est de dire qu’une machine est surchargée si sa load average est supérieure à 1. C’est erroné sauf si votre machine n’a qu’un seul processeur, monocore de surcroît…
Ce qui est vrai, c’est qu’une machine peut être considérée comme surchargée si chacun de ses cores (et non pas de ses processeurs…) à une load average supérieure à 1.
Quelques exemples pour mieux comprendre:
- un dual proc, mono core = 2 cores -> load average ok jusqu’à 2.
- un dual proc, dual cores = 4 cores -> load average ok jusqu’à 4.
- un dual proc, quad cores = 8 cores -> load average ok jusqu’à combien ?
Bon ok, c’est un peu grossier comme raisonnement. On va dire qu’en tant que bon admin, vous vous serez soucié du problème de charge avant que celle-ci soit supérieure ou égale au bottleneck.
Encore faudrait-il que vous sachiez de combien de processeurs et de coeurs votre machine dispose. Facile, un ptit cat sur le /proc/cpuinfo va vous donner toutes les infos dont vous avez besoin. Par exemple sur ma machine:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
stepping : 6
cpu MHz : 2666.486
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips : 5332.97
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz
stepping : 6
cpu MHz : 2666.486
cache size : 4096 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips : 5333.46
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Les infos qui nous intéressent sont: le physical id pour déterminer le nombre de processeurs physiques et cpu cores pour le nombre de cores. Pour obtenir le nombre total de cores à prendre en compte pour la load average, il faut multiplier le nombre de physical id différents par le nombre de cpu cores affichés (peut importe le nombre de fois que vous le voyez affiché).
Ici je n’ai qu’un seul physical id (0) et 2 cpu cores, ce qui nous donne 1 x 2 = 2. Pour ceux qui ont bien suivi, cela ve dire que je n’ai qu’un seul processeur, mais dual cores.
Bonus: regardez la ligne siblings. Si le nombre de siblings = cpu cores, alors l’hyperthreading n’est pas activé. Si le nombre de siblings = 2 x cpu cores, alors l’hyperthreading est activé.
Attention cependant, car si le calcul d’une load average convenable se base sur les capacités CPU de votre machine, il ne faut pas résumer la charge d’une machine à sa charge CPU. Vous pouvez tout à fait avoir une load average trop élevée alors que la CPU est idle à 90%. La raison à cela ? Beaucoup de processus en attente de traitement (io). Mais du coup, ça vous aura au moins permis d’éliminer une cause potentielle de votre problème de perf 
