«Notification de limite de puissance» sur les serveurs Dell 12G avec RHEL6

9

Serveur: Poweredge r620
OS: RHEL 6.4
Noyau: 2.6.32-358.18.1.el6.x86_64

Je rencontre des alarmes d'application dans mon environnement de production. Les processus critiques gourmands en CPU sont privés de ressources et provoquent un retard de traitement. Le problème se produit sur tous les serveurs Dell de 12e génération (r620) d'un cluster récemment déployé. Pour autant que je sache, des exemples de ce phénomène se produisent jusqu'à une utilisation maximale du processeur, accompagnés de quantités massives de spam de "notification de limite de puissance" dmesg. Un extrait de l'un de ces événements:

Nov  7 10:15:15 someserver [.crit] CPU12: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU6: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU14: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Package power limit notification (total events = 11)
Nov  7 10:15:15 someserver [.crit] CPU6: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU14: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU20: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Package power limit notification (total events = 12)
Nov  7 10:15:15 someserver [.crit] CPU10: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU20: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU10: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU15: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU3: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU1: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU5: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU15: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU3: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU1: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU5: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU19: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Package power limit notification (total events = 377)
Nov  7 10:15:15 someserver [.crit] CPU9: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU21: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU23: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU11: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU19: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU9: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU21: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU23: Package power limit notification (total events = 374)

Un peu de Google Fu révèle que cela est généralement associé au processeur à chaud ou à la régulation de la tension. Je ne pense pas que ce soit le cas. Les capteurs de température pour tous les serveurs du cluster fonctionnent correctement, la politique de limitation de l'alimentation est désactivée dans l'iDRAC et mon profil système est défini sur "Performances" sur tous ces serveurs:

# omreport chassis biossetup | grep -A10 'System Profile'
System Profile Settings
------------------------------------------
System Profile                                    : Performance
CPU Power Management                              : Maximum Performance
Memory Frequency                                  : Maximum Performance
Turbo Boost                                       : Enabled
C1E                                               : Disabled
C States                                          : Disabled
Monitor/Mwait                                     : Enabled
Memory Patrol Scrub                               : Standard
Memory Refresh Rate                               : 1x
Memory Operating Voltage                          : Auto
Collaborative CPU Performance Control             : Disabled
  • Une publication sur la liste de diffusion Dell décrit les symptômes presque parfaitement. Dell a suggéré à l'auteur d'essayer d'utiliser le profil Performance, mais cela n'a pas aidé. Il a fini par appliquer certains paramètres dans le guide de Dell pour configurer un serveur pour des environnements à faible latence et l'un de ces paramètres (ou une combinaison de ceux-ci) semble avoir résolu le problème.
  • Le bogue Kernel.org # 36182 note que le débogage des interruptions de limite de puissance a été activé par défaut, ce qui entraîne une dégradation des performances dans les scénarios où la régulation de la tension du processeur intervient.
  • Un article de la base de connaissances RHN (connexion RHN requise) mentionne un problème affectant les serveurs PE r620 et r720 qui n'exécutent pas le profil de performances et recommande une mise à jour d'un noyau publié il y a deux semaines. ... Sauf que nous exécutons le profil Performance ...

Tout ce que je peux trouver en ligne me fait tourner en rond ici. Qu'est-ce qui se passe?

linux dell-poweredge rhel6 Andrew B
la source
1
Pour info, ce problème a été corrigé dans le noyau principal 3.11. Cela est dû au déclenchement du gestionnaire d'interruption du noyau pour cet événement non critique "normal". La validation liée ci-dessus désactive ce gestionnaire.
Totor

Réponses:

8

Ce n'est pas la régulation de la tension qui cause le problème de performances, mais les interruptions du noyau de débogage qui sont déclenchées par lui.

Malgré quelques informations erronées de la part de Redhat, toutes les pages liées font référence au même phénomène. La régulation de la tension se produit avec ou sans le profil de performance, probablement en raison de l' activation de la fonction Turbo Boost . Quelle que soit la raison, ces fluctuations de tension interagissent mal avec les interruptions du noyau de limitation de puissance qui sont activées par défaut dans le noyau 2.6.32-358.18.1.el6.x86_64.

Solutions de contournement confirmées:

  • La mise à niveau vers le noyau Redhat le plus récent (2.6.32-358.23.2.el6) désactive ce débogage et élimine le problème de performances.
  • L'ajout des paramètres de noyau suivants à grub.confdésactivera les PLN:clearcpuid=229

Solutions de contournement floconneuses:

  • Définition d'un profil système de «Performance». Cela en soi n'était pas suffisant pour désactiver les PLN sur nos serveurs. Votre kilométrage peut varier.

Mauvaises solutions:

  • Liste noire des modules liés à ACPI. J'ai vu cela dans quelques discussions de forum. Mal avisé, alors ne le faites pas .
Andrew B
la source
N'exécutiez-vous pas des mises à jour sur les systèmes récemment déployés?
ewwhite
@ewwhite Ces serveurs ont été déployés juste avant la mise en ligne de ces mises à jour du noyau. Le nouveau RPM a été rendu public le 16 octobre .
Andrew B
Grrr à Red Hat. Belle trouvaille.
ewwhite
Même après la mise à jour, ce problème a refait surface pour moi après quelques semaines (sur le noyau 2.6.32-431.17.1.el6.x86_64). Nous avons dû désactiver les PLN en utilisant clearcpuid pour nous en débarrasser cette fois. Ce problème m'a déjà causé tellement de maux de tête! Et nous n'avons qu'un seul serveur Dell 12G (et il restera le seul à cause de cela).
Martijn
1
@Martijn Nous sommes actuellement à la hauteur 2.6.32-431.11.2.el6.x86_64et ne rencontrons pas le problème. Beaucoup de clusters, charges élevées, etc. Il est possible qu'une régression se soit glissée lorsque Redhat a publié cette mise à jour il y a cinq jours. Je vous ferai savoir ce que je trouve et mettrai à jour la réponse si je découvre que c'est le cas.
Andrew B