killer OOM não funciona corretamente, leva a um sistema operacional congelado

Question

Desde que anos, o killer da OOM do meu sistema operacional não funciona corretamente e leva a um sistema congelado.
Quando o uso de memória é muito alto, todo o sistema tende a congelar por horas ou até dias (o máximo que gravei é 7 dias antes de um reset), em vez de matando processos para liberar a memória.
Nesta situação, o iowait é muito, muito alto (~ 70%).
A ferramenta: iotop mostrou que todos os programas estão lendo com uma taxa de transferência muito alta (por dezenas de MB / s) do meu disco rígido.
O que esses programas estão lendo?
A hierarquia de diretórios?
- O código executável em si?
Eu não sei exatamente agora.

Eu uso um ArchLinux uptodate (atualmente: 4.9.27-1-lts), tenho 16 GB de ram físico, e nenhuma partição swap ativada.
Por causa da quantidade de memória RAM que tenho, não quero ativar uma partição de troca, pois isso atrasaria a aparição do problema.

Para mim, o problema é causado pelo fato de que o Linux descarta dados essenciais dos caches , o que leva a um sistema congelado porque ele precisa ler tudo, sempre do disco rígido.

Eu até me pergunto se o Linux não descartaria as páginas de códigos executáveis dos programas em execução, o que explicaria por que os programas que normalmente não lêem muitos dados se comportam dessa maneira nessa situação.

Eu tentei várias coisas na esperança de corrigir esse problema.
Uma era definir /proc/sys/vm/min_free_kbytes para 1000000 (1 GB).
Como esse 1 GB deve permanecer livre, achei que essa memória seria reservada pelo Linux para armazenar em cache dados importantes.
Mas isso não funcionou.

Além disso, acho útil acrescentar que, mesmo que pareça ótimo na teoria, restringir o tamanho da memória virtual ao tamanho da memória física, definindo /proc/sys/vm/overcommit_memory to 2 não é tecnicamente possível minha situação, porque o tipo de aplicativos que eu uso, requer mais memória virtual do que eles usam efetivamente por alguns motivos. De acordo com o arquivo /proc/meminfo , o valor Commited_AS é geralmente maior que o dobro da memória física do meu sistema (16 GB, Commited_AS geralmente é > 32 GB).

Eu experimentei esse problema com /proc/sys/vm/overcommit_memory para seu valor padrão: 0 , e desde há algum tempo eu o defini para: 1 , porque eu prefiro que os programas sejam mortos pelo killer da OOM em vez de se comportarem mal porque não verificam os valores de retorno de malloc , quando as atribuições são recusadas.

Quando eu estava falando sobre este problema no IRC , eu conheci outros usuários Linux que tiveram este mesmo problema, então eu acho que muitos usuários estão preocupados com isso. Para mim isso não é aceitável, já que até o Windows lida melhor com alto uso de memória.

Se precisar de mais informações, tenha uma sugestão, por favor, diga-me.

    

Answer 1

Eu encontrei duas explicações (da mesma coisa) a respeito de porque o kswapd0 faz a leitura constante do disco acontece bem antes que o OOM-killer elimine o processo problemático:

1. veja a resposta e o comentário de esta resposta do askubuntu SE
2. veja a resposta e os comentários de David Schwartz sobre esta resposta no unix SE

Vou citar aqui o comentário de 1. que realmente abriu meus olhos sobre porque eu estava recebendo leitura constante do disco enquanto tudo estava congelado :

For example, consider a case where you have zero swap and system is nearly running out of RAM. The kernel will take memory from e.g. Firefox (it can do this because Firefox is running executable code that has been loaded from disk - the code can be loaded from disk again if needed). If Firefox then needs to access that RAM again N seconds later, the CPU generates "hard fault" which forces Linux to free some RAM (e.g. take some RAM from another process), load the missing data from disk and then allow Firefox to continue as usual. This is pretty similar to normal swapping and kswapd0 does it. – Mikko Rantalainen Feb 15 at 13:08

Se alguém tiver uma maneira de desabilitar esse comportamento (talvez recompile o kernel com quais opções? ) , Por favor deixe-me saber o mais rápido possivel! Muito apreciado, obrigado!
EDIT: Acabei de encontrado vm.overcommit_memory=2 evita a debulha do disco que leva ao SO congelado (mesmo que o OOM-killer não tenha uma mudança para acionar, o que faz sentido, porque ele só é acionado bem depois da surra de disco, com vm.overcommit_memory=0 ) como: cc1plus: out of memory allocating 127440 bytes after a total of 897024 bytes
EDIT2 ok o acima funcionou para mim com o padrão vm.overcommit_ratio=50 mas se eu configurá-lo para 200 então o disk-thrashing está de volta!
EDIT3 ignora essas 2 EDITs, elas não são o caminho para consertar isso porque processos que não teriam morrido antes morrem agora mais cedo, também vm.overcommit_ratio=0 fará com que tudo morra, ou alguma coisa. Tentarei encontrar uma maneira melhor, provavelmente precisando de recompilação do kernel e estou pesquisando os sinalizadores GFP relevantes ...
EDIT4: Eu encontrei uma maneira, através do patch de kernel, que funciona para mim; veja o patch em esta pergunta.

    

Answer 2

Acredito que este foi um bug do kernel corrigido antes de 4.14.58 / 4.9.115; Eu tive problemas semelhantes perto da versão que você informou, que agora estão corrigidos.