1 votes

Linux Scheduler (n'utilise pas tous les cœurs sur une machine multicœur) RHEL6

Je constate un comportement étrange sur l'un de mes serveurs (fonctionnant sous RHEL 6). Il semble qu'il y ait un problème avec l'ordonnanceur.

Voici le programme de test que j'utilise :

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

void RunClient(int i) {
  printf("Starting client %d\n", i);
  while (true) {
  }
}

int main(int argc, char** argv) {
  for (int i = 0; i < 4; ++i) {
    pid_t p_id = fork();
    if (p_id == -1) {
      perror("fork");
    } else if (p_id == 0) {
      RunClient(i);
      exit(0);
    }
  }

  return 0;
}

Cette machine possède bien plus de 4 cœurs et nous nous attendons donc à ce que tous les processus tournent à 100 %. Lorsque je vérifie en haut, l'utilisation du processeur varie. Parfois elle est divisée (100%, 33%, 33%, 33%), d'autres fois elle est divisée (100%, 100%, 50%, 50%).

Lorsque j'effectue ce test sur un autre de nos serveurs (fonctionnant sous RHEL 5), il n'y a aucun problème (c'est 100%, 100%, 100%, 100%) comme prévu. Quelle est la cause de ce problème et comment puis-je le résoudre ?

T

3voto

Janne Pikkarainen Points 31244

Vous semblez réinventer la roue, il existe déjà plusieurs programmes de torture du processeur, tels que stress . Je parie que le compilateur C optimise votre programme de manière à ce qu'il n'ait pas à brûler constamment l'unité centrale pendant l'exécution du test.

Essayez avec

stress -c 4 -t 60

Cela permet de lancer 4 processus gourmands en ressources humaines et d'effectuer le test pendant 60 secondes. Je parie que vous verrez quatre cœurs fonctionner à 100 %. Cependant, si vous avez BEAUCOUP plus de cœurs que 4 (disons 16), le résultat peut varier, à moins que vous n'épingliez la commande de stress pour utiliser des cœurs spécifiques avec taskset .

1voto

Ross Light Points 1994

Il existe de grandes différences entre Red Hat 5 et 6. Je pense que la plus importante qui affecterait votre cas d'utilisation est le passage au Completely Fair Scheduler. Il n'est pas cassé, mais il présentera probablement un comportement différent au sommet par rapport au planificateur de RHEL 5. Il permettra aux processus qui étaient totalement ignorés auparavant de bénéficier d'un peu de temps processeur.

Je pense également que cette boucle while vide est en grande partie un no-op et sera optimisée jusqu'à l'oubli si vous avez activé une quelconque optimisation pour la compilation (je ne suis pas vraiment un programmeur C mais je pense que c'est le cas ; cela peut même se produire sans drapeaux d'optimisation explicites, car c'est totalement redondant). Essayez d'y mettre un calcul réel et voyez ce qui se passe.

En règle générale, à moins que vous n'en sachiez assez pour écrire votre propre planificateur de noyau, je suppose qu'il ne s'agit pas d'un bogue, mais d'une manifestation du fonctionnement du système. Ou d'un problème avec votre code/instrumentation.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X