Evitar desmontagem do aplicativo fora de memória linux

Question

Estou descobrindo que, ocasionalmente, minha caixa do Linux fica sem memória e começa a derrubar processos aleatórios para lidar com ela.

Estou curioso sobre o que os administradores fazem para evitar isso? É a única solução real para a quantidade de memória (upping o swap sozinho ajuda?), Ou há melhores maneiras de configurar a caixa com software para evitar isso? (ou seja, cotas, ou algo assim?).

    

Answer 1

Por padrão, o Linux tem um conceito de gerenciamento de memória um pouco danificado pelo cérebro: ele permite que você aloque mais memória do que o seu sistema, e então dispara aleatoriamente um processo na cabeça quando fica em apuros. (A semântica real do que é morto é mais complexa do que isso - Google "Linux OOM Killer" para muitos detalhes e argumentos sobre se é uma coisa boa ou ruim).

Para restaurar alguma aparência de sanidade no seu gerenciamento de memória:

1. Desative o OOM Killer (Coloque vm.oom-kill = 0 em /etc/sysctl.conf)
2. Desativar supercomprometimento de memória (Colocar vm.overcommit_memory = 2 em /etc/sysctl.conf)
   Observe que esse é um valor trinário: 0="estimar se tivermos RAM suficiente", 1="Sempre dizer sim", 2="diga não se não tivermos memória")

Essas configurações farão com que o Linux se comporte da maneira tradicional (se um processo solicitar mais memória do que a disponível malloc () falhará e o processo solicitando a memória deverá lidar com essa falha).

Reinicialize sua máquina para recarregar /etc/sysctl.conf ou use o sistema de arquivos proc para ativar imediatamente, sem reinicialização:

echo 2 > /proc/sys/vm/overcommit_memory 

    

Answer 2

Você pode desativar a supercomprometimento, consulte o link

    

Answer 3

A resposta curta, para um servidor, é comprar e instalar mais RAM.

Um servidor que rotineiramente experimentou erros OOM (Out-Of-Memory), então além da opção sysctl de overcommit do gerenciador de VM (memória virtual) nos kernels Linux, isso não é uma coisa boa. / p>

Aumentar a quantidade de swap (memória virtual que foi paginada para o disco pelo gerenciador de memória do kernel) ajudará se os valores atuais forem baixos e o uso envolver muitas tarefas em cada uma dessas grandes quantidades de memória, em vez de uma ou alguns processos cada, solicitando uma quantidade enorme de memória virtual total disponível (RAM + swap).

Para muitos aplicativos que alocam mais de duas vezes (2x), a quantidade de RAM como swap fornece um retorno decrescente na melhoria. Em algumas grandes simulações computacionais, isso pode ser aceitável se a redução de velocidade for suportável.

Com RAM (ECC ou não) é bastante acessível para quantidades modestas, e. 4-16 GB, eu tenho que admitir, eu não tenho experimentado este problema em mim há muito tempo.

O básico é observar o consumo de memória, inclusive usando free e top , classificados por uso de memória, como as duas avaliações rápidas mais comuns dos padrões de uso de memória. Portanto, certifique-se de entender o significado de cada campo na saída desses comandos, no mínimo.

Sem especificações de aplicativos (por exemplo, banco de dados, servidor de serviço de rede, processamento de vídeo em tempo real) e uso do servidor (poucos usuários avançados, 100-1000s de conexões usuário / cliente), não consigo pensar em nenhuma recomendação geral para lidar com o problema da OOM.

    

Answer 4

Aumentar a quantidade de memória física pode não ser uma resposta efetiva em todas as circunstâncias.

Uma maneira de verificar isso é o comando 'atop'. Particularmente estas duas linhas.

Este é o servidor externo quando era saudável:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Quando estava funcionando mal (e antes de ajustarmos overcommit_memory de 50 para 90, veríamos o comportamento com vmcom executando bem mais de 50G, processando processos a cada poucos segundos, e a carga continuava saltando radicalmente devido ao NFSd child processos sendo explodidos e recriados continuamente.

Recentemente, duplicamos casos em que servidores de terminal Linux multiusuário supercompõem em massa a alocação de memória virtual, mas pouquíssimas das páginas solicitadas são realmente consumidas.

Embora não seja aconselhável seguir essa rota exata, ajustamos a memória de supercomprometimento do padrão 50 para 90, o que aliviou alguns dos problemas. Acabamos tendo que mover todos os usuários para outro servidor de terminal e reiniciar para ver todos os benefícios.

    

Answer 5

Você pode usar ulimit para reduzir a quantidade de memória que um processo pode reivindicar antes de ser eliminado. É muito útil se o seu problema for um ou poucos processos que deixem de funcionar no seu servidor.

Se o seu problema é que você simplesmente não tem memória suficiente para executar os serviços que precisa, existem apenas três soluções:

1. Reduza a memória usada pelo seu serviços, limitando caches e semelhante

2. Crie uma área de troca maior. Será custar-lhe em desempenho, mas pode comprar você algum tempo.

3. Compre mais memória

Answer 6

Eu tive um problema semelhante relacionado ao bug e a solução era usar o antigo / kernel (fixo) mais novo.

No entanto, no momento em que não pude reiniciar a máquina, algum tipo de solução feia era fazer login como raiz e limpar os caches do sistema com este comando:

echo 3 > /proc/sys/vm/drop_caches

    

Answer 7

@ voretaq7 o linux não possui um conceito de gerenciamento de memória danificado pelo cérebro, por padrão vm.overcommit_ratio é 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

Dessa forma, se você tiver 4 GB de RAM e tentar alocar 4,2 GB com malloc de memória virtual, sua alocação falhará.

Com vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

com vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Então, por padrão, o linux não compromete demais, se o seu aplicativo tiver mais memória do que você, talvez seu código tenha bugs