Re: [pgbr-geral] Aumento de LOAD e abertura de conexões
Chegou a gerar algum report do pgbadger pra validar as conexões? Qual é a frequencia que essas conexões são abertas e encerradas? Fico curioso em saber se tu utilizas algum connection pool, como o pgbouncer ou pgpool. O colega da questão original tem um servidor de aplicações Java que tem pool embutido. É só fazer as devidas regulagens. pgbouncer não pode ser usado neste caso (no modo transaction) por causa da reutilização de prepared statements. Essa situação é normal? Existe realmente algum custo alto na abertura de novas conexões que poderia estar causando essa situação realmente? Ou a abertura de conexões seria apenas um efeito causado por algum processo que está causando indisponibilidade do servidor, fazendo com que o pool do Jboss abra mais e mais conexões. Se o postgres gargala pra abrir novas conexões, o datasource do JBoss vai provavelmente causar esse problema. Exato. E em efeito cascata. Regule o datasource do JBoss pra *menos*. Veja outra resposta. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumento de LOAD e abertura de conexões
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
Re: [pgbr-geral] Aumento de LOAD e abertura de conexões
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
[pgbr-geral] HDD x SSDs
Olá pessoal Estou criando um ambiente, com discos SSDs (ou Flash memory) para fazer experimentos para um trabalho de Pós-graduação. Vou utilizar o benchmark TCC-C (www.tpc.org), que fornece scripts para criação de tabelas e dados(tamanho voce escolhe). Algumas questões se alguém puder contribuir: - Pelo que já foi provado (artigo http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf tabela 4 e 5, página 6), em SSDs o page size , deve ser menor em discos SSDs 2KB +-. Na prática, alguém realmente utiliza block size menores quando se utiliza Discos SSDs ? - Existem outros parâmetros no banco que poderiam ser alterados, devido ao uso de disco SSDs, para melhor desempenho ? - Ao criar um índices, alguém aconselha algo diferente, considerando que se está utilizando discos SSDs? Qualquer ajuda é bem vinda! []'s Wiliam ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função com tabela em OUT
Em 28/08/2015 7:50 PM, JotaComm jota.c...@gmail.com escreveu: Boa noite! Em 27 de agosto de 2015 23:08, Bruno Silva bemanuel...@gmail.com escreveu: Alguém já teve de criar alguma função que segue o seguinte conceito: CREATE TYPE tp_conta AS ( id_conta int, valor numeric(12,4) ) CREATE TABLE t_colecaoContas OF tp_conta ( PRIMARY KEY (id_conta), quantidadeEconomias WITH OPTIONS DEFAULT 1000 ); CREATE OR REPLACE FUNCTION minha_funcao (id_pessoa integer, r_contasPessoa Out t_colecaoContas, r_mensagem Out text) RETURNS RECORD AS $body$ ... ... INSERT INTO t_ColecaoContas ( id_conta, valor ) values ( 10,100); RETURN; $body$ LANGUAGE PLPGSQL ; Apesar da função passar normal ao ser chamada, ela não tras nenhum resultado. Estou fazendo da forma correta? Preciso retornar essa 'coleção' e a mensagem de erro para o programa. Estou usando Postgres 9.3. Você realmente precisa criar um tipo de dados? Por que não usar um RETURN TABLE nomedatabela? Não posso, na verdade é uma adaptação para um sistema que já trabalha com Oracle e está evoluindo para Postgres. Por isso não posso mudar tanto a forma de chamada, pois ele tem de retornar a tabela e um varchar que tem mensagens de erro. Como você fez a chamada da função? Não sei se entendi sua pergunta... CREATE OR REPLACE FUNCTION minha_funcao (id_pessoa integer, r_contasPessoa Out t_colecaoContas, r_mensagem Out text) RETURNS RECORD AS $body$ ... Bruno E. A. Silva. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Abraços -- JotaComm http://jotacomm.wordpress.com ___ 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
Re: [pgbr-geral] Função com tabela em OUT
Boa noite! Em 27 de agosto de 2015 23:08, Bruno Silva bemanuel...@gmail.com escreveu: Alguém já teve de criar alguma função que segue o seguinte conceito: CREATE TYPE tp_conta AS ( id_conta int, valor numeric(12,4) ) CREATE TABLE t_colecaoContas OF tp_conta ( PRIMARY KEY (id_conta), quantidadeEconomias WITH OPTIONS DEFAULT 1000 ); CREATE OR REPLACE FUNCTION minha_funcao (id_pessoa integer, r_contasPessoa Out t_colecaoContas, r_mensagem Out text) RETURNS RECORD AS $body$ ... ... INSERT INTO t_ColecaoContas ( id_conta, valor ) values ( 10,100); RETURN; $body$ LANGUAGE PLPGSQL ; Apesar da função passar normal ao ser chamada, ela não tras nenhum resultado. Estou fazendo da forma correta? Preciso retornar essa 'coleção' e a mensagem de erro para o programa. Estou usando Postgres 9.3. Você realmente precisa criar um tipo de dados? Por que não usar um RETURN TABLE nomedatabela? Como você fez a chamada da função? Bruno E. A. Silva. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Abraços -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
