On 18-05-2016 00:32, Lucas Possamai wrote:
> 
> [..corte..]
>     Acho que você está desinformado. Benchmarks comprovam que shared_buffers
>     alto (dezenas de GB) não escala em TPS.
> 
> 
> posso estar... também fiz vários testes como mencionei.. também falei
> com um monte de gente... e parecia a melhor solução.. 
> 
> mas na prática não funcionou.... foi pior
> 

Desculpe mas ficou confuso pois pelo que entendi lendo emails anteriores
o seu "pior" foi por conta da falha do arquivamento... posso também ter
entendido errado.

O que vc julga como "pior"?? Performance?? Vc tem dados para nos
fornecer?? Além disso vc disse que ao alterar o shared_buffers o
PostgreSQL não iniciou, vc poderia fornecer as entradas no log que
indicam o problema?

Como o Euler já mencionou um valor de shared_buffers impacta em um
checkpoint mais demorado e durante o stop do serviço o PostgreSQL efetua
um para ele poder "parar em um estado consistente" e não necessitar de
um "recovery" no próximo "start". Se vc forçou o "stop" do serviço para
ser mais rápido então no próximo "start" ele entrará em "recovery" e
isso pode demorar algum tempo.

Att,

-- 
   Fabrízio de Royes Mello         Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Attachment: signature.asc
Description: OpenPGP digital signature

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

Responder a