"Notifica del limite di potenza" che blocca i server Dell 12G con RHEL6


9

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

Riscontro allarmi applicazione nel mio ambiente di produzione. I processi critici affamati di CPU vengono privati ​​di risorse e causano un backlog di elaborazione. Il problema si sta verificando su tutti i server Dell di 12a generazione (r620s) in un cluster distribuito di recente. Per quanto ne so, i casi in cui si verificano si stanno avvicinando al picco di utilizzo della CPU, accompagnati da enormi quantità di spam "notifica del limite di potenza" dmesg. Un estratto di uno di questi eventi:

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 po 'di Google Fu rivela che questo è in genere associato alla CPU surriscaldata o all'avvio della regolazione della tensione. Non credo sia quello che sta succedendo però. I sensori di temperatura per tutti i server nel cluster funzionano correttamente, i criteri Power Cap sono disabilitati in iDRAC e il mio profilo di sistema è impostato su "Prestazioni" su tutti questi server:

# 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
  • Un post della mailing list di Dell descrive i sintomi quasi perfettamente. Dell ha suggerito all'autore di provare a utilizzare il profilo delle prestazioni, ma ciò non ha aiutato. Ha finito per applicare alcune impostazioni nella guida di Dell per la configurazione di un server per ambienti a bassa latenza e una di quelle impostazioni (o una loro combinazione) sembra aver risolto il problema.
  • Il bug # 36182 di Kernel.org nota che il debug di interrupt di limite di potenza era abilitato di default, il che sta causando il degrado delle prestazioni in scenari in cui la regolazione della tensione della CPU sta iniziando.
  • Un articolo di RHN KB (accesso RHN richiesto) menziona un problema che riguarda i server PE r620 e r720 che non eseguono il profilo delle prestazioni e raccomanda un aggiornamento a un kernel rilasciato due settimane fa. ... Tranne il fatto che stiamo eseguendo il profilo Performance ...

Tutto ciò che posso trovare online mi fa girare in cerchio qui. Che diamine sta succedendo?


1
Cordiali saluti, questo problema è stato corretto nel kernel 3.11 della linea principale. È dovuto al fatto che il gestore di interrupt del kernel si innesca per questo evento "normale" non critico. Il commit collegato sopra disabilita questo gestore.
Totor

Risposte:


8

Non è la regolazione della tensione che causa il problema delle prestazioni, ma il kernel di debug interrompe che viene attivato da esso.

Nonostante qualche disinformazione da parte di Redhat, tutte le pagine collegate si riferiscono allo stesso fenomeno. La regolazione della tensione avviene con o senza il profilo Performance, probabilmente a causa dell'attivazione della funzione Turbo Boost . Indipendentemente dal motivo, queste fluttuazioni di tensione interagiscono male con gli interrupt del kernel con limite di potenza abilitati per impostazione predefinita nel kernel 2.6.32-358.18.1.el6.x86_64.

Soluzioni alternative confermate:

  • L'aggiornamento al kernel Redhat rilasciato più di recente (2.6.32-358.23.2.el6) disabilita questo debug ed elimina il problema delle prestazioni.
  • L'aggiunta dei seguenti parametri del kernel a grub.confdisabiliterà i PLN:clearcpuid=229

Soluzioni alternative traballanti:

  • Impostazione di un profilo di sistema di "Prestazioni". Questo da solo non era abbastanza per disabilitare i PLN sui nostri server. Il tuo chilometraggio può variare.

Bad Soluzioni alternative:

  • Inserimento nella blacklist di moduli ACPI. L'ho visto in alcuni thread del forum. Sconsigliato, quindi non farlo .

Non stavi eseguendo aggiornamenti su sistemi appena distribuiti?
ewwhite

@ewwhite Questi server sono stati distribuiti poco prima che quegli aggiornamenti del kernel diventassero attivi. Il nuovo RPM è stato reso disponibile il 16 ottobre .
Andrew B,

Grrr a Red Hat. Bella scoperta.
ewwhite

Anche dopo l'aggiornamento questo problema è riemerso per me dopo qualche settimana (sul kernel 2.6.32-431.17.1.el6.x86_64). Questa volta abbiamo dovuto disabilitare i PLN usando clearcpuid per sbarazzarcene. Questo problema mi ha già causato così tanti mal di testa! E abbiamo solo un server Dell 12G (e rimarrà l'unico a causa di ciò).
Martijn,

1
@Martijn Al momento stiamo 2.6.32-431.11.2.el6.x86_64riscontrando e non riscontriamo il problema. Molti cluster, carichi elevati, ecc. È possibile che si sia verificata una regressione quando Redhat ha rilasciato quell'aggiornamento cinque giorni fa. Ti farò sapere cosa trovo e aggiornerò la risposta se lo scoprissi.
Andrew B,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.