Em 24 de abril de 2017 16:46, Tiago José Adami <adam...@gmail.com> escreveu:
> Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello > <fabri...@timbira.com.br> escreveu: > > Isso é por conta do "overcommit_ratio = 50" que indica que foi > solicitado alocar mais memória que o "total de swap + 50% da RAM" [1] ... > como vc nao tem swap entao ele tentou alocar mais que RAM/2 e o kernel > matou... > > > > Att, > > > > > > [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting > > Agradeço pela ajuda, Fabrízio. > > Inicialmente fiquei confuso porque no /var/log/messages não haviam > entradas do OOM Killer. Mas durante a redação da resposta eu fui > conferir se havia algo desta vez e lá estava o registro. > > Sobre o problema: não estava exatamente no overcommit_ratio = 50 [1] > porque o outro parâmetro overcommit_memory estava no padrão heurístico > - valor 0. A realidade era que o servidor estava no limite de > utilização de memória. O total de memória em cache passou a ser > reduzido a meros 1 ou 2 GBs pouco antes do OOM entrar em ação. > > Com mais de 96 conexões ativas e executando comandos SQL sem parar, em > um momento os 16 GB de memória RAM chegaria no limite. A solução > encontrada foi criar uma partição SWAP de 10 GB. Tão logo foi criada, > passou a ser preenchida em até 30% nos momentos de maior utilização, > sendo liberada nos momentos de "bonanza". > > Achei um artigo convincente que dá detalhes de como funcionam estes > parâmetros do Kernel [2] dando exemplos, mas baseando-se na > configuração overcommit_memory=2, o que limita de forma parametrizada > o total que um processo pode alocar além do limite real. > > Talvez já esteja entrando em uma nova thread, mas quando falamos de um > servidor dedicado do PostgreSQL, qual seria a recomendação? Tunar o > overcommit conforme mostra o artigo [2] ou manter os padrões? > > [1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt > [2] http://engineering.pivotal.io/post/Virtual_memory_settings_ > in_Linux_-_The_problem_with_Overcommit/ > > TIAGO J. ADAMI > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > Boa tarde Tiago, Eu acho que estes parâmetros, servem para fazer o que você fez, ou seja, dar uma sobrevida aos momentos de pico do seu servidor. Caso eles não estejam configurados, o OOM poderá matar seus processos (como você experimentou) ou (caso você configure os parâmetros de memória do PostgreSQL para baixo) você poderá sofrer um erro de Out of Memory do servidor para o client. Em outras palavras, estamos apenas administrando recursos que já chegaram ao seu limite, a verdadeira solução seria: 1. Realizar um tuning das queries para que elas utilizem menos memória 2. Aumentar a quantidade de memória RAM do servidor Respondendo diretamente sua pergunta, eu gosto de tunar, pois assim você tem a oportunidade de verificar o uso de swap (como você fez) e, sendo constante, ter argumentos técnicos para recomendar a compra de mais RAM. []'s Felipe
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
