Servidor travando por razões não tão óbvias

Question

Sistema:

Linux v22017032713145956 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
Este é um servidor virtualizado em execução em um nó com virtualização KVM.

O que eu fiz:

• Eu queria rodar um servidor de jogos da factorio. Então eu baixei e executei. (Isso foi em março)
• Depois de alguns dias, o servidor simplesmente caiu. Eu não tenho nenhum registro disso ao lado de um e-mail perguntando ao meu suporte se uma mensagem do kernel sobre rcu_sched detected stalls on cpu tinha algo a ver com o nó em que o servidor está sendo executado.
• O suporte disse que eu deveria tentar definir o agendador de E / S como noop
• Eu configurei o agendador de acordo (mas apenas temporário, fazendo eco ao noop para o arquivo sys)
• Tudo funcionou bem por cerca de um mês
• Eu fiz atualizações regulares dos repositórios do Debian (apenas jessie e jessie-updates, sem backports ou algo experimental de qualquer tipo)
• Atualizações regulares dos repositórios Froxlor e GitLab.
• O servidor caiu novamente por volta das 4h da manhã do dia 29 de abril, sem motivo aparente.
• Eu reiniciei o servidor a partir do painel de controle do nó no dia 1º de maio.
• Ele caiu novamente no mesmo dia. Desta vez eu não iniciei o servidor factorio nem alterei o agendador de E / S.

Informações adicionais

Respostas de ping

O monitoramento relatou que o servidor não está respondendo a pings entre:

• 04-29-2017 04:07:30 - > 30-04-2017 09:55:46
• 05-01-2017 11:08:52 - > 05-01-2017 11:16:54

Log do kernel

/var/log/kern.log nestes intervalos de tempo:

• de 23 de abril a 30 de abril
• de 1º a 3 de maio
• desde 3 de maio

Tempo de Perguntas

Qual é o problema? Não me lembro de instalar nada. Como posso depurar a mensagem rcu_sched detected stalls ?

Atualização de 7 de maio

Acabei de receber um texto do meu amigo, que o servidor está se comportando de forma estranha. Então eu verifiquei os logs e novamente há barracas. Enviei o registro mais recente .

Atualização de 8 de maio

Eu apenas corri o memtest86 + e não encontrei nada. Mas eu verifiquei o gráfico da CPU dos últimos 31 dias e encontrei algo interessante: Quando o servidor parou de responder a pings, a carga da CPU no núcleo 2 ficou descontrolada, enquanto todos os outros núcleos estavam ociosos. O pico na CPU0 foi o mais importante.

Atualização de 7 de junho

Relatórios de tempo de atividade:
10:05:05 up 27 days, 20:50, 1 user, load average: 0.23, 0.25, 0.18
Mas eu desliguei o GitLab. Alguém tem experiência com o GitLab causando problemas no Debian?

    

Answer 1

Como pode ser visto nos seus logs, eu suponho que seus problemas provavelmente se devam a ter inclusões do VirtualBox Guest instaladas em uma máquina KVM VM e ter algum tipo de conflito.

O módulo do kernel vboxdrv pareceu ser desinstalado e substituído pelos drivers kvm / virtio no pacote antigo, eu acho , e algo que não parecia estar acontecendo no novo para alguma razão.

Como você disse, depois dos logs que você está nos dando, você desinstalou os componentes do Virtual Box.

IMO, você tomou a ação certa. Agora, espere alguns dias para ver se isso acontece novamente.

    

Answer 2

Nos registros, havia alguns NMI, consulte: link

sugerir que você verifique seu hardware também.