Não é o Ubuntu que faz isso. É o kernel do Linux que faz isso. Wikipedia tem um tópico sobre isso:
A falta de memória (OOM) é um estado de computador frequentemente indesejado, em que nenhuma memória adicional pode ser alocada para uso por programas ou pelo sistema operacional. Esse sistema não poderá carregar nenhum programa adicional e, como muitos programas podem carregar dados adicionais na memória durante a execução, eles deixarão de funcionar corretamente. Isso ocorre porque toda a memória disponível, incluindo o espaço de troca de disco, foi alocada.
Em geral, deve haver um aviso em / var / log / syslog (sistemas baseados em debian) ou /var/log/messages . Um grep "Killed process" /var/log/syslog deve mostrar se o sistema eliminou um processo.
Tópicos interessantes: Como descobrir o que está matando um processo? " na pilha e este artigo em lwn.net .
A página do projeto para OOM tem muitas dicas:
O que causa esses eventos da OOM?
-
O kernel está realmente sem memória. A carga de trabalho usou mais memória do que o sistema tem RAM e espaço de troca. O que são SwapFree e MemFree em / proc / meminfo? Se ambos forem muito baixos (menos de 1% do total), a carga de trabalho pode estar com defeito. (a menos que o mlock () ou o HugeTLB estejam envolvidos, veja abaixo ...)
-
O kernel está sem memória suficiente nas arquiteturas de 32 bits. O que é o LowFree em / proc / meminfo? Se é muito baixo, mas o HighFree é muito maior, então você tem essa condição. Essa carga de trabalho pode se beneficiar da execução em uma plataforma ou kernel de 64 bits.
-
Existe uma estrutura de dados do kernel ou vazamento de memória. O que são SwapFree e MemFree em / proc / meminfo? Qual é o número de objetos task_struct no slabinfo? O sistema estava bifurcando tantos processos que ficou sem memória? Quais objetos em / proc / slabinfo ocupam mais espaço? Se um tipo de objeto está ocupando uma vasta porção da memória total do sistema, esse objeto pode ser responsável. Verifique com os especialistas do subsistema a área da qual esse objeto é fornecido. Para ver o uso do objeto, execute isto na linha de comando:
awk '{printf "%5d MB %s\n", */(1024*1024), }' < /proc/slabinfo | sort -n -
O kernel não está usando seu espaço de troca corretamente. Se o aplicativo usar páginas mlock () ou HugeTLBfs, talvez não seja possível usar seu espaço de troca para esse aplicativo. Se isso acontecer, o SwapFree ainda poderá ter um valor muito grande quando a OOM ocorrer. Essas duas características não permitem que o sistema troque a memória afetada, portanto, o uso excessivo delas pode esgotar a memória do sistema e deixar o sistema sem nenhum outro recurso. Também é possível que o sistema se encontre em uma espécie de impasse. A gravação de dados no disco pode, por si só, exigir a alocação de memória para várias estruturas de dados de E / S. Se o sistema não conseguir localizar nem mesmo essa memória, as próprias funções usadas para criar memória livre ficarão paralisadas e o sistema provavelmente ficará sem memória. É possível fazer alguns ajustes menores para iniciar a paginação mais cedo, mas se o sistema não puder gravar páginas sujas com rapidez suficiente para liberar memória, pode-se concluir que a carga de trabalho é mal dimensionada para a memória instalada e há pouco a ser feito . Aumentar o valor em / proc / sys / vm / min_free_kbytes fará com que o sistema comece a recuperar a memória mais cedo do que antes. Isso torna mais difícil entrar nesses tipos de impasses. Se você receber esses deadlocks, esse é um bom valor para ajustar. Se você se deparar com um caso em que o ajuste desse valor ajuda, informe-o. Talvez seja necessário fazer alterações nos valores padrão.
-
O kernel tomou uma decisão ruim e interpretou mal suas estatísticas. Foi OOM enquanto ainda tinha muita RAM boa para usar.
-
Algo realmente patológico está acontecendo O kernel realmente decide ir para OOM depois de gastar uma quantidade "significativa" de tempo varrendo a memória para que algo seja liberado. A partir de 2.6.19, essa "quantidade significativa" acontece depois que a VM varreu um valor igual a todas as páginas inativas (atualmente) ativas em uma zona seis vezes. Se o kernel estiver rapidamente varrendo páginas, mas seus dispositivos de E / S (swap, sistema de arquivos ou rede fs) estiverem muito lentos, o kernel pode julgar que não há progresso sendo feito e acionar um OOM mesmo que haja swap. / p>
Execute este script durante o teste e a OOM. Execute o script, envie a saída para um especialista em VM. Peça-lhes que analisem. Então volte e atualize esta página. ;)