Erro: bloqueio suave - CPU # travado por x segundos

33

Eu já vi alguns relatórios de bugs e perguntas (na stackexchange e em outros lugares) sobre um incômodo "BUG: soft lockup - CPU#<n> stuck for <dt>s!". Até agora, não encontrei nenhuma pista sobre o que fazer ou tentar (em vez disso, as pistas que encontrei e segui não impediram que isso acontecesse). Estou mais preocupado com isso porque:

  1. a frequência desses eventos parece ter aumentado lentamente ultimamente (mais de 700 por mês),
  2. yum update e a reinicialização diminuiu a velocidade um pouco, mas vi alguns bloqueios começando a acontecer novamente,
  3. vários processos (se não o host inteiro, é difícil dizer), certamente incluindo todos os meus shells interativos ficam congelados por um certo período de tempo quando isso acontece,
  4. Não tenho certeza se isso está relacionado, mas vejo muitos logs / mensagens relacionados ao ntpd que não conseguem atualizar o relógio.

A seguir, um trecho de $(grep 'soft lockup' /var/log/messages*):

Mar 22 10:02:35 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [kjournald:1048]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:36 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:37 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:38 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#0 stuck for 10s! [postgres:5372]
Mar 22 10:02:39 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [postgres:5368]
Mar 22 10:02:40 localhost kernel: BUG: soft lockup - CPU#15 stuck for 25s! [swapper:0]
Mar 22 15:42:16 localhost kernel: BUG: soft lockup - CPU#8 stuck for 25s! [kjournald:1048]
Mar 22 18:22:13 localhost kernel: BUG: soft lockup - CPU#15 stuck for 10s! [postgres:21356]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#7 stuck for 10s! [java:8653]
Mar 22 18:22:20 localhost kernel: BUG: soft lockup - CPU#8 stuck for 72s! [kjournald:1048]
Mar 22 21:21:37 localhost kernel: BUG: soft lockup - CPU#12 stuck for 29s! [kjournald:1048]
Mar 22 21:22:07 localhost kernel: BUG: soft lockup - CPU#12 stuck for 27s! [kjournald:1048]
Mar 23 02:01:47 localhost kernel: BUG: soft lockup - CPU#8 stuck for 10s! [kblockd/8:276]
Mar 23 02:02:22 localhost kernel: BUG: soft lockup - CPU#8 stuck for 34s! [kblockd/8:276]

Isso acontece com processos aleatórios e parece razoavelmente bem distribuído pelos 16 "núcleos" desse host virtual.

O host é uma instância do AWS EC2 "cc1.4xlarge", com uma AMI denominada "EC2 CentOS 5.5 GPU HVM AMI (Driver 260.19.29) (ami-42a2532b)". Parece ser virtualizado com o Xen.

cat /etc/redhat-releaserendimentos CentOS release 5.9 (Final). 'free'relata 21G de RAM.

A cabeça de dmesgé:

Linux version 2.6.18-348.3.1.el5 ([email protected]) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Mon Mar 11 19:39:25 EDT 2013
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet console=tty0 console=ttyS0,115200n8
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000fc000000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000005dd800000 (usable)
DMI 2.4 present.
DMI: Xen HVM domU, BIOS 3.4.3-2.6.18 08/29/2012
ACPI: RSDP (v002    Xen                                ) @ 0x00000000000ea020
ACPI: XSDT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0062b0
ACPI: FADT (v004    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005ee0
ACPI: MADT (v002    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc005fe0
ACPI: SRAT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc0060c0
ACPI: SLIT (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006240
ACPI: HPET (v001    Xen      HVM 0x00000000 HVML 0x00000000) @ 0x00000000fc006270
ACPI: DSDT (v002    Xen      HVM 0x00000000 INTL 0x20090220) @ 0x(null)

Os seguintes mostra uma contagem cumulativa desses "travamentos soft" ao longo do tempo recente (o redline é quando eu fiz o último yum updateseguido por reboot): contagem cumulativa de travamentos suaves.

O seguinte mostra o histograma de duração (quanto tempo é o anfitrião preso): histograma de duração.

Pierre D
fonte
1
Toneladas de possíveis razões. Eu tive uma vez em uma instância KVM. A causa foi o driver de rede do host (realtek), que faria algo com altas cargas de rede que a virtualização não esperava, e pronto, você fica preso na CPU nas VMs. Então, basicamente, um bug no driver da rede que acionou outros erros mais adiante. A solução foi mudar para uma versão diferente do kernel (no host) que não desencadeou esse comportamento específico.
Frostschutz 28/03
1
Recebemos essa mensagem de erro, porque algumas VMs tinham mais vcpus configurado do que as CPUs físicas no novo servidor, movemos nosso host Xen para.
Jörg Ludwig

Respostas:

11

Também tenho esse problema no Xen 4.2 com o Kernel 3.6 e 3.8 (AlpineLinux).

Eu pesquisei e adicionando clocksource = jiffies ao meu kernel, eu o consertei. Em vez de jiffies, você também pode tentar "pit".

Há também relatórios de desativação de estados C no BIOS .

Franz Bettag
fonte
4
O que esses parâmetros do kernel fazem?
Burhan Ali
2
O Clocksource parece bastante óbvio para mim e c-states são os estados de energia da CPU.
Franz Bettag 04/04
+1. Desabilitar os estados-c funcionou para mim.
28813 Andrew Ensley
2

Eu tive o mesmo problema com o meu Thinkpad T520. Mas, em vez de cortar o kernel, fiz algo mais simples. Primeiro, estou usando o Centos7. Instalei o sistema básico, tudo funcionou bem. Depois, adicionei a GUI do GNOME mais tarde, quando comecei a obter os problemas mencionados acima. Percebo que muitos fabricantes configurados para instalações do Windows. A placa de vídeo é configurada geralmente para Win7 (NVIDIA OPTIMUS). Eu a redefino para o modo de gráfico integrado e não há mais interrupções / erros. Como fazer isso? Reinicie seu Thinkpad, pressione F1 ou o botão thinkvantage azul para entrar no BIOS. Vá para gráficos, selecione gráficos integrados e, em seguida, F10 para salvar e sair. Existem três configurações para esta placa: Integrada, Discreta e NVIDIA OPTIMUS (somente Win7?) Espero que isso economize algum tempo para alguém?

Cajado
fonte
Suspiro, como quase todo o resto, instalar coisas separadamente é um não-não. De volta à versão inchada da área de trabalho com o Office e outras porcarias :(
killjoy