Aparentemente, o problema estava relacionado a alguns scripts python que faziam o servidor travar. Eu não entendo porque eles enforcaram o servidor, mas pelo menos eles não o penduram mais.
Eu tenho 2 servidores Debian Linux 6.0.4 que têm um comportamento estranho: depois de 5-7-10 dias eles param. Com isso quero dizer que os servidores precisam ser reiniciados e antes que o ping não responda.
Estou lutando com esse problema há alguns meses e eis alguns pensamentos / o que tentei sem conseguir resolver o problema.
Embora eu tenha anos de experiência administrativa, nunca encontrei esse problema e, no momento, não tenho a menor idéia de onde investigar.
Se você tem uma idéia do que eu poderia tentar para corrigir o problema, por favor, compartilhe comigo: -)
Os servidores realmente param ou são inacessíveis pelo ping?
Instale uma ferramenta de monitoramento como Munin (ou similar) que mostrará gráficos não apenas da carga da CPU, mas também das estatísticas de memória, uso do disco e vários outros bits e peças - você pode configurá-lo para monitorar vários aspectos. Nex time o servidor trava, verifique os gráficos para quaisquer sinais incomuns. Você aprenderá a ver como é um gráfico normal, então qualquer coisa fora do comum é suspeita (embora não necessariamente errada).
Tem certeza de que está verificando todos os registros do servidor? ou seja, você tem web / mail / ftp / dns / outros servidores? verifique todos esses registros! Não se esqueça de ativar o registro de depuração durante a solução de problemas.
Se o servidor travar toda semana ou mais, pode ser algo que acontece regularmente, ou seja, uma tarefa cron ou rotação de log, coisas assim.
Certifique-se de obter todos os emails do sistema (alias raiz). Você pode até mesmo instalar o OSSEC, que é uma ótima ferramenta para manter um olho nos logs e receber e-mails quando as coisas dão errado. Mas esta ferramenta OSSEC é apenas uma maneira automatizada de ver os registros, então nada de mágico.
Problemas de rede? a concessão do dhcp expirou?
Por favor, mostre o conteúdo relevante de / var / log / messages e / ou /var/log/kern.log É possível que o kernel registre alguns relatórios de falhas ou algo mais que possa trazer alguma luz. Quando experimentei esses problemas inexplicáveis, isso ocorreu devido a um driver ruim, porque o log não é muito detalhado, não consegui descobrir o driver exato.
No meu caso, houve bloqueios suaves (kernel: [XXXX] BUG: bloqueio suave - CPU # X). Depois de alguma pesquisa eu encontrei o link e o último comentário forneceu algumas dicas e uma maneira de fazer registrando mais detalhado. É uma modificação fácil no kernel, mas se você não se sentir confortável compilando seu próprio kernel, pode não ser a melhor coisa a fazer.
Apenas atualizando o kernel ou instalando uma versão mais nova e reinicializando pode corrigir o problema.
Citações:
We extensively researched the problem.
The TLB flush softlockup is only a CONSEQUENCE of a deadlock.
Background: The TLB flush is issued by a CPU to a number of other CPUs using inter-processor interupts to progagate paging changes. Then the issuing CPU loops until all processor acknowledge the change. If such processor is in deadlock on a spinlock, this never hapens, then the softlockup triggers. The deadlock arise on a spinlock, this lock may be held by user code sometimes (through /proc or /sys interfaces of modules).
The only way to identify the root cause (i.e. which driver is causing problems) is to dump ALL CPU stacks in the soft lockup code.
One way to do that is to modifiy the kernel and add
arch_trigger_all_cpu_backtrace()in the
kernel/softlockup.c:softlockup_tick()function.
This is based on NMI IPI which ensure all stacks are dump, even in the case of deadlock (well don't expect the impossible to happen either).
You should easily find the faulty driver and post the relevant bug.