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 ...


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

Respostas:


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.


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.


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.


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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.