Auf 12G Dell-Servern mit RHEL6 wird eine „Power Limit-Benachrichtigung“ angezeigt

9

Server: Poweredge r620
Betriebssystem: RHEL 6.4
Kernel: 2.6.32-358.18.1.el6.x86_64

In meiner Produktionsumgebung treten Anwendungsalarme auf. Kritische CPU-hungrige Prozesse werden an Ressourcen gehungert und verursachen einen Verarbeitungsstau. Das Problem tritt auf allen Dell-Servern der 12. Generation (r620s) in einem kürzlich bereitgestellten Cluster auf. Soweit ich das beurteilen kann, stimmen Instanzen dieses Ereignisses mit der maximalen CPU-Auslastung überein, begleitet von massiven Mengen an Spam bei der Benachrichtigung über "Leistungslimits" dmesg. Ein Auszug aus einem dieser Ereignisse:

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)

Ein wenig Google Fu zeigt, dass dies normalerweise damit zusammenhängt, dass die CPU heiß läuft oder die Spannungsregelung einsetzt. Ich glaube jedoch nicht, dass dies der Fall ist. Temperatursensoren für alle Server im Cluster funktionieren einwandfrei, die Power Cap-Richtlinie ist im iDRAC deaktiviert und mein Systemprofil ist auf allen diesen Servern auf "Leistung" eingestellt:

# 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
  • Ein Dell-Mailinglistenbeitrag beschreibt die Symptome nahezu perfekt. Dell schlug dem Autor vor, das Leistungsprofil zu verwenden, aber das half nicht. Am Ende hat er einige Einstellungen im Dell-Handbuch zum Konfigurieren eines Servers für Umgebungen mit geringer Latenz angewendet, und eine dieser Einstellungen (oder eine Kombination davon) scheint das Problem behoben zu haben.
  • Der Kernel.org-Fehler Nr. 36182 stellt fest, dass das Debuggen von Interrupts mit Leistungsbegrenzung standardmäßig aktiviert war, was in Szenarien, in denen die CPU-Spannungsregelung einsetzt, zu Leistungseinbußen führt.
  • In einem RHN KB-Artikel (RHN-Anmeldung erforderlich) wird ein Problem erwähnt, das sich auf PE r620- und r720-Server auswirkt, auf denen das Leistungsprofil nicht ausgeführt wird, und es wird ein Update für einen vor zwei Wochen veröffentlichten Kernel empfohlen. ... außer wir führen das Leistungsprofil aus ...

Alles, was ich online finden kann, lässt mich hier im Kreis laufen. Was zum Teufel ist los?

linux dell-poweredge rhel6 Andrew B.
quelle
1
Zu Ihrer Information, dieses Problem wurde im Mainline-Kernel 3.11 behoben . Dies liegt daran, dass der Kernel-Interrupt-Handler für dieses "normale" unkritische Ereignis ausgelöst wird. Das oben verlinkte Commit deaktiviert diesen Handler.
Totor

Antworten:

8

Es ist nicht die Spannungsregelung, die das Leistungsproblem verursacht, sondern die Debugging-Kernel-Interrupts, die von ihm ausgelöst werden.

Trotz einiger Fehlinformationen von Redhat beziehen sich alle verlinkten Seiten auf dasselbe Phänomen. Die Spannungsregelung erfolgt mit oder ohne Leistungsprofil, wahrscheinlich aufgrund der aktivierten Turbo-Boost- Funktion. Unabhängig vom Grund interagieren diese Spannungsschwankungen schlecht mit den Kernel-Interrupts mit Leistungsbegrenzung, die standardmäßig in Kernel 2.6.32-358.18.1.el6.x86_64 aktiviert sind.

Bestätigte Problemumgehungen:

  • Durch ein Upgrade auf den zuletzt veröffentlichten Redhat-Kernel (2.6.32-358.23.2.el6) wird dieses Debugging deaktiviert und das Leistungsproblem behoben.
  • Durch Hinzufügen der folgenden Kernelparameter grub.confwerden PLNs deaktiviert:clearcpuid=229

Flockige Problemumgehungen:

  • Festlegen eines Systemprofils für "Leistung". Dies allein reichte nicht aus, um PLNs auf unseren Servern zu deaktivieren. Ihr Kilometerstand kann variieren.

Schlechte Problemumgehungen:

  • ACPI-bezogene Module auf die schwarze Liste setzen. Ich habe dies in einigen Forenthreads gesehen. Schlecht beraten, also nicht .
Andrew B.
quelle
Haben Sie keine Updates auf neu bereitgestellten Systemen ausgeführt?
ewwhite
@ewwhite Diese Server wurden bereitgestellt, kurz bevor diese Kernel-Updates live gingen. Die neue Drehzahl wurde am 16. Oktober zur Verfügung gestellt .
Andrew B
Grrr zu Red Hat. Schöner Fund.
ewwhite
Auch nach dem Update tauchte dieses Problem nach einigen Wochen wieder auf (auf Kernel 2.6.32-431.17.1.el6.x86_64). Wir mussten PLNs mit clearcpuid deaktivieren, um sie dieses Mal loszuwerden. Dieses Problem hat mir schon so viele Kopfschmerzen bereitet! Und wir haben nur einen 12G Dell Server (und dieser wird aus diesem Grund der einzige bleiben).
Martijn
1
@Martijn Wir sind derzeit mit 2.6.32-431.11.2.el6.x86_64dem Problem beschäftigt und haben es nicht. Viele Cluster, hohe Lasten usw. Es ist möglich, dass sich eine Regression eingeschlichen hat, als Redhat dieses Update vor fünf Tagen veröffentlichte. Ich werde Sie wissen lassen, was ich finde, und die Antwort aktualisieren, wenn ich feststelle, dass dies der Fall ist.
Andrew B