GNU / Linux OOM (falta de memória) congela - idéias de solução

Question

Explicação

Ao trabalhar com uma máquina mais antiga com swap e ram de 2 GB, eu frequentemente encontro um comportamento bem descrito como freeze:

• aqui , qual é a melhor maneira de evitar falta de memória oom congela no linux
• aqui , computador congelando em ram quase completo , possivelmente problema de cache de disco
• e aqui , sistema suspenso quando fica sem memória
• bug globalmente aparentemente longo conhecido

Enquanto todos os Q & A aqui se concentram principalmente em

• ajustes com sysctl vm.min_free_kbytes e vm.swappiness
• outra solução proposta ajusta oom_score e reza OOM funciona
• configurando o zram (compressa de troca)
• scripts de shell de vários [1] classificam [2]
• ou até mesmo "conselhos" para comprar mais memória ram etc.

Eu acho essas soluções paliativas. Eu compreendo a partir da leitura da documentação do kernel , que mesmo que a OOM tenha que se comportar, ela pode funcionar em dois "modos" por enquanto:

• ou mata mais processo de fome de memória (geralmente)
• ou mata memória 'ofensor', que é o último processo que realmente tentou alocar memória.

Nenhuma dessas soluções realmente me satisfaz. Cheguei à conclusão de que eu NÃO quero que a OOM seja executada matando processos aleatórios ou finais, mas quero manter sistema operacional. Eu quero decidir o que matar sozinho, mas sem alterar oom_score para processos.

Perguntas

O que eu quero saber / fazer é:

1. A situação mudou / melhorou nunca em kernels (digamos 4.0 +)
2. A situação mudou em nunca Ubuntu (patches personalizados? 12.04 +)
3. Independentemente dessas duas perguntas, estou aberto a sugestões, que ainda não foram mencionadas em Q & A acima .

4. Independentemente dessas três questões acima. Estou pensando em compilar o próprio /bin/login binary, modifiquei isso:

   • alocaria quantidade configurável de memória (ex. 8MB)
   • copia / separa o espaço de usuário configurável TUI (ex. htop) (consulte this )
   • o pai colocaria o processo filho em suspensão, enviando-o ao SIGTSTP (para que ele não consuma cpu), talvez próximo do filho fd.
   • o pai enviaria SIGTCONT para o filho somente quando o usuário fosse autenticado corretamente. Talvez também restaurar filhos fd se fechado por razões de segurança,
   • este binário de emergência de login seria executado por upstart / systemd ou qualquer binário init, executando provavelmente também com permissões elevadas, para permitir a eliminação de qualquer processo desejado.

5. Essa abordagem parece sensata ou isso é exagero? Quaisquer falhas de segurança visíveis à primeira vista?