Como um processo manipula a situação quando não encontra memória para usar?

Question

O que acontece quando um determinado processo descobre que não há memória para usar?

Esse processo matará / reiniciará outro processo para continuar com sua tarefa?

Ou qual será o processo (que requer mais memória) nesta situação?

Se possível, qualquer um pode fornecer um bom link em relação a isso?

    

Answer 1

Em alguns sistemas de memória virtual paginada por demanda, o sistema operacional se recusa a alocar páginas anônimas (ou seja, páginas contendo dados sem uma fonte de sistema de arquivos, como dados de tempo de execução, pilha de programas etc.), a menos que haja espaço swap suficiente para trocar as páginas a fim de liberar memória física. Essa contabilidade rigorosa tem a vantagem de que a cada processo é garantido o acesso à quantidade de memória virtual que eles alocam, mas também significa que a quantidade de memória virtual disponível é essencialmente limitada pelo tamanho do espaço de troca.

A contabilidade de memória no kernel do Linux tenta compensar os programas que tendem a alocar mais memória do que eles usam, rastreando a quantidade de memória realmente em uso pelos processos, e supercompromete a quantidade de memória virtual. Em outras palavras, a quantidade de memória virtual alocada pelo kernel pode exceder a quantidade de memória física e espaço de troca combinados no sistema. Na prática, isso significa que a alocação de memória por malloc() nunca falhará. Enquanto isso leva a uma melhor utilização da memória física e do espaço de troca, a desvantagem é que quando a quantidade de memória em uso excede a quantidade de memória física e espaço de troca disponível, o kernel deve de alguma forma liberar recursos de memória para atender a alocação de memória. compromisso.

O mecanismo do kernel que é usado para recuperar memória para preencher a supercomprometimento é chamado de out-of-memory-killer (OOM-killer). Normalmente, o mecanismo começa a matar os processos "desonestos" que consomem memória para liberar memória para outros processos. O comportamento do algoritmo OOM-killer e de contabilidade de memória pode ser ajustado via sysctl settings ou /proc/sys/vm . Se a configuração vm.panic_on_oom for diferente de zero, o kernel entrará em pânico quando o sistema ficar sem memória.

A heurística usada pelo OOM-killer pode ser modificada através da configuração vm.oom_kill_allocating_task . Por padrão, o OOM-killer irá varrer a lista de tarefas e selecionar uma tarefa mal-intencionada de tarefa, utilizando muita memória para matar. O OOM-killer também pode ser configurado para matar a tarefa que acionou a condição de falta de memória.

O algoritmo de contabilidade de memória do kernel pode ser ajustado com a configuração vm.overcommit_memory . O padrão é executar algumas verificações heurísticas fracas antes de supercomprometimento, mas o algoritmo de contabilidade de memória também pode ser definido para um modo estrito, no qual o limite do espaço de endereço virtual é determinado pelo valor de vm.overcommit_ratio configurações de acordo com a seguinte fórmula: / p>

    virtual memory = (swap + physical memory * (overcommit_ratio / 100))

Quando a contabilidade restrita de memória está em uso, o kernel não aloca mais páginas anônimas, a menos que tenha memória física livre suficiente ou espaço de troca para armazenar as páginas. Isso significa que é essencial que o sistema seja configurado com espaço de troca suficiente . A menos que haja memória física ou espaço de troca suficientes para satisfazer o compromisso de memória, as chamadas para malloc() poderão falhar. Nesses casos, cabe ao próprio programa determinar um curso de ação apropriado. Alguns podem simplesmente desistir e falhar completamente, mas também podem recorrer a um algoritmo mais lento, porém mais eficiente em termos de memória, para realizar a ação para a qual precisariam de alocação de memória.

    

Answer 2

Isso depende do que o programa está configurado para fazer. Programas simples apenas imprimem uma mensagem de erro e morrem quando não são capazes de alocar memória suficiente. Alguns programas tentam liberar memória por conta própria e tentar novamente. Alguns programas executam alguma economia de estado de emergência antes de sair. Alguns programas continuam funcionando de alguma forma e ficam sem a memória extra, talvez depois de informar ao usuário que algum comando não pôde ser executado.

Enquanto um processo poderia, em princípio, matar outro processo, isso seria um comportamento extremamente estranho. O processo não teria como saber quais processos matar e nenhuma garantia de que ele seria capaz de capturar sua memória.

Se a falta de memória for detectada pelo kernel em vez de pelo aplicativo, o kernel pode matar alguns processos, com base em heurísticas complexas (como "não mate sshd ").