Em 30 de janeiro de 2014 12:32, Flavio Henrique Araque Gurgel <
[email protected]> escreveu:

> Em 30-01-2014 14:38, Flavio Henrique Araque Gurgel escreveu:
>
>  Só que diminuir o número de conexões é o primeiro passo, pois ele
>> mascara todos os outros.
>>
>
> Só pra vocês verem como este assunto é recorrente e as pessoas são
> insistentes, acaba de circular na lista internacional:
>
> > I would be grateful anyone have a suggestion for my problem. I want to
> > simulate 400 clients sending queries to my Postgresql server. I know the
>
> Onde o requerente pergunta em tradução livre "Como faço pra simular 400
> clientes enviando consultas para meu servidor PostgreSQL..."
>
> Uma pergunta simples, e que não tem nada a ver com desempenho.
>
> A resposta veio de Stephen Frost, um de nossos gurus, é imediata:
>
> "Unless your server has 400 CPUs, you probably want to use a connection
> pooler in front of PG."
>
> Em tradução livre "Exceto se seu servidor tiver 400 CPUs, você
> provavelmente vai querer usar um aglomerador de conexões na frente de seu
> PostgreSQL."
>
> Basicamente, a regra é 1:1 - Uma conexão para cada CPU  disponível, é uma
> boa regra para primeiro tuning e primeiro teste. Que me abençoe o santo
> Fábio Telles.
>
> Toda variação nessa regra só deve ser feita sob condição de teste.
> Qualquer outro número, sem teste, é achismo.
>
> Portanto, começar o teste do colega com 450 conexões numa máquina de 32
> núcleos, não... vai... chegar... a lugar... algum.
>
>
> []s
> Flavio Gurgel
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Pessoal,

Mais uma dúvida, estamos com o Postgres rodando em uma máquina virtual,
teríamos mais desempenho se estivéssemos rodando em uma máquina física com
as mesmas configurações?


-- desculpem os top-posting.

-- 
*Wellington*
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a