Obtenha um despejo básico / depuração de um processo morto pelo oom-killer

10

Existe alguma maneira de obter um despejo básico ou poder depurar um processo que foi morto pelo oom-killer?

Ou até mesmo defina oom-killer para tentar matar um processo usando o ABRT?

oom dump

— TrapAlice
fonte

5

Outra abordagem é desativar o comprometimento excessivo da memória.

Para restaurar alguma aparência de sanidade ao seu gerenciamento de memória:

Desabilitar o OOM Killer (Coloque vm.oom-kill = 0em /etc/sysctl.conf)

Desativar overcommit memória (Coloque vm.overcommit_memory = 2em /etc/sysctl.conf)

Essas configurações farão o Linux se comportar da maneira tradicional (se um processo solicitar mais memória do que o disponível malloc(), falhará e o processo que solicita a memória deve lidar com essa falha).
Observe que este é um valor ternário:

0 = "estimativa se tivermos RAM suficiente"

1 = "Sempre diga sim"

2 = "diga não se não tivermos memória"

Isso forçará o aplicativo a lidar com a falta de memória e, possivelmente, seus logs / coredump / etc. podem fornecer algo útil.

ATUALIZAÇÃO # 1

NOTA: Quando o sistema ficar sem memória, você não poderá gerar novos processos! Você pode estar bloqueado para fora do sistema.

— nishantjr
fonte

Esta é uma péssima ideia. A maioria dos softwares em execução no sistema provavelmente não lida com o valor de retorno da falha de alocação de memória corretamente. Isso fará com que caminhos de código que praticamente nunca sejam executados por alguém sejam executados e, na pior das hipóteses, possa introduzir vulnerabilidades de segurança em seu sistema ao executar esses caminhos de código inesperados e não testados.

— KJ Tsanaktsidis

4

echo 1 > /proc/sys/vm/oom_dump_tasks

que parece o máximo que você pode obter no kernel para exibir erros de falta de memória.

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Permite que um dump de tarefas em todo o sistema (excluindo threads do kernel) seja produzido quando o kernel executa uma eliminação de OOM e inclui informações como pid, uid, tgid, tamanho da vm, rss, nr_ptes, swapents, pontuação oom_score_adj e nome. Isso é útil para determinar por que o assassino do OOM foi chamado, para identificar a tarefa não autorizada que o causou e para determinar por que o assassino do OOM escolheu a tarefa que executou para matar.

Se isso estiver definido como zero, essas informações serão suprimidas. Em sistemas muito grandes com milhares de tarefas, pode não ser possível despejar as informações do estado da memória de cada uma. Esses sistemas não devem ser forçados a incorrer em uma penalidade de desempenho em condições OOM, quando as informações podem não ser desejadas.

Se isso estiver definido como diferente de zero, essas informações serão mostradas sempre que o assassino do OOM realmente matar uma tarefa que consome muita memória.

— HBruijn
fonte