De tempos em tempos, o "meu" servidor para porque fica sem memória e espaço de troca. (continua respondendo ao ping, mas nada além disso, nem mesmo ssh).
Disseram-me que o linux faz um comprometimento excessivo de memória, que, pelo que entendi, é o mesmo que os bancos com dinheiro: concede aos processos mais memória do que realmente disponível, assumindo que a maioria dos processos não use realmente toda a memória que solicita, em pelo menos nem todos ao mesmo tempo.
Suponha que essa seja realmente a causa pela qual meu sistema ocasionalmente trava; não vamos discutir aqui se esse é ou não o caso (consulte O que pode fazer com que TODOS os serviços de um servidor sejam inoperantes, ainda respondendo ao ping? E como descobrir ) .
Tão,
como desabilito ou reduzo drasticamente o comprometimento excessivo da 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 devo encontrá-las e alterá-las (espero que algum arquivo de configuração), que valores devo tentar e se preciso reiniciar o servidor para efetivar as alterações.
e é seguro? Que efeitos colaterais eu poderia esperar? Ao pesquisar no overcommit_memory, encontro coisas assustadoras, como pessoas dizendo que o servidor não pode mais inicializar ....
Como o que causa o aumento repentino no uso da memória é o mysql, devido a consultas feitas pelo php que, por sua vez, são chamadas enquanto atendem solicitações http, eu esperaria que apenas algum script php não fosse concluído e, portanto, 500 respostas de tempos em tempos quando o servidor está muito ocupado, o que é um risco que posso correr (certamente melhor que todo o servidor fique inacessível e precise reiniciá-lo com força).
Ou pode realmente fazer com que o meu servidor não consiga reiniciar se eu escolher as configurações incorretas?
Respostas:
O overcommit de memória pode ser desativado por
vm.overcommit_memory=20 é o modo padrão, em que o kernel determina heuristicamente a alocação, calculando a memória livre em comparação com a solicitação de alocação que está sendo feita. E defini-lo como 1 ativa o modo de assistente, onde o kernel sempre anuncia que possui memória livre suficiente para qualquer alocação. Definir como 2 significa que os processos podem alocar apenas uma quantidade configurável (
overcommit_ratio) de RAM e começarão a receber falha na alocação ou mensagens OOM quando ultrapassar essa quantidade.É seguro fazê-lo, não. Não vi nenhum caso de uso adequado em que a descompressão de memória realmente ajudou, a menos que você esteja 100% certo da carga de trabalho e da capacidade do hardware. Caso esteja interessado, instale o
kernel-docspacote e vá/Documentation/sysctl/vm.txtpara ler mais ou leia online .Se você definir
vm.overcommit_memory=2, ele será comprometido demais com a porcentagem de RAM física configuradavm.overcommit_ratio(o padrão é 50%).Isso não sobreviverá a uma reinicialização. Para persistência, coloque isso no
/etc/sysctl.confarquivo:e corra
sysctl -p. Não há necessidade de reiniciar.fonte
Instrução totalmente não qualificada: desabilitar a confirmação excessiva de memória é definitivamente "mais seguro" do que habilitá-lo.
O $ customer o configurou em algumas centenas de servidores web e ajudou muito nos problemas de estabilidade. Existe até um cheque de Nagios chamando o fogo bem alto, se NÃO estiver desativado.
Por outro lado, as pessoas podem não considerar "seguro" deixar seus processos sem memória quando apenas desejam exagerar um pouco de memória RAM e nunca realmente usam isso. (ou seja, SAP seria um bom exemplo)
Então, você voltou a ver se isso melhora as coisas para você. Como você já está pesquisando para se livrar de problemas relacionados - acho que isso pode ajudar você.
(Eu sei que vou arriscar um voto negativo por alguma pessoa mal-humorada)
fonte
Concordo que desabilitar o overcommit é mais seguro do que habilitá-lo em algumas circunstâncias. Se o servidor executar apenas alguns trabalhos de memória grandes (como simulações de circuito no meu caso), é muito mais seguro negar ao aplicativo a solicitação de memória antecipadamente, em vez de esperar por um evento OOM (que certamente ocorrerá em breve). Frequentemente, vemos servidores tendo problemas depois que o assassino da OOM fez seu trabalho.
fonte