Sistema travado quando a memória está acabando

34

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

Quando o sistema fica sem memória, ele fica extremamente sem resposta: leva alguns segundos / minutos para fazer coisas como mudar para TTY1 ou até mover o ponteiro do mouse. Às vezes, parece que o sistema congela: três nossos atrás deixei em paz e nada mudou até agora.

Prefiro evitar criar uma partição / arquivo de troca neste eeePC, já que o disco já é muito pequeno e também porque as muitas gravações no espaço de troca reduziriam muito a vida útil do cartão flash. Além disso, acho que um arquivo / partição de swap apenas moveria o problema, em vez de resolvê-lo definitivamente.

O kernel não deveria matar alguns aplicativos aleatórios quando ficar sem memória? Por que falha (ou leva anos) em fazer isso?

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

linux memory freeze

— peoro
fonte

11

Qual DE / WM você está usando na sua instalação, quais serviços / daemons você está executando? Usar um ambiente de área de trabalho completo e navegar com o Chromium ou Firefox, por exemplo, consome sua memória RAM. 1 GB de RAM deve ser suficiente para executar o Arch Linux, mas o que realmente importa é o que você coloca em cima dele.

11

Estou usando o LXDE. O Chromium é o programa que normalmente ocupa a maior parte da RAM. De qualquer forma, este não é o ponto. Não sou eu quem deve se preocupar com a quantidade de memória que meu sistema está usando, é meu sistema que não deve morrer por causa disso. Se meu sistema está com pouca memória, é livre para matar qualquer aplicativo que desejar, eu só quero que não congele !

— peoro

6

Quer dizer, eu estou pensando seriamente sobre a execução de um roteiro como este (em pseudocódigo): while(true){ if( $FREE_MEMORY<10MB ){ kill -9 $RANDOM_PID; } }. Isso definitivamente resolveria o meu problema. Mas espere, o kernel não deveria fazer isso (e de uma maneira muito melhor que o meu script)? Por que não está fazendo o seu trabalho?

— peoro

2

@ Marcin, que apenas moveria o problema, não o corrigirá. Mesmo se eu tivesse 4 GB de memória (graças a alguma troca), meu sistema poderia ficar sem memória (portanto, travando). O que eu quero evitar é o congelamento do meu sistema quando estiver sem memória RAM. Se meu kernel simplesmente matasse cromo assim que minha RAM terminasse, eu ficaria feliz mesmo com os 1 GB que tenho agora.

— peoro

4

@ Lee O "sysrq mágico" é uma combinação de teclas que vai diretamente para o kernel. Isso geralmente funciona mesmo que o teclado e o mouse não respondam. Veja en.wikipedia.org/wiki/Magic_SysRq_key

— Raman

14

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

SysRq-F

A tecla SysRq geralmente é combinada na tecla PrtSc nos teclados.

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

Thx Raman, para obter conselhos sobre esse recurso nos comentários acima.

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

— Arkemlar
fonte

2

Eu tenho a chave PrtScn|SysRq. Mas pressionar SysRq - Fapenas obtém uma captura de tela

— Lee

2

Como você basicamente pegou meu comentário acima e fez uma resposta, uma pequena atribuição teria sido legal. Eu votei em você de qualquer maneira. :-)

— Raman

3

@ Lee Você precisa habilitá-lo. Algumas distribuições não têm o sysrq mágico ativado por padrão. Isso deve ajudar: google.ca/search?q=sysrq+enable

— Raman

2

@Raman Aposto que 99% dos que acham que isso não pode "ativá-lo" por padrão porque a máquina já está congelada ... por que não está ativada por padrão?

— precisa saber é o seguinte

3

@themihai porque muitas pessoas consideram um risco à segurança - ele fornece acesso direto ao kernel via acesso físico a um dispositivo de entrada, independentemente do estado do aplicativo, por exemplo, telas de bloqueio e outros.

— Raman

12

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 frequente 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 do aplicativo que não foram utilizados por um tempo podem ser movidos para o disco: isso é troca.
Os dados dos arquivos usados recentemente são mantidos na RAM: esse é o cache do disco (para leitura de dados do disco) e os buffers do disco (para os dados que estão prestes a serem 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 troca (a troca é necessária apenas se houver uma maneira melhor de usar a RAM).

Em um sistema sem troca, há um momento em que os dados do aplicativo estão usando quase toda a RAM e, portanto, quase não resta espaço para o cache. É provável que o sistema esteja lento. O kernel não começará a matar aplicativos até que realmente precise. Enquanto os aplicativos preencherem apenas 99% da memória disponível, o sistema continuará funcionando, mas muito lentamente porque 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 a troca nesse ponto.

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

Não conheço uma maneira direta de dizer ao kernel para reservar uma quantidade mínima de RAM para o cache do disco. Você pode configurar uma pequena parte da sua RAM como espaço de troca , talvez até compactado . Há relatórios de sucesso nessa frente , embora eu não garanta no seu caso particular.

— Gilles 'SO- parar de ser mau'
fonte

11

Obrigado pela explicação e links, eles ajudaram a tirar algumas dúvidas sobre a troca. Após a resposta do @Marcin à minha pergunta, configurei 256 MB de swap virtual compactado (compcache) na minha RAM. No entanto, isso não responde totalmente à minha pergunta: entendo que meu sistema ficará lento quando toda a RAM for usada apenas pelo aplicativo e nada for armazenado em cache; Ainda não consigo entender por que esse sistema trava por minutos / horas (talvez para sempre?) Quando estou totalmente sem memória RAM. Eu acho que meu kernel não está fazendo seu trabalho em matar aplicativos quando a memória está esgotada, se 3 horas não forem suficientes para mudar para o TTY1.

— peoro

Troquei a desativação com 32 GB de memória física e, quando um software defeituoso foge com a alocação de memória (olá ld, seu pedaço de lixo), ele permanece travado por quase um minuto, acordando apenas o suficiente para me deixar mover o mouse incrivelmente lento por um segundo ou dois a cada vários segundos. O manuseio de OOM do Linux é uma porcaria completa. Se tiver sorte, o assassino da OOM mata o processo certo sem estragar completamente o ambiente da área de trabalho. E eu sou um grande fã do Linux. É muito pior com a paginação ativada. A paginação do Linux é uma piada.

— precisa saber é o seguinte

6

Este é um bug conhecido desde 2007 - consulte Congelamento do sistema com alto uso de memória .

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

— Dan Dascalescu
fonte

2

Parece ser "Não atribuído" no Ubuntu. Talvez o DE deva avisar o usuário ou até congelar o aplicativo com muita memória?

— Nkkollaw

11

@ nbrogi - tudo menos congelar silenciosamente. Mas boa sorte em convencer os desenvolvedores do Ubuntu a fazer isso.

— Dan Dascalescu

6

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

Como o killer do Linux OOM não é capaz de fazer seu trabalho corretamente, comecei a usar o OOM Killer do espaço do usuário: earlyoom . Está escrito em C, bastante configurável e está funcionando como um encanto para mim.

Também ouvi falar de algumas alternativas, como o OOMD do Facebook , desenvolvidas para rodar em seus servidores, mas ainda não tentei.

— peoro
fonte