Muito. Use menos. MUITO menos.
Sei que isso não é uma ciência exata, mas o que vocês indicariam como
saudável?
Não há uma regra, mas o pessoal costuma começar a regulagem com um total
de até 2 vezes o número de núcleos para uma aplicação OLTP.
Existe um trabalho pesado feito pelo desenvolvedor Andreas Freund que
achou um overhead no gerenciamento de locks. Ele já fez um patch mas
isso só deve ser colocado dentro do código na versão 9.6. Com esse
patch, o número de conexões possíveis deve aumentar bastante sem grande
piora no desempenho.
Pois hoje rodamos o sistema com 4 Apps, geralmente cada um deles roda
com 15 conexões.
Deveria reduzir esse max do pool para um valor mais baixo, e em casos em
que há picos de conexão por qualquer fator que seja, esperar que o pool
se recupere? Pq já pensei nessa possibilidade também, limitar o numero
de conexões ao banco e deixar o pool fazer o seu trabalho.
Limite no pool.
Se sua aplicação começar a reclamar de falta de conexões, o problema é
outro. Aí entra tuning, otimizações de consultas e código, etc.
Qual a versão do PostgreSQL, sistema operacional e quantos núcleos
de processamento tens no seu servidor?
9.2.13, Ubuntu Server 14.04, 32 núcleos hoje apenas por um período, mas
o normal é uma EC2 com 16 núcleos.
Limite seu total a 64 conexões (soma de todos os pools dos JBoss)
Depois, monitore o servidor e veja se ainda tem tempo de CPU sobrando.
Aí você pode aumentar gradativamente. Se estiver engargalado, reduza
gradativamente.
Faço isso em todos os ambientes que trabalho.
Sim, os desenvolvedores Java ficam com a pulga atrás da orelha mas
depois agradecem por terem aprendido mais alguma coisa na vida.
Li também problemas relacionados a overhead no processo de
checkpoint,
os parâmetros hoje estão da seguinte forma.
checkpoint_segments = 256
OK. Mas você monitora o log pra ver se usa isso tudo mesmo?
checkpoint_timeout = 30min
Muito.
Normalemente os 5 minutos por default funcionam melhor.
checkpoint_warning = 30min
Isso aqui é só pra log. Na verdade, melhor que esse valor seja menor que
o anterior pra você saber se os checkpoints estão ocorrendo com
frequência exagerada.
checkpoint_completion_target = 0.9
Em SSD ok.
bgwriter_lru_maxpages = 500
bgwriter_lru_multiplier = 3
bgwriter_delay = 50ms
Diz a lenda (e algumas lendas famosas) que isso não muda nada mas na
minha experiência vale o tuning. Mas tem que ter os discos monitorados e
separado pra enxergar o ganho.
Os dados estão em SSD com RAID 10, 10 volumes de 200GB, totalizando
6000IOPS. A PGDATA está em um SSD de 50GB.
Você me parece ter bons discos. Mas monitore sempre o await e service time.
Seu banco de dados é relativamente pequeno.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
