O Linux Centos 6 fica indisponível de tempos em tempos - problema de sistema operacional e rede

2

Estou encontrando o seguinte problema. Há um servidor (DL160 G5) rodando o Centos 6.3 com o kernel padrão 2.6.32-220.2.1.el6.x86_64 - neste momento eu gostaria de acrescentar que o problema apareceu também na versão anterior - 6.1 e kernel antigo (não lembre-se exatamente qual versão). Há o cPanel instalado e, de tempos em tempos, ele fica indisponível (conexão de rede). O que eu verifiquei é (via KVMoIP):

  • a média de carga é completamente normal
  • não falta memória ou espaço em disco quando ocorre um problema
  • não há notificações do console
  • verificou todos os logs de acesso e não há sinal de que isso pode ser causado por um script de cliente
  • não pode acessar a interface local (127.0.0.1) nem o endereço IP principal
  • executando o tcpdump só consigo ver pacotes chegando ao servidor - sem respostas
  • todos os serviços parecem estar funcionando corretamente (mail, sql, http, ssh)
  • crontab marcado e crontabs de todos os clientes também
  • a utilização da porta de rede é baixa (até vários Mbits)
  • a taxa de pacotes chegando é baixa - centenas por segundo (de acordo com o tcpdump)
  • console (via kvmoip) funciona bem, sem atrasos
  • não há conntrack neste servidor
  • não há ipv6 neste servidor
  • descarregando iptables, os módulos de descarga não resolvem o problema
  • reiniciar a rede não resolve o problema, nenhum erro aparece
  • também ocorre quando duas redes separadas são configuradas (e vários gateways), bem como um IP, um gw padrão e uma rede configurada - portanto, parece uma configuração de rede independente
  • parece repetir aleatoriamente (carga, taxa de pacotes, uso de largura de banda, independente de carga)
  • servidor verificado com diferentes ferramentas de detecção de rootkit - parece estar limpo
  • servidor foi reinicializado, não alterou nada
  • não há erros de interface
  • os apperas aleatoriamente podem ser uma vez por semana ou várias vezes por dia

Geralmente funciona bem após 1-15 minutos. O que eu também posso verificar? É definitivamente questão do sistema operacional - há tráfego na interface apenas em uma direção quando o problema ocorre, não pode sequer pingar loopback. Alguma ideia? Verificações recomendadas? Qualquer coisa que eu não verifiquei acima.

    
por adoado0 22.10.2013 / 16:32

2 respostas

2

É muito improvável, mas recentemente tive um problema em que, em intervalos aleatórios, certos sistemas experimentavam um tempo de CPU "SYSTEM" muito alto, o que era ruim o suficiente para que as ferramentas de cluster presumissem que o sistema estivesse inoperante e interrompessem problemas.

Durante o problema, tente top e clique em 1 para expandir as CPUs, e verifique se um ou mais processadores estão indicando um comportamento estranho.

Isso é o que parece se esse problema estiver em vigor. Observe o alto valor "sy".

Cpu0  : 16.7%us, 25.0%sy,  0.0%ni, 50.0%id,  0.0%wa,  0.0%hi,  8.3%si,  0.0%st
Cpu1  : 28.6%us, 42.9%sy,  0.0%ni, 28.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  6.0%us, 11.3%sy,  0.0%ni, 80.5%id,  0.0%wa,  0.0%hi,  2.3%si,  0.0%st
Cpu3  : 20.0%us, 60.0%sy,  0.0%ni, 20.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Você também pode executar dstat -talm (talvez passar por segundo e redirecionar para um arquivo) para obter estatísticas por segundo que podem ajudar a diagnosticar o problema, caso você não consiga ver corretamente. / p>

Note que, para o meu problema, acabei trabalhando com o suporte da Red Hat por semanas, e eventualmente tentei instalar uma versão de patch mais recente do kernel, que era a resolução.

    
por 22.10.2013 / 18:38
1

O CentOS ou qualquer variação do Linux não faz isso apenas por diversão. Há um problema de hardware subjacente.

Meu palpite é que seu servidor é um VMware ou outro convidado virtualizado e o problema ocorre enquanto um instantâneo de convidado é tirado.

Sua lista de marcadores era bastante longa, mas não mencionava registros. Algo interessante em dmesg output ou em /var/log ?

    
por 22.10.2013 / 16:42