É possível fazer com que o assassino do OOM intervenha mais cedo?

34

Eu tento ajustar meu sistema de desenvolvimento para a confiabilidade máxima. Desabilitei o swap, porque, para o uso da GUI, ela geralmente deixa a máquina sem resposta, de tal maneira que não é mais utilizável. No entanto, se aplicativos agressivos consomem a memória, alguns mecanismos parecem funcionar, tirando o máximo proveito disso no custo da velocidade. Não há operação de troca do disco rígido, mas o sistema está ficando sem resposta da mesma forma. Então, quero deixar o assassino da OOM entrar em ação antes que o sistema faça esforços especiais no ganho de memória. É possível configurar o killer OOM para agir se houver menos de 100 MB de memória física livre, por exemplo?

linux-kernel memory-management

— dronus
fonte

2

Penso que o verdadeiro problema aqui é que não há RAM suficiente para começar. Você não usará swap, a menos que não haja ram. Ao desativar o swap ... você fica sem memória ram e não tem para onde paginar. O que faz com que coisas feias aconteçam. Seu sistema parece estar mal configurado e nenhuma quantidade de ajustes corrigirá isso.

— Journeyman Geek

8

Eu não concordo Desenvolvimento e 'uso de energia' geralmente envolvem uso experimental. Por exemplo, ao usar uma ferramenta de processamento de imagem de linha de comando, não há especificações quanto de memória sua operação leva em relação ao tamanho da imagem. Então eu apenas dou uma chance. E não espero que torne toda a minha máquina inútil. Para um único experimento, eu poderia usar o ulimit para mantê-lo seguro, mas para toda a operação do sistema, às vezes com muitas operações, a contenção de um processo não é tão útil, mas definitivamente é um 'seguro de vida' para toda a máquina.

— 21412 dronus

1

O fato de seu sistema ser interrompido ao usar a troca é suspeito. Seu computador está usando o swap porque está sem memória. A troca está diminuindo, pois o acesso ao disco é lento. O acesso ao disco é lento devido a ???. Seus problemas até o fim. Não é apenas que você esteja com pouca memória RAM. É que você não pode usar a única maneira de mitigar isso devido a outra coisa.

— Journeyman Geek

7

@JourneymanGeek, você está fora no campo esquerdo. Os discos são lentos em comparação com a ram, ponto final; portanto, as trocas pesadas sempre atrapalham o sistema. É claro que ele está sem memória porque tentou executar um programa que usa muita memória. A questão é o que fazer quando estiver sem memória? Mate o porco ou diminua a velocidade devido à falta de memória para o cache do disco.

— 31412 psusi

2

@ TomWijsman, o IO do disco é muitas ordens de magnitude mais lento que o IO da memória, portanto, o uso da troca de disco sempre significou uma grande desaceleração. Às vezes (especialmente nos velhos tempos em que o carneiro era caro e a maioria das pessoas não tinha muito), é preferível não poder fazer o que você estava tentando. Hoje em dia, o disco é MUITO mais lento que o RAM, e o RAM é barato o suficiente para a maioria das pessoas. Por isso, nas raras ocasiões em que eles executam acidentalmente algo que usa mais RAM do que eles, geralmente é melhor desistir do que levar 1000 vezes o tempo necessário para fazê-lo.

— psusi 29/03/12

36

Eu também lutei com esse problema. Eu só quero que meu sistema permaneça responsivo, não importa o que aconteça, e prefiro perder processos do que esperar alguns minutos. Parece não haver maneira de conseguir isso usando o kernel oom killer.

No entanto, no espaço do usuário, podemos fazer o que quisermos. Então, escrevi o Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) 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 o http://www.unrealengine.com/html5/ algumas vezes. Agora, as guias culpadas do navegador são mortas antes que as coisas saiam do controle.

— Jakob
fonte

3

Obrigado por coçar esta coceira! Amar cedo até agora.

— Thomas Ferris Nicolaisen

1

Acabei de descobrir que o Android faz o mesmo por um longo tempo. Não tenho certeza se ele está usando um código personalizado como o seu para isso.

— Dronus 23/05

1

Estou testando earlyoomagora, ele se sai bem em um primeiro teste de gatilho. Apenas me pergunto por que isso não pode ser implementado pela configuração do kernel ou pelas ferramentas do sistema.

— Dronus 23/05

12

A política padrão do kernel é permitir que os aplicativos continuem alocando memória virtual enquanto houver memória física livre. A memória física não é realmente usada até que os aplicativos toquem na memória virtual que eles alocaram, para que um aplicativo possa alocar muito mais memória do que o sistema, em seguida, comece a tocá-lo mais tarde, fazendo com que o kernel fique sem memória e ative a saída assassino de memória (OOM). Porém, antes que o processo de hogging seja interrompido, o cache do disco é esvaziado, o que torna o sistema lento para responder por um tempo até que o cache seja recarregado.

Você pode alterar a política padrão para proibir a confirmação excessiva de memória, escrevendo um valor de 2 em /proc/sys/vm/overcommit_memory. O valor padrão /proc/sys/vm/overcommit_ratioé 50, portanto o kernel não permitirá que os aplicativos aloquem mais de 50% do ram + swap. Se você não tiver troca, o kernel não permitirá que os aplicativos aloquem mais de 50% de sua memória RAM, deixando os outros 50% livres para o cache. Isso pode ser um pouco excessivo, então você pode aumentar esse valor para aproximadamente 85%, para que os aplicativos possam alocar até 85% da sua memória RAM, deixando 15% para o cache.

— psusi
fonte

1

A alteração desses valores a partir dos padrões sem base teórica não será alcançada em um sistema mais confiável; você só pode justificar essa alteração com estatísticas apropriadas. Só porque você pode mudar isso não significa que você deveria. Se você está constantemente em condições de pouca memória, isso significa que você está usando mais memória do que você tem e deve comprar mais memória, isso não significa que você deve mexer nas configurações e matar aplicativos aleatórios. Interrompendo com o seu trabalho diário ou a introdução de corrupção, isso não é realmente o caminho a percorrer ...

— Tamara Wijsman

3

@TomWijsman, a pergunta deixa claro que ele não está constantemente em condições de pouca memória; ele apenas executa um comando que requer uma quantidade inesperadamente grande de memória. Comprar mais memória não é a única solução quando você acabar. Outras soluções possíveis incluem encontrar maneiras melhores de usar a memória que você possui, ou simplesmente não fazer o que precisar de tanta memória. A questão deixa claro que o último é mais aceitável do que sair e comprar mais carneiro.

— psusi 29/03/12

Qual linha da pergunta deixa isso claro? Eu vejo o oposto cedido I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Ele mencionou a GUI, enquanto você assume que ele executa um comando. Comprar mais memória é a primeira solução, usar menos memória é a segunda solução, tornar o sistema instável, mexendo nos padrões estáveis, é a última solução. A pergunta não precisa ser respondida literalmente, então não vejo qual é o seu problema, pois você deve nos incomodar nos comentários. Rant não ajuda ...

— Tamara Wijsman

4

Ei, essa resposta parecia bem legal. Infelizmente, o 'commit' refere-se à demanda de memória virtual que parece, o que é bastante ruim estimado pelos programadores de aplicativos. Por exemplo, com meu (sem swap) desktop rodando, há cerca de 400 2000MB de memória física usada, mas 1600mb 'commit'ted como /proc/meminfo' s Committed_ASestados. Com alguns aplicativos em execução, esse valor excede facilmente a memória física, por isso é difícil definir um limite viável para isso.

— 21412 dronus

3

Salve seu trabalho antes de tentar isso! : O PI teve falhas imediatas em tudo (bash, gerenciador de janelas etc.).

— jozxyqk

8

Para mim, definir vm.admin_reserve_kbytes = 262144 faz exatamente isso. OOM killer intervém antes que o sistema fique completamente sem resposta.

— Michael Vigovsky
fonte

1

Eu gosto da ideia, mas isso significa que você nunca tem 256MiB de memória física usada?

— Jérôme Pouiller

1

256MiB será usado para caches. Os caches são realmente importantes, não se trata apenas de correr mais rápido, o sistema não funcionaria se não houvesse memória suficiente para os caches. O código de todos os programas em execução pode ser descarregado da memória, pois é mmapedado e pode ser lido de volta no disco. Sem caches, cada alternador de tarefas exigirá leitura de disco e o sistema ficará completamente sem resposta.

— Michael Vigovsky

4

As outras respostas têm boas soluções automáticas, mas acho que também pode ser útil ativar a SysRqchave para quando as coisas ficarem fora de controle. Com a SysRqchave, você enviaria mensagens manualmente para o kernel e poderá fazer coisas como uma reinicialização segura (com SysRQ + REISUB) mesmo que o espaço do usuário esteja completamente congelado.

Para permitir que o kernel ouça solicitações, defina kernel.sysrq = 1ou habilite apenas as funções que você provavelmente usará com uma máscara de bits (documentada 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 OOM killer SysRq + F.

— timuzhti
fonte

-2

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

É errado organizar uma festa em um armário e colocar "limpando meu armário" em sua pequena lista de reprodução.

É possível fazer com que o assassino do OOM intervenha mais cedo?

Fazer isso terá resultados colaterais indesejados, porque você não tem controle sobre o que é morto.

Eu tento ajustar meu sistema de desenvolvimento para a confiabilidade máxima.

A confiabilidade máxima envolve testar seu sistema e aprimorá-lo com base nesses testes.

Apenas ajustar coisas aleatórias não o levará a lugar algum ...

Desabilitei o swap, porque, para o uso da GUI, ela geralmente deixa a máquina sem resposta, de tal maneira que não é mais utilizável. No entanto, se aplicativos agressivos consomem a memória, alguns mecanismos parecem funcionar, tirando o máximo proveito disso no custo da velocidade.

Devido a condições de pouca memória, desabilitar a troca não melhorará o comportamento , mas o contrário .

Para aumentar a confiabilidade nessa situação, adicione mais memória para 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 não em um ambiente de desenvolvimento ...

Não há operação de troca do disco rígido, mas o sistema está ficando sem resposta da mesma forma.

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

Então, quero deixar o assassino da OOM entrar em ação antes que o sistema faça esforços especiais no ganho de memória.

Esforços especiais que farão mais mal do que bem, como expliquei acima. Em vez disso, você pode matar processos dos quais não precisa, mas acho que você não pode fazer isso, para que o OOM acabe com os processos necessários.

É possível configurar o killer OOM para agir se houver menos de 100 MB de memória física livre, por exemplo?

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

— Tamara Wijsman
fonte

7

É claro que desabilitar a troca melhora o comportamento porque, em vez de debulhar o disco, o OOM entra em ação e mata o porco da memória. Ficar sem memória ram não é o problema (e adicionar mais significa apenas que você precisa se esforçar mais para se esgotar). O problema é o que fazer quando você acabar. Você deseja que o OOM mate o porco e, assim, alivie a condição de pouca memória.

— 31412 psusi

7

Porque matar um aplicativo que está tentando usar mais memória do que você tem é preferível deixar todo o sistema de joelhos. Em um mundo perfeito, você teria memória ilimitada e nunca se esgotaria, mas, na realidade, às vezes se esgota por acidente e prefere receber "memória insuficiente" do que interromper o sistema.

— Psusi 29/03/12

5

A compra de memória extra pode resolver alguns problemas, dependendo da quantidade comprada. Mas isso não muda o fato de que pode haver usos inesperados por ordens de magnitude. Então, eu quero que o aplicativo falhe, mas NÃO o sistema nessas condições. Alguns exemplos: processe uma pasta cheia de imagens compactadas, a maioria com tamanho "normal", mas algumas com tamanho muito grande. Um pequeno erro pode fazer um loop morto com a fuga de memória consumindo 1 GB / s. Abra acidentalmente um arquivo de vídeo em um editor de texto. Normalmente este termina com sintomas como rato jerky e UI quase morto até o Oom entra em ação.

— dronus

6

@TomWijsman também existem loops quase mortos, pois existem algoritmos que se comportam lineares no caso médio, mas exponenciais no pior caso, dependendo dos dados de entrada. E não posso enviar um sinal de interrupção se o mouse estiver irregular e clicar, assim como a entrada do teclado mostra uma latência de um minuto. Normalmente, mudo para um terminal em modo de texto e espero alguns minutos para que o login prossiga apenas para emitir um tipo killcego.

— 21412 dronus

7

Não tenho problemas em matar aplicativos que ficariam mortos também. Considere um sistema com troca física de 2 GB + troca de 2 GB. Um aplicativo que acaba rapidamente com a memória física também pode facilmente consumir a troca. Ele morreria mais tarde, depois de deixar o sistema sem resposta por minutos a horas. Então, por que não matá-lo rapidamente antes que a operação da GUI fique esquisita? Muitos processos fazem todo o seu trabalho com 10mb, alguns levam 1gb e outros raros precisariam de 10gb, isso é a vida.

— 21412 dronus