Solution 1 :
Pas surement, mais surtout sur 1.00*n_cpu .
La charge signifie ce qui suit :s'il existe plusieurs processus sur un système à processeur unique, ils s'exécutent apparemment en parallèle. Mais ce n'est pas vrai. Ce qui se passe pratiquement :le noyau donne 1/100e de seconde à un processus, puis interrompt son exécution avec une interruption. Et donne le 1/100e de seconde suivant à un autre processus.
Pratiquement, la question "quel processus devrait obtenir notre prochain intervalle de 1/100e de seconde ?", sera tranchée par une heuristique complexe. Il est nommé tâche planification .
Bien sûr, les processus qui sont bloqués, par exemple ils attendent leurs données qu'ils lisent sur le disque, sont exemptés de cette planification des tâches.
Que dit la charge :combien de processus attendent actuellement leur prochaine période de 1/100e de seconde. Bien sûr, c'est une valeur moyenne. C'est parce que vous pouvez voir plusieurs nombres dans un cat /proc/loadavg .
La situation dans un système multi-processeurs est un peu plus complexe. Il existe plusieurs processeurs, dont les délais peuvent être attribués à plusieurs processus. Cela rend la planification des tâches un peu - mais pas trop - plus complexe. Mais la situation est la même.
Le noyau est intelligent, il essaie de partager les ressources système pour une efficacité optimale, et c'est à peu près cela (il y a des choses mineures d'optimisation, par exemple, il vaut mieux qu'un processus soit exécuté le plus longtemps possible sur le même cpu en raison de considérations de mise en cache, mais cela n'a pas d'importance ici). En effet, si nous avons load 8, cela signifie qu'il y a en fait 8 processus en attente de leur prochaine tranche de temps. Si nous avons 8 processeurs, nous pouvons donner ces tranches de temps aux processeurs un à un, et ainsi notre système sera utilisé de manière optimale.
Si vous voyez un top , vous pouvez voir que le nombre de processus en cours d'exécution est étonnamment faible :ce sont les processus marqués par R là. Même sur un système pas vraiment hardcore, il est souvent inférieur à 5. C'est en partie parce que les processus attendant leurs données depuis les disques ou depuis le réseau sont également suspendus (marqués avec S en haut). La charge ne montre que l'utilisation du processeur.
Il existe également des outils pour mesurer la charge du disque, à mon humble avis, ils devraient être au moins importants en tant que surveillance de l'utilisation du processeur, mais d'une manière ou d'une autre, ce n'est pas si bien connu ici dans notre monde d'administrateur système professionnel.
Les outils Windows divisent souvent la charge par le nombre réel de processeurs. Cela amène certains administrateurs système Windows professionnels à utiliser la charge système dans ce sens divisé par processeur. Ils n'ont pas raison et seront probablement plus heureux après que vous leur ayez expliqué cela.
Les processeurs multicœurs sont pratiquement plusieurs processeurs sur la même puce de silicium. Il n'y a aucune différence.
Dans le cas des processeurs hyperthreadés, il y a un effet secondaire intéressant :le chargement d'un processeur ralentit ses paires hyperthreadées. Mais cela se produit à un niveau plus profond, ce que la planification normale des tâches gère, bien que cela puisse (et doive) influencer les décisions de déplacement de processus du planificateur.
Mais de notre point de vue actuel - ce qui détermine la charge du système - cela n'a pas non plus d'importance.
Solution 2 :
La charge moyenne ne signifie pas ce que vous pensez que cela signifie. Il ne s'agit pas d'une utilisation instantanée du processeur, mais plutôt du nombre de processus en attente d'exécution. Généralement c'est à cause de beaucoup de choses qui demandent du CPU, mais pas toujours. Un coupable courant est un processus en attente d'E/S - disque ou réseau.
Essayez d'exécuter ps -e v et la recherche d'indicateurs d'état de processus.
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").
Cela vient du ps page de manuel, pour que vous y trouviez plus de détails - R et D processus présentent probablement un intérêt particulier.
Vous pouvez vous retrouver avec des "pics" de moyenne de charge pour toutes sortes de raisons, ils ne sont donc pas vraiment une bonne mesure de quoi que ce soit d'autre que "ce système est-il occupé". S'enliser dans le mappage de la moyenne de charge aux cœurs de processeur ne vous fera aucun bien.
Solution 3 :
Comme l'hyperthreading n'est pas réellement un deuxième cœur, il n'atteindra jamais un cœur à 200 %, mais il l'amènera au-delà de 100 % pour certaines charges de travail.
Donc, votre charge maximale est quelque part inconnue entre environ 4 et 6
(bien sûr, cela peut augmenter en cas de surcharge car il compte en fait les processus exécutables, en particulier lorsqu'ils attendent des E/S)
Solution 4 :
Sur un système Linux, non seulement les processus de la file d'attente exécutable sont comptés pour calculer la charge, mais également ceux dans les états de veille ininterrompus , wikipedia, provoquant un pic de charge lorsque de nombreux processus attendent le disque.
Solution 5 :
J'ai fait quelques expériences sur notre système Xeon à 24 cœurs (2 sockets x 12 cœurs). La charge maximale est de 48,0 dans ce cas en raison de la façon dont Linux configure l'hyperthreading.
Cependant, vous n'obtenez pas l'équivalent de 48 cœurs de débit. Ce que j'ai observé, c'est que vous obtenez environ 90 % du débit dans les 24 premiers processeurs logiques, c'est-à-dire si la charge atteint 24,0. Ensuite, vous obtenez un débit supplémentaire d'environ 10 % pour les 24 processeurs logiques restants (la charge s'exécute à 48,0). Une autre façon de penser est que si vous exécutez 48 threads sur les 24 cœurs, vous obtiendrez une augmentation d'environ 10 à 20 % si vous activez l'hyperthreading plutôt que non. Ce n'est pas un coup de pouce à 100 % comme le laisseraient entendre les responsables marketing.
Par exemple, une façon de tester cette observation est d'avoir un processus qui exécute 48 threads (par exemple en utilisant TBB ou un modèle de threading manuel), puis de l'exécuter
time numactl --physcpubind=0-23 ./myprocess
puis lancez
time numactl --physcpubind=0-47 ./myprocess
Ce dernier devrait fonctionner en environ 10 à 20 % de temps en moins. Si votre processus est fortement bloqué en E/S, le résultat peut être différent.
Le premier désactivera l'hyperthreading en autorisant uniquement les threads à s'exécuter sur un seul processeur logique (de chaque cœur), tandis que le second activera l'hyperthreading en permettant aux threads de s'exécuter sur 2 processeurs logiques (de chaque cœur).
La charge dans les deux cas doit être signalée comme 48,0 ... ce qui, comme vous pouvez le voir, est très trompeur.