Eu tenho um servidor Ubuntu 12.04 que às vezes morre completamente - sem SSH, sem ping, nada até que seja fisicamente reiniciado.
Após a reinicialização, vejo no syslog que o oom-killer matou, bem, praticamente tudo.
Há muitas informações detalhadas sobre o uso da memória. Como leio esses logs para ver o que causou o problema do OOM? O servidor tem muito mais memória do que precisa, portanto, não deve ficar sem memória.
Você ficou sem memória em algum lugar , embora eu não tenha idéia de onde (eu não sou tão bom em ler a saída do kernel). Eu acho que você acertou um bug estranho no kernel, honestamente.
— Derobert 29/10
Verifique serverfault.com/questions/564068/linux-oom-situation Há uma ótima resposta.
— seaquest
relacionado: stackoverflow.com/questions/9199731/…
— Ciro Santilli adicionou
O assassino da OOM sugere que, na verdade, você ficou sem memória.
Se você diz que tem mais memória do que precisa, talvez algum evento do sistema esteja criando um vazamento de memória em algum lugar, mas o assassino do OOM não dirá por que há um vazamento de memória, apenas que ficou sem memória e agora tenta matar o mínimo coisas importantes (com base no oom_score ).
E se o caso é que há um vazamento de memória, talvez o Oom-killer apenas mate procs para que o rouge possa alocar mais e mais memória.
Então, o que eu faria no caso, é
Configure o kdump , que criará um despejo de memória vmcore após um pânico no kernel. (está descrito mais aqui )
Definindo vm.panic_on_oom=1parâmetro do kernel. Isso causará pânico no kernel caso a máquina fique sem memória.
Da próxima vez que você entrar em pânico, poderá abrir o arquivo vmcore criado pelo kdump e olhar para a tabela de processos, e ela revelará o culpado.
Quais linhas me dizem que realmente fiquei sem memória? Não duvido de você, só quero saber como interpretar mensagens futuras.
O fato de o OOM-killer ter sido chamado é o que diz isso.
Existem alguns problemas que eu me deparei com os quais o oom-killer é executado SEM falta de memória, como este: bl0rg.krunch.be/oom-frag.html O que eu não sei é como saber condições reais de OOM de coisas assim. Tenho certeza de que está escrito em algum lugar desse log, simplesmente não sei como interpretá-lo.
Ainda acho que para você, a melhor opção ainda é pesquisar no kdump e no vmcore para obter uma captura instantânea da aparência do sistema no momento do erro real. "ps" não é a única ferramenta disponível para você. Além disso, se você criar um tíquete de suporte no ubuntu ou algo assim para chegar ao fundo do problema, eles provavelmente também gostariam de um vmcore para uma análise de causa raiz. Verifique esta página: dedoimedo.com/computers/crash-analyze.html