Cent OS: Como eu desativo ou reduzo o excesso de memória, e é seguro fazê-lo?

Question

Ocasionalmente, o "meu" servidor trava porque fica sem memória e espaço de troca. (ele continua respondendo ao ping mas nada mais do que isso, nem mesmo ssh).

Eu soube que o linux faz overcommitment de memória, que até onde eu entendo é o mesmo que os bancos fazem com dinheiro: ele concede mais memória aos processos do que os disponíveis, assumindo que a maioria dos processos não usa toda a memória pergunte, pelo menos não todos ao mesmo tempo.

Por favor, assuma que esta é realmente a causa porque o meu sistema ocasionalmente trava, não vamos discutir aqui se este é ou não o caso (consulte O que pode fazer com que TODOS os serviços em um servidor caiam, mas ainda assim respondam ao ping? E como descobrir ).

Então,

1. como desativar ou reduzir drasticamente o excesso de memória no CentOS? Eu li que existem duas configurações chamadas vm.overcommit_memory (valores 0, 1 ou 2) e vm.overcommit_ratiom mas não tenho idéia de onde eu tenho que encontrar e alterá-los (alguns arquivo de configuração espero), que valores devo tentar e se preciso reinicializar o servidor para que as alterações sejam efetivas.

2. e é seguro? Quais efeitos colaterais eu posso esperar? Quando pesquisando sobre o overcommit_memory, eu acho coisas assustadoras como pessoas dizendo que o servidor não pode inicializar mais ...

Como o aumento súbito no uso da memória é mysql devido a consultas feitas pelo php que, por sua vez, é chamado durante a requisição http, eu esperaria que apenas alguns scripts php não fossem concluídos e, portanto, cerca de 500 respostas do tempo para o tempo em que o servidor está muito ocupado, o que é um risco que posso correr (certamente melhor que o servidor inteiro fique inacessível e tenha que reiniciá-lo).

Ou será que o servidor não consegue reiniciar se eu escolher as configurações erradas?

    

Answer 1

A supercomissão de memória pode ser desativada por vm.overcommit_memory=2

0 é o modo padrão, onde o kernel determina heuristicamente a alocação calculando a memória livre comparada com a solicitação de alocação sendo feita. E defini-lo como 1 ativa o modo de magia, onde o kernel sempre anuncia que tem memória livre suficiente para qualquer alocação. A configuração para 2 significa que os processos só podem alocar até (RAM + troca) e começarão a receber falhas de alocação ou mensagens OOM quando ultrapassarem essa quantia.

É seguro fazê-lo, não. Eu não vi nenhum caso de uso adequado em que a desativação do overcommit de memória realmente ajudou, a menos que você tenha 100% de certeza da capacidade de carga de trabalho e hardware. Caso esteja interessado, instale o pacote kernel-docs e vá para /Documentation/sysctl/vm.txt para ler mais.

Se você definir vm.overcommit_memory=2 , não precisará se preocupar com overcommit_ratio.

echo 0/1/2 > /proc/sys/vm/overcommit_memory 

Isso não sobreviverá a uma reinicialização. Para persistência, coloque isso em /etc/sysctl.conf file:

vm.overcommit_memory=X

e execute sysctl -p . Não há necessidade de reiniciar.

    

Answer 2

Declaração totalmente não qualificada: Desativar o overcommit de memória é definitivamente "mais seguro" do que habilitá-lo.

O

$ customer configurou algumas centenas de servidores web e ajudou muito com os problemas de estabilidade. Há até um cheque do Nagios chamando o fogo bem alto se ele nunca estiver desativado.

Por outro lado, as pessoas podem não considerar "seguro" ter seus processos saindo da memória quando eles gostariam de supercomprimir um pouco de RAM e nunca realmente usariam isso. (ou seja, o SAP seria um bom exemplo)

Então, você volta a ver se isso melhora as coisas para você. Já que você já está procurando por isso para se livrar de questões relacionadas - acho que pode ajudar você.

(Eu sei que vou arriscar um voto negativo por uma pessoa mal-humorada)

    

Answer 3

Concordo que desativar a supercomprometimento é mais seguro do que habilitá-lo em algumas circunstâncias. Se o servidor executa apenas alguns grandes trabalhos de memória (como simulações de circuitos no meu caso), é muito mais seguro negar ao aplicativo o pedido de memória antecipadamente, em vez de esperar por um evento OOM (o que certamente acontecerá em breve) ter problemas após o assassino da OOM ter feito o seu trabalho.