Em 18 de maio de 2016 08:12, Luiz Carlos L. Nogueira Jr. < [email protected]> escreveu:
> Euler, > > 32GB > 12 cores - Como isso determina no final das contas o paralelismo real de > instruções, iria deixar o pool proximadamente 4x mais (50). > > Eu tinha visto as estatísticas, mas como comparar o bouncer com as > conexões diretas no banco? > > Só pelo SO. Tem alguma maneira de calcular o TPS do banco antes e depois > do bouncer? > > Luiz Carlos > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > Bom dia Luiz, Você pode rodar o pgbench com e sem o pgbouncer e verificar os resultados. O ideal é que o pgbouncer não esteja instalado no servidor de banco de dados, para que o processamento de um não limite o do outro. O mesmo ocorre com o pgbench, que deve ser disparado de uma terceira máquina independente. Para a configuração do pool você pode adotar duas filosofias: 1. Limitar o tamanho do pool para um número baixo (12 por exemplo): isto vai fazer com que as queries/sessões que estão ocupando este pool possuam mais recursos, pois estão dividindo o servidor com menos concorrentes e portanto tenham um desempenho melhor. O ponto negativo é que as conexões posteriores ficarão aguardando na fila e poderão morrer dependendo da configuração do checkout de wait. Esta configuração é melhor para processos em batch e não para transações OLTP com usuários reais esperando uma resposta. 2. Adequar o pool à quantidade máxima de clientes que você deseja atender mantendo um mínimo de nível de serviço. Como você mesmo disse, configurou para 50, neste caso o servidor irá atender estas 50 transações/sessões e as demais aguardarão na fila. Isto fará com que você consiga atender às pessoas sem stressar o banco de dados em demasia, fazendo com que posteriores conexões (digamos que exista um pico eventual de 600 conexões em algum momento) morram na fila, o que é um comportamento melhor do que deixar as 600 entrarem no banco de dados e degradar a performance geral a tal ponto que todo o sistema se torne inutilizável (obviamente que se existirem muitos picos acima da capacidade de 50 do exemplo, o ideal seria rever o hardware utilizado). Por fim, é preciso decidir-se por manter os pools em modo query (não recomendado), transaction (mais recomendado) ou session (pouco recomendado). Existem vários sites explicando as diferenças destes modos e eles influenciam diretamente nos TPSs que você poderá medir com o pgbench. Espero ter ajudado nos pensamentos que você terá que desenvolver neste trabalho. Boa sorte!
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
