“Notificação de limite de energia” que afeta os servidores 12G da Dell com RHEL6

9

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

Estou enfrentando alarmes de aplicativos no meu ambiente de produção. Processos críticos que exigem muita CPU estão ficando sem recursos e causando um atraso no processamento. O problema está acontecendo em todos os servidores Dell de 12ª geração (r620s) em um cluster implantado recentemente. Até onde eu sei, as ocorrências disso estão correspondendo ao pico de utilização da CPU, acompanhadas por grandes quantidades de spam de "notificação de limite de energia" dmesg. Um trecho de um desses 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)

Um pouco do Google Fu revela que isso geralmente está associado à CPU quente, ou à regulação da tensão. Não acho que seja isso o que está acontecendo. Os sensores de temperatura de todos os servidores do cluster estão funcionando bem, a política de limite de energia está desabilitada no iDRAC e meu perfil do sistema está definido como "Desempenho" em todos esses 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
  • Uma postagem na lista de discussão da Dell descreve os sintomas quase perfeitamente. A Dell sugeriu que o autor tentasse usar o perfil Desempenho, mas isso não ajudou. Ele acabou aplicando algumas configurações no guia da Dell para configurar um servidor para ambientes de baixa latência e uma dessas configurações (ou uma combinação delas) parece ter corrigido o problema.
  • O bug # 36182 do Kernel.org observa que a depuração de interrupção no limite de energia foi ativada por padrão, o que está causando degradação do desempenho em cenários onde a regulação da tensão da CPU está aumentando.
  • Um artigo da RHN KB (é necessário fazer login na RHN) menciona um problema que afeta os servidores PE r620 e r720 que não estão executando o perfil Performance e recomenda uma atualização para um kernel lançado duas semanas atrás. ... Exceto que estamos executando o perfil Desempenho ...

Tudo o que posso encontrar on-line está me circulando em círculos aqui. O que diabos está acontecendo?

linux  dell-poweredge  rhel6 
— Andrew B
fonte
1
Para sua informação, esse problema foi corrigido no kernel da linha principal 3.11. Isso ocorre porque o manipulador de interrupções do kernel é acionado para esse evento não crítico "normal". A consolidação vinculada acima desabilita esse manipulador.
— Totor

Respostas:

8

Não é a regulação de tensão que causa o problema de desempenho, mas o kernel de depuração interrompe que está sendo acionado por ele.

Apesar de algumas informações erradas da parte de Redhat, todas as páginas vinculadas estão se referindo ao mesmo fenômeno. A regulação de tensão ocorre com ou sem o perfil Performance, provavelmente devido ao recurso Turbo Boost estar ativado. Independentemente do motivo, essas flutuações de tensão estão interagindo mal com as interrupções do limite de energia que são ativadas por padrão no kernel 2.6.32-358.18.1.el6.x86_64.

Soluções alternativas confirmadas:

  • A atualização para o kernel Redhat lançado mais recentemente (2.6.32-358.23.2.el6) desativa essa depuração e elimina o problema de desempenho.
  • A adição dos seguintes parâmetros do kernel grub.confdesabilitará os PLNs:clearcpuid=229

Soluções alternativas escamosas:

  • Definindo um perfil de sistema de "desempenho". Isso por si só não foi suficiente para desativar os PLNs em nossos servidores. Sua milhagem pode variar.

Bad soluções alternativas:

  • Lista negra de módulos relacionados à ACPI. Eu já vi isso em alguns tópicos do fórum. Mal recomendado, então não .
— Andrew B
fonte
Você não estava executando atualizações em sistemas recém-implantados?
— ewwhite
@ewwhite Esses servidores foram implantados pouco antes de as atualizações do kernel serem lançadas. O novo RPM foi disponibilizado em 16 de outubro .
— Andrew B
Grrr para a Red Hat. Bom achado.
— ewwhite
Mesmo após a atualização, esse problema ressurgiu para mim após algumas semanas (no kernel 2.6.32-431.17.1.el6.x86_64). Tivemos que desativar os PLNs usando o clearcpuid para nos livrarmos dessa vez. Esse problema já me causou muitas dores de cabeça! E temos apenas um servidor 12G Dell (e continuará sendo o único por causa disso).
— Martijn
1
@Martijn No momento, estamos trabalhando 2.6.32-431.11.2.el6.x86_64e não estamos enfrentando o problema. Muitos clusters, altas cargas etc. É possível que uma regressão tenha surgido quando o Redhat lançou essa atualização há cinco dias. Informarei o que encontro e atualizo a resposta se descobrir que esse é o caso.
— Andrew B
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.