O killer da OOM não é uma forma qualquer pessoa gerencia a memória; é a maneira dos kernels Linux lidar com falhas fatais na última esperança para evitar o travamento do sistema!
O que você deve fazer é:
-
verifique se você tem swap suficiente. Se tiver certeza, ainda adicione mais.
-
implemente limites de recursos! Pelo menos para as aplicações que você espera que usem memória (e ainda mais se você não espera que elas aconteçam - essas geralmente acabam sendo problemáticas). Veja os comandos ulimit -v (ou limit addressspace) em seu shell e coloque-o antes da inicialização do aplicativo em seu script de inicialização. Você também deve limitar outras coisas (como número de processos -u, etc) ... Dessa forma, o aplicativo receberá o erro ENOMEM quando não houver memória suficiente, em vez do kernel dar a eles memória inexistente e depois ficar berserk matando tudo !
-
diz ao kernel para não comprometer a memória. Você poderia fazer:
echo "0" > /proc/sys/vm/overcommit_memory
ou melhor ainda (dependendo da quantidade de espaço de troca)
echo "2" > /proc/sys/vm/overcommit_memory; echo "80" > /proc/sys/vm/overcommit_ratio
Veja Desativando o comprometimento excessivo para obter mais informações sobre isso.
Isso instruiria o kernel a ter mais cuidado ao dar memória aos aplicativos que ele realmente não tem (a semelhança com a crise econômica mundial é impressionante)
-
como último recurso, se tudo no seu sistema, exceto o MangoDB, for descartável (mas, por favor, corrija dois pontos acima primeiro!), você pode diminuir o chances de ser morto (ou mesmo ter certeza de que não será eliminado - mesmo que a alternativa seja desligar a máquina sem nada funcionar) sintonizando / proc / $ pid / oom_score_adj e / ou / proc / $ pid / oom_score.
echo "-1000" > /proc/'pidof mangod'/oom_score_adj
Veja Domar o assassino de OOM para mais informações sobre esse assunto.