Sistema suspenso quando fica sem memória

Question

Eu tenho um eeePC 900a: ele tem um flash de 8GB como disco e apenas 1GB de RAM. A distribuição Linux instalada nele é o ArchLinux.

Quando o sistema fica sem memória, ele se torna extremamente sem resposta: são necessários vários segundos / minutos para fazer coisas como alternar para TTY1 ou até mesmo mover o ponteiro do mouse. Às vezes parece que o sistema apenas congela: três anos atrás, eu deixei passar e nada mudou até agora.

Eu prefiro evitar a criação de uma partição / arquivo de swap neste eeePC, já que o disco já é pequeno, e também porque as muitas gravações no espaço de troca encurtariam muito a vida útil da placa flash. Além disso, acho que um arquivo de swap / partição apenas moveria o problema, em vez de definitivamente corrigi-lo.

O kernel não deve matar alguns aplicativos aleatórios quando ficar sem memória? Por que falha (ou leva séculos) ao fazer isso?

Há alguns meses / anos atrás eu já tentei investigar isso, mas não consegui encontrar nada que realmente funcionasse ...

    

Answer 1

É possível chamar diretamente o OOM-killer (killer de memória) pela combinação de teclado:

SysRq-F

A chave SysRq é geralmente combinada dentro da chave PrtSc nos teclados.

OOM-killer mata algum processo (-es) e o sistema se torna responsivo novamente.

Thx Raman para conselhos sobre este recurso nos comentários acima.

PS: Isso me ajudou muito. Eu concordo com a opinião de que este é o conselho mais útil sobre esse problema se for causado pelo Chrome ou qualquer outro software ganancioso de memória. Mas você precisa ter em mente que OOM-killer poderia matar algum processo realmente importante, use-o com cuidado.

    

Answer 2

O estado natural das coisas é que os dados do aplicativo estão na RAM e os arquivos estão no disco.
O estado ideal das coisas, em termos de desempenho, é que os dados em uso freqüente estão na RAM, e os dados que não são necessários no momento estão no disco.
Em um sistema normal, o kernel faz duas coisas para tentar alcançar esse ideal:

• Os dados de aplicativos que não foram usados por algum tempo podem ser movidos para o disco: isso é swap.
• Os dados dos arquivos que foram usados recentemente são mantidos na RAM: esse é o cache de disco (para dados lidos do disco) e os buffers de disco (para dados que estão prestes a ser gravados no disco).

Em um sistema típico, uma parte significativa da RAM é dedicada ao cache e aos buffers (50% é uma figura típica). Como a RAM é um recurso finito, isso pode exigir o deslocamento de alguns dados do aplicativo para swap (a troca é necessária apenas se houver uma maneira melhor de usar a RAM).

Em um sistema sem swap, há um ponto em que os dados do aplicativo estão usando quase toda a RAM e, portanto, quase não resta espaço para o cache. Então o sistema provavelmente será lento. O kernel não começará a matar aplicativos até que seja necessário. Desde que os aplicativos preencham apenas 99% da memória disponível, o sistema continua funcionando, mas muito lentamente, pois os dados dos arquivos precisam ser carregados e recarregados do disco o tempo todo. Com os mesmos aplicativos em execução, o sistema seria mais rápido com swap nesse ponto.

Para saber mais sobre esse problema, consulte esta discussão sobre o lkml e esta postagem no blog .

Eu não sei de uma maneira direta de dizer ao kernel para reservar uma quantidade mínima de RAM para o cache de disco. Você poderia configurar uma pequena parte de sua memória RAM como espaço de troca , talvez até compactado . Existem relatórios de sucesso nessa frente , embora eu não tenha garantias em seu caso particular.

    

Answer 3

Este é um bug conhecido desde 2007 - veja Sistema congelado em alto uso de memória .

Nesta situação, o Windows exibe uma caixa de diálogo avisando o usuário para fechar um ou mais aplicativos.

    

Answer 4

Peoro, eu concordo com você que o sistema deve ter capacidade para gerenciar a memória dependendo da quantidade de recursos que possui e evitar que o sistema fique inoperante devido a falta de recursos. Eu criei recentemente um sistema com 32 GB de RAM. Inicialmente pensado para ser o suficiente para o sistema não ter swap, mas tem pendurado cerca de 1x a cada mês. Eu percebo que ele trava com frequência ao executar a ressincronização de RAID e a verificação de dados mensais. Mais tarde eu aloquei 100GB de swap para evitar travar o sistema. O que eu acho é que o sistema costumava usar a troca e não respondia muito, mas depois que a tarefa terminava, o sistema ficava mais responsivo. Muitas vezes tenho que reinicializar o sistema para torná-lo mais responsivo, porque o sistema não se auto-limpa e reduz o uso de RAM após uma tarefa intensiva. A troca física é certamente a maneira de fazer com que tarefas intensivas aconteçam em velocidade mais lenta, mas o sistema realmente precisa ter melhor controle quando o recurso não é necessário e se corta.

Eu gosto da sua ideia de fazer um script para matar esses processos, mas seria um desastre se você matasse processos importantes que estão sendo executados atualmente por um usuário. Se pudermos eliminar automaticamente os processos inativos quando não forem necessários, isso poderá resolver o problema.

    

Answer 5

Recentemente, encontrei uma solução para o meu problema.

Como o assassino da OOM no Linux não consegue fazer seu trabalho adequadamente, comecei a usar um OOM Killer de espaço de usuário: earlyoom . Está escrito em C, bastante configurável e está funcionando como um encanto para mim.

Eu também ouvi sobre algumas alternativas, como o OOMD do Facebook , desenvolvido para rodar em seus servidores, mas eu não tentei um presente