Muito obrigado por todas as respostas pessoal, vou fazer os devidos ajustes e monitoramentos, e posto novamente com os resultados que alcancei.
Em 28 de agosto de 2015 08:24, Flavio Henrique Araque Gurgel < fha...@gmail.com> escreveu: > 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 > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
