Linux reinicializa a memória

Question

Eu tenho um servidor com CPU Intel (R) Atom (TM) D525 e 1 GB de memória. Percebi que o servidor seria desligado e reiniciado automaticamente a cada 7 dias.

Eu verifiquei o uso da memória e descobri que quando o uso da memória atingiu 90%, o kernel foi reinicializado. Quando eu verifiquei o log do kernel no arquivo /var/log/messages , eu não encontrei nada sobre o kernel desligar, apenas uma mensagem sobre o início do kernel. Eu verifiquei o arquivo /proc/sys/vm/min_free_kbytes , o valor é "3765".

Eu acho que quando a memória disponível é muito baixa, mas não chega ao número, o sistema começa a recuperar a memória. Então o kernel não pode fazer nada, então reinicia.

Você pode me dar algumas dicas?

    

Answer 1

Em alguns sistemas de memória virtual com paginação 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.

Na prática, os programas tendem a alocar mais memória do que eles usam. Por exemplo, o Java Virtual Machine aloca muita memória virtual na inicialização, mas não a utiliza imediatamente. A contabilização de memória no kernel do Linux tenta compensar isso rastreando a quantidade de memória realmente em uso pelos processos e supercompromina 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. 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. No entanto, se a configuração vm.panic_on_oom sysctl for diferente de zero, o kernel entrará em pânico quando o sistema ficar sem memória.

Os valores possíveis para a configuração vm.panic_on_oom são os seguintes:

• 0 (default) Quando ocorre uma situação de falta de memória, o OOM-killer mata um processo desonesto.

• 1 O kernel normalmente entra em pânico, mas se o processo que atingiu seu limite de alocação de memória definido com mbind(MPOL_BIND) ou cpuset , o processo é eliminado.

• 2 O kernel sempre entra em pânico em uma situação de falta de memória.

A heurística usada pelo OOM-killer pode ser modificada através da configuração vm.oom_kill_allocating_task sysctl. Os valores possíveis são os seguintes:

• 0 (padrão) O OOM-killer varrerá a lista de tarefas e selecionará uma tarefa mal-intencionada de tarefa que utilizará muita memória para ser eliminada.

• 1 (diferente de zero) O OOM-killer eliminará 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 as configurações de vm.overcommit_memory sysctl. Os valores possíveis são os seguintes:

• 0 (padrão) Heuristic overcommit com verificações fracas.

• 1 Sempre supercomprometido, sem verificações.

• 2 Contabilidade estrita, nesse modo, 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:

  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 .

As configurações de sysctl podem ser verificadas ou modificadas em tempo de execução com o comando sysctl . Para tornar as alterações permanentes, as configurações podem ser gravadas em /etc/sysctl.conf . As configurações acima também estão disponíveis na interface /proc/sys/vm . Os arquivos correspondentes são:

• /proc/sys/vm/panic_on_oom

• /proc/sys/vm/oom_kill_allocating_task

• /proc/sys/vm/overcommit_memory

• /proc/sys/vm/overcommit_ratio

Answer 2

• Eu acho que você deve descobrir o processo consumido muita memória.Talvez o programa tenha um erro de vazamento de memória.Você deve consertá-lo.
• Se não houver memória suficiente, o Linux encerrará algum processo consumindo muita memória ou reinicializará a si mesmo. Porque o kernel deve usar alguma memória.
• O comportamento diferente é determinado pelo config.But eu acho que você deve corrigir o erro de vazamento de memória.

Answer 3

Eu estou supondo que algum watchdog (kernel?) detecta um travamento do sistema e é isso que está causando as reinicializações. As opções de .config do kernel, como CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC , podem causar uma reinicialização após um determinado tempo limite de detecção do sistema interrompido.

A verdadeira questão é: por que o sistema está travado? o que eu acredito é o mesmo que esta pergunta: matador OOM não funciona corretamente, leva a um sistema operacional congelado