Clobbering de “notificación de límite de potencia” en servidores Dell 12G con RHEL6

9

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

Estoy experimentando alarmas de aplicaciones en mi entorno de producción. Procesos críticos de CPU hambrientos se están quedando sin recursos y causando una acumulación de procesamiento. El problema está ocurriendo en todos los servidores Dell de 12a generación (r620s) en un clúster recientemente implementado. Por lo que puedo decir, las instancias de este suceso coinciden con la utilización máxima de la CPU, acompañadas de cantidades masivas de spam de "notificación de límite de potencia" dmesg. Un extracto de uno de estos eventos:

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 poco de Google Fu revela que esto generalmente se asocia con la CPU funcionando en caliente o con la regulación de voltaje en funcionamiento. No creo que eso sea lo que está sucediendo. Los sensores de temperatura para todos los servidores del clúster funcionan bien, la Política de límite de energía está deshabilitada en el iDRAC y mi Perfil del sistema está configurado en "Rendimiento" en todos estos servidores:

# 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
  • Una publicación de la lista de correo de Dell describe los síntomas casi a la perfección. Dell sugirió que el autor intentara usar el perfil de rendimiento, pero eso no ayudó. Terminó aplicando algunas configuraciones en la guía de Dell para configurar un servidor para entornos de baja latencia y una de esas configuraciones (o una combinación de ambas) parece haber solucionado el problema.
  • El error Kernel.org n. ° 36182 señala que la depuración de interrupción del límite de potencia se habilitó de manera predeterminada, lo que está causando una degradación del rendimiento en escenarios en los que se está iniciando la regulación del voltaje de la CPU.
  • Un artículo de RHN KB (se requiere inicio de sesión de RHN) menciona un problema que afecta a los servidores PE r620 y r720 que no ejecutan el perfil de rendimiento, y recomienda una actualización de un núcleo lanzado hace dos semanas. ... Excepto que estamos ejecutando el perfil de rendimiento ...

Todo lo que puedo encontrar en línea me está ejecutando en círculos aquí. ¿Qué diablos está pasando?

linux dell-poweredge rhel6 Andrew B
fuente
1
Para su información, este problema se ha corregido en el núcleo de la línea principal 3.11. Se debe a que el controlador de interrupción del núcleo se activa para este evento no crítico "normal". La confirmación vinculada anteriormente deshabilita este controlador.
Totor

Respuestas:

8

No es la regulación del voltaje la que causa el problema de rendimiento, sino las interrupciones del núcleo de depuración que está activando.

A pesar de cierta información errónea por parte de Redhat, todas las páginas vinculadas se refieren al mismo fenómeno. La regulación de voltaje ocurre con o sin el perfil de rendimiento, probablemente debido a que la función Turbo Boost está habilitada. Independientemente de la razón, estas fluctuaciones de voltaje están interactuando de manera deficiente con las interrupciones del kernel con límite de potencia que están habilitadas por defecto en el kernel 2.6.32-358.18.1.el6.x86_64.

Soluciones alternativas confirmadas:

  • La actualización al kernel Redhat lanzado más recientemente (2.6.32-358.23.2.el6) desactiva esta depuración y elimina el problema de rendimiento.
  • Agregar los siguientes parámetros del kernel grub.confdeshabilitará los PLN:clearcpuid=229

Soluciones escamosas:

  • Establecer un perfil del sistema de "rendimiento". Esto por sí solo no fue suficiente para deshabilitar los PLN en nuestros servidores. Su experiencia puede ser diferente.

Soluciones alternativas malas :

  • Lista negra de módulos relacionados con ACPI. He visto esto en algunos hilos del foro. Mal aconsejado, así que no lo hagas .
Andrew B
fuente
¿No estaba ejecutando actualizaciones en sistemas recientemente implementados?
Ewwhite
@ewwhite Estos servidores se implementaron justo antes de que se activaran las actualizaciones del kernel. El nuevo RPM estuvo disponible el 16 de octubre .
Andrew B
Grrr a Red Hat. Buen hallazgo
ewwhite
Incluso después de la actualización, este problema volvió a aparecer para mí después de algunos días (en el kernel 2.6.32-431.17.1.el6.x86_64). Tuvimos que deshabilitar los PLN usando clearcpuid para deshacernos de él esta vez. ¡Este problema ya me ha causado tantos dolores de cabeza! Y solo tenemos un servidor 12G Dell (y seguirá siendo el único debido a esto).
Martijn
1
@Martijn Actualmente estamos haciendo 2.6.32-431.11.2.el6.x86_64y no experimentamos el problema. Muchos clústeres, cargas altas, etc. Es posible que haya habido una regresión cuando Redhat lanzó esa actualización hace cinco días. Le haré saber lo que encuentro y actualizaré la respuesta si descubro que ese es el caso.
Andrew B