Depurar fora de memória com / var / log / messages

Question

O seguinte relatório é lançado no meu log de mensagens:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Não importa se esse problema é para httpd , mysqld ou postfix , mas estou curioso para saber como continuar a depuração do problema.

Como posso obter mais informações sobre o motivo da morte do PID 9163 e não tenho certeza se o Linux mantém histórico para os PIDs terminados em algum lugar.

Se isso ocorrer em seu arquivo de log de mensagens, como você resolverá esse problema passo a passo?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103'

    

Answer 1

O kernel registrou um monte de coisas antes que isso acontecesse, mas a maior parte provavelmente não estará em /var/log/messages , dependendo de como o (r)syslogd está configurado. Experimente:

grep oom /var/log/*
grep total_vm /var/log/*

O primeiro deve aparecer várias vezes e o último em apenas um ou dois lugares. Esse é o arquivo que você quer ver.

Encontre a linha original "Falta de memória" em um dos arquivos que também contém total_vm . Trinta segundos a um minuto (poderia ser mais, poderia ser menos) antes dessa linha você encontrará algo como:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Você também deve encontrar uma tabela em algum lugar entre essa linha e a linha "Sem memória" com cabeçalhos como este:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Isso pode não dizer muito mais do que você já sabe, mas os campos são:

• pid O ID do processo.
• uid ID do usuário.
• tgid ID do grupo de tópicos.
• total_vm Uso de memória virtual (em páginas de 4 kB)
• rss Uso de memória residente (em páginas de 4 kB)
• nr_ptes Entradas da tabela de páginas
• swapents Entradas de swap
• oom_score_adj Geralmente 0; um número menor indica que o processo terá menor probabilidade de morrer quando o killer da OOM for invocado.

Você pode ignorar principalmente nr_ptes e swapents , embora eu acredite que esses fatores determinam quem é morto. Isso não é necessariamente o processo que usa mais memória, mas é muito provável que seja. Para mais informações sobre o processo de seleção, veja aqui . Basicamente, o processo que termina com a pontuação mais alta é morto - essa é a "pontuação" informada na linha "Sem memória"; infelizmente as outras pontuações não são reportadas, mas essa tabela fornece algumas pistas em termos de fatores.

Novamente, isso provavelmente não fará muito mais do que esclarecer o óbvio: o sistema ficou sem memória e mysqld foi escolhido para morrer porque matá-lo liberaria a maioria dos recursos . Isso não significa necessariamente mysqld está fazendo algo errado. Você pode olhar a tabela para ver se alguma outra coisa saiu da linha no momento, mas pode não haver nenhum culpado claro: o sistema pode ficar sem memória simplesmente porque você julgou mal ou configurou incorretamente os processos em execução.

    

Answer 2

A chave para isso está na própria mensagem - Sem memória . Quando o kernel do Linux está com falta de memória virtual (RAM física mais swap), ele começa a matar processos e é exatamente isso que aconteceu aqui. Parece que mysqld estava usando mais de 2 GB de memória virtual.

Quanta memória RAM e swap o sistema possui? Eu consideraria adicionar RAM extra ou, se isso não for possível, adicionar swap extra. Como uma solução rápida para, pelo menos, impedir que os processos sejam finalizados, você pode adicionar um arquivo de troca.

Atualização: Olhando para a quantidade de memória RAM que você tem, você pode ver imediatamente o problema. Você tem ~ 1.6GB de RAM e 100MB de swap, mas o MySQL está usando muito mais RAM do que isso. Isso explica por que você está vendo processos sendo finalizados.