Início / unix / Perguntas / 761987
Accepted
wangt13
Asked: 2023-11-21 16:54:17 +0800 CST

Qual é o gatilho do OOM killer, memória livre ou disponível no Linux?

  • 772

Estou trabalhando em um sistema Linux embarcado que está na plataforma SOC.
Tenho duas máquinas executando a mesma carga de trabalho de memória e obtive a seguinte saída de memória.

Máquina 1.

              total        used        free      shared  buff/cache   available
Mem:          50616       35304        2516          48       12796       13100
Swap:             0           0           0

Máquina 2.

              total        used        free      shared  buff/cache   available
Mem:          57328       45320        2856          56        9152        9572
Swap:             0           0           0

A máquina 1 tem menos freememória que a máquina2, mas a máquina 1 tem mais availablememória que a máquina 2. Nesse caso, qual máquina corre maior risco de acionar o OOM killer?
Existe algum conselho sobre ajuste de memória?

Atualizado com a configuração overcommit_memory (meio que fora do assunto)

Pela resposta do Fritz, em outro sistema mudei overcommit_memorypara 2, sem outras alterações, consegui o seguinte.

# cat /proc/sys/vm/overcommit_ratio
50
#
# free
              total        used        free      shared  buff/cache   available
Mem:          84244       25256       35196          92       23792       56772
Swap:             0           0           0
# echo 2 > /proc/sys/vm/overcommit_memory
#
# ls
-/bin/sh: can't fork: Cannot allocate memory

A proporção é 50, mas é indicada cannot allocate memoryao desativar o overcommit de memória.

Mesmo echo 100 > /proc/sys/vm/overcommit_ratioquando echo 2 > /proc/sys/vm/overcommit_memory, ainda ocorreu o erro e tive que reiniciar o sistema.

Portanto, de acordo com meus testes, alterar a alocação excessiva de memória pode não gerar a pre-definedfalha de segmentação.

Eu aceitei a resposta de Fritz sobre as recuperações de memória do kernel em availablee free.

Podemos abrir outra questão para discutir a alocação excessiva de memória do Linux.

linux

1 respostas

  1. Best Answer

    freea memória não é utilizada completamente, enquanto availablea memória pode ser liberada pelo kernel imediatamente se for necessário. Ele contém itens como cache do sistema de arquivos, evitando leituras do disco e acelerando o sistema. Se você olhar com atenção, verá que o availablevalor é semelhante a buff/cache.

    Assim, o kernel não deve invocar o assassino OOM a menos que a availablememória esteja esgotada.

    Como Andrew apontou nos comentários: A opção segura é desabilitar a supercomprometimento de memória no kernel . Dessa forma, quando um programa solicitar mais memória do que a disponível no momento, a mallocchamada retornará NULLem vez de ser bem-sucedida. Isso significa que nunca poderá haver mais memória alocada do que a disponível fisicamente, então o assassino OOM (espero) nunca será invocado:

    # Assuming swap is disabled because it is an embedded system:
echo 100 > /proc/sys/vm/overcommit_ratio  # Commit max 100% of physical RAM (+ Swap, which is off)
echo 2 > /proc/sys/vm/overcommit_memory  # Disable overcommit heuristics

    No entanto, isso requer que (a) seus programas não solicitem muito mais memória do que pretendem usar e (b) que você verifique o valor de retorno de todas as mallocchamadas e faça algo sensato quando elas retornarem NULL. Caso contrário, você corre o risco de ter o mesmo comportamento do assassino OOM (seu processo morrendo aleatoriamente), neste caso devido a uma desreferência segfault/null.

    É difícil obter mais conselhos de ajuste sem informações sobre o cenário específico que você está enfrentando. Mas se a memória física se esgotar durante o excesso de comprometimento, não há muito que o kernel possa fazer além de: trocar , encerrar um processo ou entrar em pânico . Você pode tentar ativar zramou zswap("trocando" para RAM) ou adicionar um swapfile, mas ambos provavelmente degradarão o desempenho do sistema quando a memória estiver (quase) cheia. É melhor garantir que seu aplicativo não tenha vazamentos de memória.

    • 3

relate perguntas