O Ubuntu no VPS não responde: BUG: bloqueio suave - CPU # 0 preso por 22s

5

Temos um VPS rodando Ubuntu, no Xen. O problema é que, aproximadamente uma vez por dia, por cerca de 20 a 50 minutos, em um tempo aleatório, o servidor se torna completamente indiferente ao mundo externo. Após este período, torna-se responsivo novamente, como se nada tivesse acontecido, não perca tempo de atividade, não reinicie. Ele apenas começa a responder novamente como se estivesse em animação suspensa.

Essas interrupções ocorrem sob condições de memória não excepcional e cpu, por exemplo, 70% mem, 5% cpu. Parei todos os serviços não essenciais para que o uso seja muito uniforme. Essas interrupções não ocorrem particularmente durante períodos de aumento de memória / cpu (durante tarefas diárias), elas às vezes ocorrem em tempos de uso muito baixo de cpu (< 2%), mas no passado também ocorreram durante a troca.

Esses apagões estão ocorrendo tanto no Ubuntu 12.04 LTS quanto no Ubuntu 14.04 LTS - nenhuma alteração (atualizei o Ubuntu especificamente para ver se ele ajudou nesse problema).

É possível fazer login em nosso site de webhosts e usar seu console de administração para ver mensagens de erro durante esse período. Presumivelmente, essas mensagens são da virtualização Xen, a mensagem principal é assim:

BUG: soft lockp - CPU#0 stuck for 22s! [ksoftireqd/0:3] (repeats many times)
SysRq : Emergency Sync (Sometimes this is the only message in the console)

Outros vistos anteriormente em diferentes situações de carga incluem:

BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0] 

(repetido várias vezes) ou:

INFO: rcu_sched detected stall on CPU 0 (t=15000 jiffies) 

(repetido muitas vezes com t ficando maior)

Do googling eu tentei vários parâmetros do kernel, como nohz = off e acpi = off sem sucesso. Tudo o que o suporte técnico disse é que outras instalações do Ubuntu não estão sofrendo o mesmo problema.

Alguém tem alguma ideia ou experiência com este problema?

    
por Blake Walsh 04.06.2014 / 01:47

2 respostas

4

Bem, não encontrei nenhuma solução para esse problema, independentemente do que tentei. No final, substituí o Ubuntu pelo Debian 7.0, e o problema desapareceu, junto com algum uso anormal da CPU que não apareceu na parte superior, mas apareceu no painel de monitoramento do VPS (esse uso da CPU se manifestou como um aumento gradual em torno de 2 3 dias até 10%, seguido de queda para 0%, resultando em um padrão "sawtooth" no gráfico de uso da CPU. Eu fiz não tentar reinstalar o Ubuntu (embora eu tenha tentado atualizar para o 14.04), por causa disso eu não posso dizer com certeza que a substituição do Ubuntu pelo Debian foi a solução. No entanto, o Debian tem sido tão sólido como seria de esperar de sua reputação, infelizmente, eu posso dizer o mesmo para o Ubuntu conhecendo sua reputação. Eu amo o Ubuntu e eu absolutamente amo o Unity, mas parece que o Ubuntu realmente não é estável em uma gama tão ampla de hardware.

Respondi à minha própria pergunta porque 1) Eu encontrei uma solução e 2) não consegui encontrar uma solução em nenhum outro lugar (exceto no caso do CentOS, fazendo o downgrade do CentOS 6 para o CentOS 5) para que isso seja útil se talvez não seja bem-vindo a outras pessoas com esse problema. Eu sei que não ficaria feliz com a solução: substituir o Ubuntu pelo Debian! Mas no final foi o que fiz para resolver o problema. Aliás, eu decidi sobre o Debian porque não encontrei nenhum relato deste problema para o Debian, enquanto encontrei relatos deste problema para o Ubuntu e o CentOS.

    
por 04.07.2014 / 12:50
4

Espero que isso ajude alguém a ver este problema no futuro.

Vivenciamos esse problema em um ambiente semelhante:

  • Ubuntu 14.04 3.13.0 Kernel
  • Ambiente KVM do QEMU

Nosso mestre de cluster do Splunk emitia esses avisos em média a cada cinco minutos. A carga da CPU chegaria a 35% rotineiramente, e os avisos listariam o splunkd ou python como o processo mais provável de ter causado o bloqueio.

Depois de muito puxar o cabelo e ranger de dentes, em desespero, mudamos a configuração do barramento de disco no Virt-Manager de 'virtio' para 'SATA'.

O problema desapareceu.

No momento, ainda estamos monitorando o sistema, mas ele não emitiu mais nenhum aviso desde a mudança (meia hora até agora) e a carga da CPU está estável em torno de 2%.

Eu sei que é um pouco cedo para quebrar o champanhe e os fogos de artifício, mas estamos esperançosos.

    
por 13.08.2014 / 13:28