Bonne façon d'interpréter la charge du système sur un processeur à 4 threads et 8 threads

Comme nous le savons tous, une charge de 1,00 sur un seul processeur signifie qu'il y a une charge de 100% . Analogiquement, une charge de 4,00 sur un quad core serait de 100% .

Comment dois-je interpréter la charge sur un processeur à 4 threads et 8 threads? Quand puis-je atteindre la capacité maximale du processeur? À 4h00 ou 8h00 ?

Pas surement, mais surtout 1.00*n_cpu.

La charge signifie ce qui suit: s'il y a plusieurs processus sur un système à processeur unique, ils fonctionnent 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 arrête 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 / 100ème de seconde?", Sera décidée par une heuristique complexe. Il est nommé comme tâche la planification .

Bien entendu, les processus qui sont bloqués, par exemple ils attendent leurs données ce qu'ils lisent sur le disque, sont exemptés de cette planification des tâches.

Quelle charge indique: combien de processus attendent actuellement leur prochaine tranche de 1 / 100e de seconde. Bien sûr, c'est une valeur moyenne. En effet, vous pouvez voir plusieurs nombres dans un cat /proc/loadavg.

La situation dans un système multi-CPU 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 du système pour une efficacité optimale, et il est proche de cela (il y a des choses d'optimisation mineures, 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 la charge 8, cela signifie: il y a en fait 8 processus en attente de leur prochaine tranche de temps. Si nous avons 8 cpus, nous pouvons donner ces tranches de temps aux cpus 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 bas: ce sont les processus marqués par Rlà. Même sur un système pas vraiment hardcore, il est souvent inférieur à 5. Cela est dû en partie au fait que les processus attendant leurs données des disques ou du réseau sont également suspendus (marqués d'un Sen haut). La charge affiche uniquement 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 certaine manière, ce n'est pas si bien connu ici dans notre monde sysadmin professionnel.

Les outils Windows divisent souvent la charge avec 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 pas de différence.

Dans le cas de CPU hyperthreadés, il y a un effet secondaire intéressant: le chargement d'un processeur ralentit ses paires hyperthreadées. Mais cela se produit sur une couche plus profonde que gère la planification normale des tâches, bien qu'elle puisse (et devrait) influencer les décisions de déplacement du processus du planificateur.

Mais de notre point de vue actuel - ce qui détermine la charge du système - cela n'a pas autant d'importance.

Étant donné que l'hyperthreading n'est pas réellement un 2e cœur, il ne portera jamais un cœur à 200% mais il le dépassera à 100% pour certaines charges de travail.

Votre charge maximale est donc quelque part inconnue entre environ 4 et 6

(bien sûr, cela peut augmenter plus en cas de surcharge car il compte en fait les processus exécutables, en particulier lorsqu'ils attendent des E / S)

La moyenne de charge ne signifie pas ce que vous pensez que cela signifie. Il ne s'agit pas de l'utilisation instantanée du processeur, mais plutôt du nombre de processus en attente d'exécution. Habituellement, c'est à cause de beaucoup de choses qui manquent de CPU, mais pas toujours. Un coupable commun est un processus en attente d'E / S - disque ou réseau.

Essayez d'exécuter ps -e vet de rechercher des 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").

Ceci provient de la pspage de manuel, vous y trouverez donc plus de détails - Ret les Dprocessus sont probablement d'un intérêt particulier.

Vous pouvez vous retrouver avec des «pics» de charge moyenne pour toutes sortes de raisons, donc ils ne sont pas vraiment une bonne mesure d'autre chose que «ce système est-il occupé». S'enliser dans le mappage de la charge moyenne aux cœurs de processeur ne vous fera aucun bien.

Sur un système Linux, non seulement les processus dans la file d'attente exécutable sont comptés pour calculer la charge, mais également ceux dans des états de veille sans interruption, wikipedia , provoquant une augmentation de la charge lorsque de nombreux processus attendent le disque.

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 fonctionne à 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 un boost d'environ 10-20% si vous activez l'hyperthreading par rapport à non. Ce n'est pas un coup de pouce à 100% comme le laisseraient entendre les gars du 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 d'exécuter

time numactl --physcpubind=0-23  ./myprocess

puis exécutez

time numactl --physcpubind=0-47  ./myprocess

Ce dernier devrait fonctionner en 10 à 20% de temps en moins. Si votre processus est fortement bloqué d'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.