É possível acionar o OOM-killer em trocas forçadas?


26

É possível que o sistema troque preventivamente páginas inativas ( vm.swappiness), mas invoque o oom-killer quando o sistema ficar sem memória RAM (em vez de ficar sem memória) e forçado a trocar?

O objetivo final é impedir que o sistema seja interrompido quando ele começar a danificar o disco devido a falhas importantes nas páginas, mas ainda assim permitir que as páginas inativas sejam trocadas.

Outro desejo seria configurar quanta memória de troca o sistema é forçado a usar antes que o oom-killer seja acionado. Dessa forma, o sistema pode entrar em swap um pouco, desde que não vá muito longe. Ou eu poderia definir esse limite para acionar oom-killer antes de usar toda a RAM, para que sempre haja espaço para o cache do sistema de arquivos (e, assim, evite mais trocas de disco).

Não parece que isso seria difícil de fazer. Parece que você poderia simplesmente dizer ao oom-killer para disparar quando o sistema tiver o X ram usado / livre. Mas é por isso que estou perguntando; Eu não sei.

Para esclarecimento, não pretendo desativar a troca ou ajustar o vm.swappinessparâmetro


3
Curiosamente, isso acontece mesmo quando não há arquivo de troca. Aparentemente, os arquivos mapeados na memória somente leitura (como executáveis, bibliotecas, talvez recursos gráficos) são trocados.
WGH 13/01

O oomd do Facebook é um daemon de espaço do usuário projetado para eliminar processos com base na taxa de transferência geral do sistema (ou seja, apenas quando se realiza uma debulha). Mas parece bastante complicado configurar para desktops / estações de trabalho (que provavelmente não estão colocando tarefas em cgroups ou containers).
Jeffrey Bosboom

Respostas:


22

Eu também lutei com esse problema. Eu só quero que meu sistema permaneça responsivo, não importa o que aconteça, e prefiro perder processos do que esperar alguns minutos. Parece não haver maneira de conseguir isso usando o kernel oom killer.

No entanto, no espaço do usuário, podemos fazer o que quisermos. Então, escrevi o Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) que matará o maior processo (por RSS) quando a RAM disponível ficar abaixo de 10%.

Sem o earlyoom, foi fácil bloquear minha máquina (8 GB de RAM) iniciando o http://www.unrealengine.com/html5/ algumas vezes. Agora, as guias culpadas do navegador são mortas antes que as coisas saiam do controle.


11
Obrigado, é exatamente o que eu estava procurando. Agora posso continuar executando column -t -s,alguns arquivos csv enormes e deixar earlyoommatá-lo quando isso não for possível, antes de perceber qualquer falta de resposta.
Henfiber

4

Isso soa como uma solução muito elaborada. Eu sugeriria (e faço isso em máquinas que configurei que não precisam hibernar) simplesmente alocar uma pequena quantidade de espaço de troca (128-256MiB). Dessa forma, o kernel pode trocar algumas páginas, mas o OOM-killer é invocado antes que as coisas fiquem ruins.

Se você realmente quiser fazer isso, acho que precisará escrever seu próprio script / programa que monitora o uso da troca e chama o OOM-killer usando a tecla Magic SysReq (que pode ser feita programaticamente escrevendo para /proc/sysrq-trigger).


11
Eu diria que ter uma pequena troca não é uma solução muito elegante. Você basicamente acaba limitando a utilidade do seu swap. E se você tiver muitas páginas inativas e se beneficiaria de ter 10 GB de swap por aí? Eu tenho caixas com ~ 100GB de RAM, onde 10GB de swap não é uma idéia muito buscada. E escrever um aplicativo para fazer isso no espaço do usuário está aberto a problemas (em comparação com o nativo no kernel).
1326 Patrick

Porque então você precisa essencialmente de um mecanismo para distinguir "troca boa" de "troca ruim", e esse é um algoritmo difícil de conceber. A quantidade de troca que é apropriado, obviamente, depende da quantidade de RAM e da carga de trabalho que você está executando, por isso, se 10GiB é apropriado para suas máquinas, em seguida, alocar esse :-)
mgorven

Por que isso seria difícil? Existem apenas 2 tipos de troca, troca preventiva devido a vm.swappinesstroca forçada devido à falta de memória RAM. Tudo o que precisa acontecer é quando o kernel é forçado a trocar, para acionar oom-killer. E 10 gb também deixam muito espaço para troca forçada para debulhar o disco.
1326 Patrick
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.