OOM killer não está funcionando?

41

Pelo que entendi, quando o sistema está perto de não ter memória livre, o kernel deve começar a matar processos para recuperar alguma memória. Mas no meu sistema isso não acontece.

Suponha um script simples que aloque muito mais memória do que a disponível no sistema (uma matriz com milhões de strings, por exemplo). Se eu executar um script como este (como um usuário normal), ele receberá toda a memória até o sistema congelar completamente (apenas o SysRQ REISUB funciona).

A parte estranha aqui é que, quando o computador congela, o led do disco rígido liga e permanece assim até a reinicialização do computador, se eu tiver uma partição swap montada ou não!

Então, minhas perguntas são:

Esse comportamento é normal? É estranho que um aplicativo executado como usuário normal possa travar o sistema dessa maneira ...
Existe alguma maneira de fazer o Ubuntu simplesmente matar automaticamente esses aplicativos quando eles recebem muita (ou mais) memória?

Informação adicional

Ubuntu 12.04.3
Kernel 3.5.0-44

RAM: ~ 3.7GB a partir de 4GB (compartilhado com a placa gráfica). *

$ tail -n+1 /proc/sys/vm/overcommit_*
==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   4194300 344696  -1

kernel

— Salem
fonte

Não sei por que não está funcionando. Tente tail -n+1 /proc/sys/vm/overcommit_*e adicione a saída. Veja aqui também: Como configurar oom-killer

— kiri

Então, o que está acontecendo com seu espaço de troca? Você pode postar alguma saída do vmstat como #vmstat 1 100 ou algo assim? e também mostre-nos cat / etc / fstab O que deve acontecer é com uma certa quantidade de uso de memória, você deve começar a escrever para trocar. Os processos de matança não devem ocorrer até que a memória e o espaço de troca estejam "cheios".

— precisa saber é

tente também #swapon -a

— j0h

@ j0h Com o swap parece funcionar bem (depois de algum tempo, o processo travou com algo parecido Allocation failed). Mas, sem troca, apenas congela o computador. É suposto funcionar desta maneira (apenas matar quando se usa swap)?

— Salem

2

Com o SysRq, você também pode invocar o OOM (SysRq + F iirc)

— Lekensteyn

36

A partir da documentação oficial/proc/sys/vm/* :

oom_kill_allocating_task

Isso habilita ou desabilita a eliminação da tarefa de acionamento do OOM em situações de falta de memória.

Se estiver definido como zero, o killer do OOM examinará toda a lista de tarefas e selecionará uma tarefa com base nas heurísticas a serem eliminadas. Normalmente, isso seleciona uma tarefa desonesta que consome muita memória que libera uma grande quantidade de memória quando é morta.

Se isso estiver definido como diferente de zero, o killer do OOM simplesmente matará a tarefa que acionou a condição de falta de memória. Isso evita a verificação cara da lista de tarefas.

Se panic_on_oom for selecionado, ele terá precedência sobre qualquer valor usado em oom_kill_allocating_task.

O valor padrão é 0.

Para resumir, ao definir oom_kill_allocating_taskpara 1, em vez de varrer seu sistema à procura de processos para matar, o que é uma tarefa cara e lenta, o kernel simplesmente mata o processo que causou a falta de memória no sistema.

De minhas próprias experiências, quando um OOM é acionado, o kernel não tem mais "força" suficiente para fazer essa verificação, tornando o sistema totalmente inutilizável.

Além disso, seria mais óbvio apenas matar a tarefa que causou o problema, por isso não entendo por que ela está definida como 0padrão.

Para testar, basta escrever no pseudo-arquivo adequado /proc/sys/vm/, que será desfeito na próxima reinicialização:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

Para uma correção permanente, escreva o seguinte em /etc/sysctl.confou para um novo arquivo em /etc/sysctl.d/, com uma .confextensão ( /etc/sysctl.d/local.confpor exemplo):

vm.oom_kill_allocating_task = 1

— Teresa e Junior
fonte

2

Sempre foi definido como 0 no Ubuntu? Porque eu lembro que costumava matar automaticamente, mas desde algumas versões ele parou de fazer isso.

— Skerit

11

@skerit Isso realmente não sei, mas foi definido como 0 nos kernels que usei em 2010 (Debian, Liquorix e GRML).

— Teresa e Junior

"Além disso, seria mais óbvio apenas matar a tarefa que causou o problema, por isso não entendo por que está definido como 0padrão". - porque o processo que solicitou memória não é necessariamente aquele que "causou o problema". Se o processo A consumir 99% da memória do sistema, mas o processo B, que usa 0,9%, for o que aciona o assassino da OOM por azar, B não "causa o problema" e não faz sentido kill B. Tendo isso em consideração, a política corre o risco de processos de baixa memória totalmente sem problemas serem mortos por acaso devido ao uso de memória descontrolada de um processo diferente .

— Mark Amery

11

@MarkAmery O verdadeiro problema é que o Linux, em vez de apenas matar o processo necessário, começa a se debater como um retardado, mesmo que vm.admin_reserve_kbytesaumentado para, digamos, 128 MB . A configuração vm.oom_kill_allocating_task = 1parece aliviar o problema, na verdade não o resolve (e o Ubuntu já lida com garfos por padrão).

— Teresa e Junior

11

Talvez mais elegantesudo sysctl -w vm.oom_kill_allocating_task=1

— Pablo A

9

Atualização: O bug foi corrigido.

A resposta de Teresa é suficiente para solucionar o problema e é boa.

Além disso, arquivei um relatório de bug, porque esse é definitivamente um comportamento defeituoso.

— int_ua
fonte

Não sei por que você recebeu voto negativo, mas isso também me parece um bug do kernel. Hoje eu bati um grande servidor universitário com ele e matei alguns processos que estavam em execução há semanas ... Obrigado por preencher esse relatório de erro!

— shapecatcher

7

Pode ter sido corrigido em 2014, em 2018 (e 18.04) o assassino da OOM não está mais fazendo nada.

— Skerit 22/05/19

0

Você pode tentar o earlyoom , um assassino de OOM que opera no espaço do usuário e tenta matar o maior processo em uma situação de OOM.

— qwr
fonte

-1

Antes de tudo, recomendo a atualização para 13.10 (instalação limpa, salve seus dados).

Se você não deseja atualizar, mude o vm.swappiness para 10 e se encontrar problemas com o seu ram, instale o zRAM.

— Brask
fonte

2

Não fui eu quem votou contra você, mas, geralmente, diminuir vm.swappinessfaz mais mal do que bem, ainda mais em sistemas que sofrem de problemas de pouca memória.

— Teresa e Junior

Não quando você comprime a ram primeiro e evita o uso do disco muito mais lento e pode congelar o computador.

— Brask

Em teoria, o zRAM é uma coisa agradável, mas requer muita CPU e geralmente não vale o custo. A memória é geralmente muito mais barata que a eletricidade. E, em um laptop, onde a atualização da RAM é mais cara, o uso da CPU é principalmente indesejável.

— Teresa e Junior

O que ele está pedindo é ter um zRAM do sistema mais estável e a troca de swappiness fará com que o sistema use mais recursos da CPU sim, mas o que ele tem de atm limitado e com erros é a memória, ele quer resolver o problema, não uma lição de teoria. do que acontece quando você instala o zRAM.

— Brask

Fica claro em sua pergunta que ele pode escrever um script impróprio que coma mais do que deveria (e eu já fiz isso sozinho). Em uma situação como essa, você pode assistir ao script capturando gigabytes de RAM em alguns segundos e o zRAM não será resgatado, pois o script nunca será satisfeito o suficiente.

— Teresa e Junior