Hoje eu (acidentalmente) executei algum programa na minha caixa Linux que rapidamente utilizou muita memória. Meu sistema congelou, ficou sem resposta e, portanto, não consegui matar o agressor.
Como posso evitar isso no futuro? Não pode pelo menos manter um núcleo responsivo ou algo funcionando?
Respostas:
Aposto que o sistema realmente não "congelou" (no sentido de que o kernel travou), mas não respondeu muito bem. As chances são de que ele estava apenas trocando muito, fazendo com que o desempenho interativo e a taxa de transferência do sistema caíssem como uma pedra.
Você pode desativar a troca, mas isso apenas altera o problema de baixo desempenho para processos eliminados pelo OOM (e toda a diversão que causa), juntamente com a diminuição do desempenho devido ao menor cache de disco disponível.
Como alternativa, você pode usar os limites de recursos por processo (geralmente chamados de rlimite / ou ulimit) para remover a possibilidade de um único processo consumir uma quantidade ridícula de memória e causar trocas, mas isso apenas o leva a um território divertido com processos que morrem em momentos inconvenientes porque eles queriam um pouco mais de memória do que o sistema estava disposto a dar a eles.
Se você soubesse que faria algo que provavelmente causaria grande uso de memória, provavelmente poderia escrever um programa wrapper que mlockall()executasse e executasse seu shell; isso a manteria na memória e seria a coisa mais próxima de "manter um núcleo responsivo" que você provavelmente obterá (porque não é que a CPU esteja sendo superutilizada, esse é o problema).
Pessoalmente, subscrevo o método de controle de recursos "não faça coisas estúpidas". Se você possui root, pode causar todos os tipos de danos a um sistema e, portanto, fazer qualquer coisa que não saiba os resultados prováveis é um negócio arriscado.
ulimitou até mesmo cgroups hoje em dia, se você é um jovem descolado, faz o trabalho muito bem. Se você estiver fazendo alterações nas consultas em produção sem validar seus efeitos em um ambiente não crítico, esse é o seu problema de causa raiz.
Como mencionado acima no comentário de Tronic, é possível chamar o OOM-killer (exterminador de memória) diretamente pela combinação de teclado SysRq- F.
SysRqA tecla geralmente é combinada na PrtSctecla dos teclados.
OOM-killer mata algum processo (-es) e o sistema se torna responsivo novamente. Os acessos diretos ao OOM-killer podem não ser ativados por padrão, verifique esta questão para descobrir como verificar seu status e / ou ativá-lo.
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.
Este é um erro 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.
Se você deseja recompilar o kernel, tente o patch da EDITseção desta pergunta: /programming//q/52067753/10239615
Ele não expulsa as Active(file)páginas durante alta pressão de memória e, portanto, permite o OOM-killer acionar quase instantaneamente porque o kernel não precisa mais gastar minutos de constante leitura em disco das páginas de códigos executáveis de todos os processos, causando um SO congelado.
Isso é algo particularmente difícil de evitar. É porque o kernel começa a trocar. Uma solução é desativar a troca. Quando o sistema ficar sem memória, em vez de começar a trocar, o kernel matará alguns processos; geralmente ele escolhe o processo correto para matar, mas é melhor matar um processo aleatório do que ter um sistema que não responde.
Essa pode ser uma solução particularmente boa para servidores, porque os servidores geralmente têm RAM suficiente e, quando começam a usar o espaço de troca, significa que há algo errado de qualquer maneira. No entanto, os desktops geralmente precisam do espaço de troca, então acho que não há uma boa solução para os desktops. Costumo desativar o espaço de troca nos servidores, principalmente quando há suspeita de vazamento de memória.