Descobri que, ao se deparar com uma situação OOM de falta de memória, minha interface do usuário da caixa linux congela completamente por muito tempo.
Eu configurei a magic-sysrq-key e, em seguida, usando echo 1 | tee /proc/sys/kernel/sysrqe encontrando uma situação OOM->UI-unresponsive foi capaz de pressionar Alt-Sysrq-fque, como o dmesglog mostrou, faz com que o OOM encerre/mate um processo e, com isso, resolva a situação do OOM.
Minha pergunta é agora. Por que o linux não responde tanto quanto a GUI congelou, no entanto, parecia não acionar o mesmo OOM-Killer, que eu acionei manualmente por meio da Alt-Sysrq-fcombinação de teclas?
Considerando que na situação "congelada" do OOM o sistema não responde a ponto de nem mesmo permitir uma resposta oportuna (< 10 segundos) ao pressionar o Ctrl-Alt-F3(alternar para tty3), eu teria que assumir que o kernel deve estar ciente de sua falta de resposta, mas ainda assim não invocou por si só o Alt-Sysrq-fOOM-Killer, por quê?
Estas são algumas configurações que podem ter 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 nem 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 under_oom 0não está claro, ainda )
A razão pela qual o OOM-killer não é chamado automaticamente é porque o sistema, embora completamente lento e sem resposta já quando está perto de falta de memória y, na verdade não atingiu a situação de falta de memória.
Simplificado, o ram quase completo contém 3 tipos de dados:
Em uma situação de falta de memória, o kernel linux, tanto quanto eu posso dizer, é
kswapd0thread do kernel, para evitar perda de dados e perda de funcionalidade, não pode jogar fora 1. e 2. , mas tem a liberdade de remover pelo menos temporariamente aqueles mapeados em- dados de arquivos de memória da ram que são processos de formulário que não estão em execução no momento.Embora este seja um comportamento que envolve o disk-thrashing , constantemente descartar dados e reler do disco, pode ser visto como útil, pois evita, ou pelo menos adia a remoção/eliminação necessária de um processo e a liberação-mas-também- perdendo sua memória, tem um preço alto : desempenho.
é claramente IO caro e o sistema provavelmente não responderá, embora tecnicamente ainda não tenha ficado completamente sem memória.
Do ponto de vista do usuário, como parece, ser travado/congelado e a interface do usuário que não responde pode não ser realmente preferível, em vez de simplesmente matar o processo (por exemplo, de uma guia do navegador, cujo uso de memória pode ter sido a causa raiz/culpado para começar com.)
É aqui que, como a pergunta indicou, o gatilho da tecla Magic SysRq para iniciar o OOM manualmente parece ótimo, pois o Magic SysRq é menos afetado pela falta de resposta do sistema.
Embora possa haver casos de uso em que seja importante preservar os processos a todo custo ( desempenho ), para um desktop, é provável que os usos prefiram o OOM-killer sobre a interface do usuário congelada. Há um patch que afirma isentar arquivos com backup de fs mapeados limpos da memória em tal situação nesta resposta no stackoverflow .
Você pode observar o arquivo /sys/fs/cgroup/memory/memory.oom_control, durante um teste de estresse.
ou
Você pode olhar para a data da última modificação, para ver se foi alterada na época do último bloqueio. Isso lhe dirá se ele estava mesmo tentando fazer seu trabalho.
Esse é o seu problema:
Se definido como 1, significa que está sob controle do oom. Habilitado.
Se definido como 0, assim não está sob controle do oom. Desabilitado.