Se eu digitar no meu shell x=`yes`, eventualmente obterei cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated)porque yestenta escrever xpara sempre até ficar sem memória. Recebo uma mensagem cannot allocate <memory>porque o OOM-killer do kernel disse que xreallocnão há mais bytes para alocar e que ele deve sair imediatamente.
Mas, quando peço a alguém game_enginepara alocar mais memória gráfica que não existe porque não tenho recursos suficientes, ele recorre à minha RAM e CPU para alocar a memória solicitada.
Por que o OOM-killer do kernel nunca detecta nenhuma game_enginetentativa de alocar toneladas de memória, como acontece com x=`yes`?
Ou seja, se estou executando game_enginee meu usuário não gerou nenhum processo novo desde memory-hog game_engine, por que dito game_enginesempre consegue deixar meu sistema de joelhos irrecuperáveis e sem resposta, sem que o OOM-killer o mate?
Eu uso motores de jogo como exemplo porque eles tendem a alocar toneladas e toneladas de memória em minha pobre placa integrada, mas isso parece acontecer com muitos processos X que consomem muitos recursos.
Existem casos em que o OOM-killer é ineficaz ou incapaz de revogar a memória de um processo?
Responder1
Na verdade, a melhor solução para o assassino OOM é não ter um. Configure seu sistema para não usar memória sobrecarregada e recuse-se a usar aplicativos e bibliotecas que dependam dela. Nestes dias de disco infinito, por que não fornecer troca infinita? Não há necessidade de se comprometer com a troca, a menos que a memória seja usada, certo?
A resposta à sua pergunta pode ser que o assassino OOM não funciona da maneira que você pensa. O assassino OOM usa heurística para escolher qual processo matar, e as regras nem sempre significam que o último solicitante morre. Cf.Domando o assassino OOM. Portanto, não se trata de o assassino OOM ser "ineficaz", mas sim de fazer uma escolha diferente daquela que você prefere.