É possível fazer o interventor assassino da OOM antes?

Question

Eu tento ajustar meu sistema de desenvolvimento para confiabilidade máxima. Eu desabilitei a troca, porque para o uso da GUI, ela praticamente torna a máquina sem resposta de tal forma que não é mais utilizável. No entanto, se aplicativos agressivos consomem a memória, alguns mecanismos parecem funcionar de forma a tirar o máximo proveito do custo da velocidade. Não há nenhuma operação de troca de disco rígido, mas o sistema também está ficando sem resposta. Então eu quero deixar o assassino da OOM chutar antes que o sistema faça algum esforço especial no ganho de memória. É possível configurar o assassino de OOM para agir se houver menos de 100 MB de memória física livre, por exemplo?

    

Answer 1

Eu também lutei com essa questão. Eu só quero que meu sistema permaneça responsivo, não importa o quê, e eu prefiro perder processos para esperar alguns minutos. Parece não haver nenhuma maneira de conseguir isso usando o kernel oom killer.

No entanto, no espaço do usuário, podemos fazer o que quisermos. Então eu escrevi o Daemon Early OOM ( link ) que matará o maior processo (por RSS) quando a RAM disponível ficar abaixo de 10%.

Sem o earlyoom, foi fácil bloquear minha máquina (8 GB de RAM) iniciando link algumas vezes. Agora, as guias culpadas do navegador são mortas antes que as coisas saiam do controle.

    

Answer 2

A política padrão do kernel é permitir que os aplicativos continuem alocando memória virtual, desde que haja memória física livre. A memória física não é realmente usada até que os aplicativos toquem a memória virtual que alocaram, portanto, um aplicativo pode alocar muito mais memória do que o sistema, e depois começar a tocá-la mais tarde, fazendo com que o kernel fique sem memória e acione a saída de assassino de memória (OOM). Antes que o processo de invasão seja eliminado, ele causou o esvaziamento do cache de disco, o que torna o sistema lento para responder por algum tempo até que o cache seja reabastecido.

Você pode alterar a política padrão para não permitir a supercomprometimento de memória escrevendo um valor de 2 para /proc/sys/vm/overcommit_memory . O valor padrão de /proc/sys/vm/overcommit_ratio é 50, portanto, o kernel não permitirá que os aplicativos aloquem mais de 50% de RAM + swap. Se você não tiver swap, o kernel não permitirá que os aplicativos aloquem mais de 50% do seu RAM, deixando os outros 50% livres para o cache. Isso pode ser um pouco excessivo, então você pode querer aumentar esse valor para dizer, 85% ou mais, então os aplicativos podem alocar até 85% do seu RAM, deixando 15% para o cache.

    

Answer 3

Para mim, configurar vm.admin_reserve_kbytes = 262144 faz exatamente isso. OOM killer intervents antes do sistema ficar completamente sem resposta.

    

Answer 4

As outras respostas têm boas soluções automáticas, mas acho que pode ser útil também ativar a tecla SysRq para quando as coisas saem do controle. Com a chave SysRq , você estaria enviando mensagens manualmente para o kernel, e você pode fazer coisas como uma reinicialização segura (com SysRQ + REISUB ) mesmo se o espaço do usuário estiver completamente congelado.

Para permitir que o kernel ouça solicitações, defina kernel.sysrq = 1 ou ative apenas as funções que você provavelmente usará com um bitmask (documentado aqui ). Por exemplo, kernel.sysrq = 244 habilitará todos os combos necessários para a reinicialização segura acima, bem como a invocação manual do killer da OOM com SysRq + F .

    

Answer 5

A confiabilidade não é atingida por condições de pouca memória e um invasor OOM.

É errado organizar uma festa em um closet e colocar "limpando meu armário" na sua pequena playlist.

Is it possible to make the OOM killer intervent earlier?

Isso terá resultados colaterais involuntários, porque você não tem controle sobre o que é morto.

I try to tweak my development system to maximal reliability.

A confiabilidade máxima envolve testar seu sistema e melhorar seu sistema com base nesses testes.

Apenas alterando coisas aleatórias não vai levar você a lugar algum ...

I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore. Nevertheless, if agressive appications eat up the memory, some mechanisms seem to kick in that making the most out of it on cost of speed.

Devido a condições de pouca memória, desabilitar o swap não irá melhorar o comportamento , faz o oposto .

Para aumentar a confiabilidade nessa situação, adicione mais memória de forma que seu sistema seja mais responsivo e não haja processos aleatórios sendo mortos sem a intenção do usuário. Você não deve recorrer a condições de pouca memória e a um mecanismo como esse, especialmente em um ambiente de desenvolvimento ...

There is no harddrive swap operation, but the system is getting unresponsive likewise.

Condições de pouca memória, de fato, resultam em falta de resposta, independentemente de você ter uma troca ou não.

So I want to let the OOM killer kick in before the system make any special efforts on memory gain.

Esforços especiais que farão mais mal do que bem, como expliquei acima. Em vez disso, você pode matar processos que não precisa de si mesmo, mas acho que não pode fazer isso para que a OOM mate os processos que você precisa.

Is it possible to configure the OOM killer to act if there is less than 100 MB free physical memory for example?

Pode ser, mas você obtém um maior retorno do investimento se comprar apenas uma memória extra que não custa muito atualmente. Considere que você vai se bater no pé a longo prazo, se você continuar a trabalhar em condições de pouca memória. OOM é como um oficial de justiça, não ajuda você, ajuda o sistema operacional ...