Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello
<[email protected]> 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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a