Por que o killer do out-of-memory (OOM) do linux não é executado automaticamente, mas funciona com o sysrq-key?

Question

Descobri que, ao se deparar com uma situação OOM de falta de memória, minha interface de usuário da interface linux se congela completamente por um longo tempo.

Eu configurei a magic-sysrq-key usando echo 1 | tee /proc/sys/kernel/sysrq e encontrando uma situação OOM- & ##########################################****************************************************************** processo e por isso resolver a situação OOM.

Minha pergunta é agora. Por que o linux não responde tanto quanto a GUI congelou, no entanto, parece não acionar o mesmo OOM-Killer, que eu acionei manualmente via combinação de teclas Alt-Sysrq-f ?

Considerando que na situação OOM "congelada" o sistema não responde a ponto de nem permitir que uma resposta oportuna (< 10sec) atinja o dmesg (mude para tty3), eu teria que assumir que o kernel deve estar ciente de sua falta de resposta, mas ainda não invocou por si só o Alt-Sysrq-f OOM-Killer, por quê?

Estas são algumas configurações que podem ter um impacto no comportamento descrito.

$> mount | grep memory
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
$> cat /sys/fs/cgroup/memory/memory.oom_control 
oom_kill_disable 0
under_oom 0
oom_kill 0

que enquanto eu entendo afirma que o cgroup de memória não tem OOM neithe ativado nem desativado (evidentemente, deve haver uma boa razão para ter o OOM_kill ativo e desativado, ou talvez eu não possa interpretar corretamente a saída, também o Ctrl-Alt-F3 é um pouco incerto, ainda)

    

Answer 1

A razão pela qual o OOM-killer não é chamado automaticamente é, porque o sistema, embora completamente desacelerado e sem resposta já quando próximo a falta de memória y, não atingiu realmente o situação de memória.

simplificado demais, o RAM quase completo contém 3 tipos de dados:

1. dados do kernel, isso é essencial
2. páginas de dados essenciais do processo (por exemplo, quaisquer dados que o processo criou apenas em memória RAM)
3. páginas de dados de processo não essenciais (por exemplo, dados como o código de executáveis, para os quais há uma cópia no disco / no sistema de arquivos e que, embora atualmente mapeados para a memória, podem ser "relidos" do disco no momento do uso )

Em uma situação de falta de memória, o kernel do linux, tanto quanto eu posso dizer, é kswapd0 kernel thread, para evitar perda de dados e perda de funcionalidade, não posso descartar 1. e 2., mas está livre para pelo menos temporariamente remova os dados de arquivos mapeados em memória de ram que são processos de formulário que não estão atualmente em execução.

Embora este seja um comportamento que envolva disco-thrashing , para jogar dados fora constantemente e relê-los disco, pode ser visto como útil, pois evita, ou pelo menos adia, a remoção necessária / morte de um processo e a liberação de sua memória, mas tem um preço alto : desempenho .

[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ] 
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ] 
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]

é claramente IO caro e o sistema provavelmente não responderá, apesar de tecnicamente ainda não ter esgotado de memória.

De uma perspectiva do usuário, aparentemente, ser travada / congelada e a UI resultante sem resposta pode não ser realmente preferível, simplesmente matando o processo (por exemplo, de uma guia do navegador, cujo uso da memória pode ter sido a causa raiz / culpado para começar.)

É aqui que, como a pergunta indicou, o gatilho Magic SysRq para iniciar a OOM manualmente parece ótimo, como o Magic O SysRq é menos impactado pela falta de resposta do sistema.

Embora possa haver casos de uso em que é importante preservar os custos de todos os processos ( desempenho ), para um desktop, é provável que os usuários preferissem o OOM-killer sobre o congelado UI. Existe um patch que reivindica a isenção de arquivos fs limpos e mapeados da memória em tal situação nesta resposta em stackoverflow .

    

Answer 2

Você pode assistir ao arquivo /sys/fs/cgroup/memory/memory.oom_control, durante um teste de estresse.

ou

Você pode ver a data da última modificação, para ver se ela foi alterada por volta do horário do último bloqueio. Isso lhe dirá se estava mesmo tentando fazer o trabalho.

under_oom 0

Esse é o seu problema:

under_oom    0 or 1 (if 1, the memory cgroup is under OOM, tasks may
             be stopped.)

Se definido como 1, significa que está sob controle total. Ativado.
Se definido como 0, assim não está sob controle. Desativado.