O servidor FreePBX (base do sistema operacional central) é bloqueado sem erros ou pânicos do kernel

1

Pouco de uma situação desconcertante com a qual tenho lidado por alguns dias. Eu tenho vários servidores headless CentOS (6.4) com as seguintes estatísticas:

Core

  • CentOS - 6,4 (final)
  • Kernel - 2.6.32-358.14.1.el6.x86_64
  • FreePBX - 4.211.64-9
  • MoBo - Asus P8H61
  • CPU - Intel Core i3 de 3,4 GHz
  • Mem - 8GB Kingston DDR3 800-1600
  • HDD - WD Black 7200 RPM
  • PRI - Dispositivo Digium TE130 800a (rev 02)
  • PRI - Sangoma B600 (1923: 0025)
  • SE Status: desativado (eu sei, eu sei)

    Pacotes

  • libpri-1.4.12-6_centos6.x86_64

  • libpri-debug-info-1.4.12-6_centos6.x86_64
  • libpridevel - 1.4.12-6_centos6.x86_64

  • dahdi-firmware-oct6114-128-1.05.01-119_centos5.noarch

  • dahdi-linux-2.7.0-18_centos6.x86_64

  • wanpipe-7.0.4-kernel.2.6.32.358.14.1.el6.dahdi.2.7.0.rel.49.x86_64
  • dahdi-linux-kmod-debuginfo-2.7.0-45_centos6.2.6.32_358.14.1.el6.x86_64.x86_64
  • dahdi-linux-debuginfo-2.7.0-18_centos6.x86_64
  • dahdi-firmware-oct6114-032-1.07.01-119_centos5.noarch
  • kmod-dahdi-linux-2.7.0-45_centos6.2.6.32_358.14.1.el6.x86_64.x86_64
  • dahdi-firmware-oct6114-256-1.05.01-119_centos5.noarch
  • dahdi-firmware-te820-1.76-119_centos5.noarch
  • dahdi-firmware-vpmoct032-1.12.0-119_centos5.noarch
  • dahdi-firmware-2.5.0.1-119_centos5.noarch
  • dahdi-linux-devel-2.7.0-18_centos6.x86_64
  • dahdi-firmware-xorcom-1.0-1.noarch
  • dahdi-tools-debuginfo-2.7.0-37_centos6.x86_64
  • dahdi-firmware-oct6126-128-01.07.04-119_centos5.noarch
  • dahdi-firmware-oct6114-064-1.05.01-119_centos5.noarch
  • dahdi-firmware-hx8-2.06-119_centos5.noarch
  • dahdi-firmware-tc400m-MR6.12-119_centos5.noarch
  • schmooze-dahdi-1.0.0-2.noarch dahdi-tools-2.7.0-37_centos6.x86_64
  • dahdi-tools-doc-2.7.0-37_centos6.x86_64

Quando esta configuração funciona, funciona muito bem. Dez servidores em locais diferentes executando este mesmo hardware e software de configuração. Três dos dez servidores, no entanto, continuam bloqueando. Ao bloquear, quero dizer completamente sem resposta na rede e nenhuma chamada telefônica pode ser enviada ou recebida. É necessário um desligamento / reinicialização do servidor para que ele se torne operacional novamente.

/ var / log / messages, dmesg e dmesg, old param de gravar quando o sistema trava, mas não há erros, erros de hardware, pânicos, etc nos logs. / var / log / boot mostra uma inicialização normal, apenas alguns avisos sobre o prodígio (que não é usado). / var / log / mcelog está sempre vazio, sem contagem de linhas ou texto. /var/log/freepbx.log mostra linhas INFO normais.

Não há padrão para o período de tempo ou a carga de trabalho dos servidores que se correlacionam ao bloqueio. Às vezes, será por três horas, às vezes por três dias. Sensores show temp está sempre dentro do intervalo e nenhum registro de limite da CPU é registrado. Eu instalei o kdump e configurei os parâmetros do kernel para entrar em pânico com softlockup e pendurar tarefas, bem como com os padrões. O kdump.conf foi alterado para a reinicialização padrão. Quando eu manualmente SYSRQ C (kernel panic), o kdump é acionado e despeja um arquivo de falha (embora por algum motivo ele não seja reinicializado automaticamente depois disso). O uso de SAR para cpu nunca é superior a 5% de utilização, a memória nunca ultrapassa 10% de utilização. O HDD rd_sec atinge o pico em 5.86, o wr_sec atinge o máximo em 120. O Max util tem uma média de 7%.

Eu corri memtester e estresse no sistema, tentando fazê-lo falhar, sem sucesso (o sistema precisa permanecer para cima, se possível). O Memtester rodando com 512M e 50 iterações, até 2048M e 100 iterações, todos testaram "ok" sem problemas.

Não vejo nenhum motivo para o travamento dessas caixas, ou porque o kdump não está sendo acionado (se é um kernel panic). Eu exaurei minhas habilidades de pesquisa de log em tentativas de encontrar uma razão para esse comportamento.

Alguém mais tem uma ideia de onde eu poderia procurar, ou o que eu poderia fazer para identificar o problema aqui, por favor?

    
por PenguinCoder 14.07.2014 / 22:23

0 respostas