Em 04-07-2012 11:33, Tulio escreveu: > /1 - o pgBouncer é apenas um pool de conexões, o PgPool 2 pode fazer > muito mais que isso. Se você quer apenas um pool, o pgbouncer costuma > ser mais leve e mais simples para isso./ > não me recordo se foi em Blog ou na lista, mas já ouvi falar bem sobre o > desempenho quando conciliamos os dois serviços...
Eu já falei em palestras alguma coisa. O pgbouncer é muito, muito mais eficiente que o pgpool para fazer... pool. Só que o pgbouncer só faz isso, pool. Talvez por fazer só isso, ele é menor em footprint (consumo de memória) e muito rápido. Ele também é multithread, o pgpool é multiprocessos. Para muitas conexões (milhares, por exemplo), o pgbouncer vai bem, o pgpool senta. O pgpool tem outras dezenas de funcionalidades interessantes. Então, quando alguém tem: Sistema Web (php, cgi, python, perl) com milhares de conexões do lado Web, eu sugiro sempre usar o pgbouncer. Se esse mesmo alguém precisa de funcionalidades do pgpool, eu sugiro fazer assim: aplicação -> pgbouncer -> pgpool -> PostgreSQL Onde n conexões da aplicação são n conexões no pgbouncer. m conexões do pgbouncer são as mesmas m para o pgpool que lida na relação 1:1 de m conexões com o PostgreSQL. E n > m, normalmente n >>>> m. > Apesar do PgPool estar configurado para balanceamento.. parece não ter > gerado um bom resultado.. Como é esse balanceamento? Qual modo do pgpool está usando? Você está replicando por streaming no PostgreSQL? Ou está usando a replicação síncrona do pgpool? Em tempo, balanceamento de carga com TPC-B não tem efeito nenhum. Todos os selects estarão dentro de transações (bloco BEGIN, SELECT, COMMIT) e o pgpool *não* balanceia isso. Manda tudo pro Master. E, se você estiver usando: - replicação síncrona do pgpool - OU replicação síncrona do PostgreSQL Você fatalmente terá perda de desempenho num TPC-B. TPC-B é praticamente escrita, escrita não escala assim como você está fazendo. A replicação síncrona do pgpool tende a apresentar pior resultado que a replicação síncrona embutida no PostgreSQL. > o parametro backend_weigth foi setado como 1 na master e 2 na slave.. > nessa configuração estou que 2/3 do peso de consultas será enviado a > master.. e 1/3 a slave.. > pois se setar como 0 na master ela nao aceitará consultas.. apenas > gravações.. Não vai balancear TPC-B. Tudo vai cair no mestre. Somente SELECTs avulsos cairão no slave, o TPC-B não prevê isso. > /3 - o pgBouncer pode ser utilizado em vários modos. Experimente eles e > conheça suas limitações antes de testa-lo./ > Ok.. > indica algum material em especifico? Documentação do pgbouncer no site oficial, em especial o FAQ: http://pgbouncer.projects.postgresql.org/doc/faq.html []s Flavio Henrique A. Gurgel Consultor e Instrutor 4Linux Tel: +55-11-2125-4747 www.4linux.com.br _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
