Boa tarde Matheus, Vejo que meu conhecimento sobre banco é muito menor que o seu, por exemplo, o que fico muito grato por estar aprendendo bastante.
As características do ambiente de banco de dados que usamos é que são cerca de 50 bancos e em média 00 conexões simultâneas por banco. Esses valores que citei foi em decorrência de algumas documentações sugerindo isso. Mas sempre estou aberto a ouvir opiniões que acrescentem algo ao meu entendimento, por isso estou nesse fórum. Grato pela atenção. Em 9 de agosto de 2013 13:32, Matheus de Oliveira <matioli.math...@gmail.com > escreveu: > > > > 2013/8/9 Dilamar Hoffmann <dilama...@gmail.com> > >> shared_buffers = 24GB (RAM Total - 8GB (OS e PostgreSQL)). >> >> Isso para que as consultas encontrem os dados em cache e não no sistema >> operacional, evitando as requisições ao sistema. Tudo depende do tamanho do >> banco de dados, numero de requisições, etc. No meu caso funciona >> perfeitamente com esses valores sem uso de swap. >> >> > Eu não ia falar nada, mas decidi comentar porque achei a sua recomendação > um tanto quanto exagerada. Para a maioria dos casos não é recomendado um > valor alto assim para shared_buffers (veja que esse valor é 75% da RAM), > apesar de ser verdade que há casos bem específicos onde esse valor pode ser > bom. Mas já vi vários casos onde esse exagero foi prejudicial, me parece > que é comum para quem vem do mundo Oracle, pois é uma recomendação comum > para esse software. Entretanto os algoritmos do PostgreSQL consideram que > há um bom cache sendo gerenciado pelo sistema operacional, assim, o > shared_buffers muito alto pode degradar a performance (em geral devido à > execução do do bgwriter). > > Também não acho que o fato de não entrar em swap ajude, já que o ruim é > que o SO fica com pouca memória para cache. E, mesmo com esse valor, existe > uma explicação para effective_cache_size = 26GB? Pois, pra mim a conta não > bate: > > - Temos 24GB para o shared_buffers > - Mais a possibilidade de ~ 3 * 1,5 GB devido ao maintenance_work_mem e > autovacuum (pode não alocar tudo isso) > > Só nessa conta (sem considerar outros fatores), teríamos somente 3,5 GB > para cache do sistema operacional, e "mentir" sobre isso para o PostgreSQL > *pode* ser desastroso. > > Veja que não estou querendo te criticar, mas achei que a recomendação > poderia prejudicar algumas pessoas sem um melhor contexto. Ainda, fiquei > pessoalmente interessado nesse ambiente que você citou e os motivos de um > valor tão alto ter dado ganho em performance. Pois a maioria dos casos e as > configurações iniciais a considerar, são contrárias a isso. Pode nos falar > mais sobre isso? Quais as características do ambiente (DW, OLTP, muita > consulta, balanceado, usuários simultâneos, etc...)? E o tamanho da base? > Você chegou a testar valores menores? E a verificação do uso efetivo do > shared_buffers (a extensão pg_buffercache ajuda a analisar isso)? E ainda a > atividade do bgwriter é muito intensa? > > > >> Abraço. >> >> >> Em 9 de agosto de 2013 10:19, Matheus de Oliveira < >> matioli.math...@gmail.com> escreveu: >> >>> >>> Em 8 de agosto de 2013 14:07, Emerson Martins <emersonmarti...@gmail.com >>> > escreveu: >>> >>>> Pessoal estou aqui mais uma vez precisando da ajuda de todos para >>>>> entender melhor como configurar esses parâmetros de memória no postgres.Se >>>>> existe alguma métrica específica para configura-los. >>>>> >>>>> shared_buffers = >>>>> effective_cache_size = >>>>> work_mem = >>>>> maintenance_work_mem = >>>>> >>>>> Tomando por base um servidor com 32GB de memória e SO Linux (Debian) >>>>> >>>> >>>> >>> 2013/8/9 Dilamar Hoffmann <dilama...@gmail.com> >>>> >>> Bom dia Emerson, >>>> >>>> De acordo com esse valor de memória RAM os valores seriam: >>>> >>>> shared_buffers = 24GB >>>> >>> >>> Quê? 24GB de shared_buffers? E um top-posting pra complementar. Pode >>> isso Arnaldo? >>> >>> effective_cache_size = 26GB >>>> work_mem = 8MB >>>> maintenance_work_mem = 1600MB >>>> >>>> >>> >>> Meio chutado esse valores, não?! >>> >>> Concordo que pode ter algumas situações onde esses valores podem ser >>> bons (apesar de ser em apenas 0,0001%, ao meu ver), mas não acho legal >>> apresentar valores dessa forma. O ideal, como já foi passado antes nos >>> links e comentários, é entender os valores e monitorar a efetividade das >>> alterações. Claro que se tem valores iniciais "meio genéricos" [1], que >>> seriam, em geral: >>> >>> - shared_buffers = 15% a 20% da RAM, no caso dele eu começaria com 6GB e >>> subiria se necessário (não mais do que 10GB ao menos que bem provado). Veja >>> que existe a possibilidade de 500MB ser mais que suficiente (claro, para >>> bancos pequenos), então por que exagerar tanto no começo? >>> >>> - effective_cache_size = o restante usado para cache do S.O. Em geral, >>> podemos dizer que seria total da RAM - shared_buffers - outras apps. Um bom >>> chute seria 50% da RAM, ou seja, 16GB, mas claro que também vai depender do >>> tamanho do banco e das tabelas. >>> >>> - work_mem = esse é difícil dizer, talvez 8MB pode ser um valor inicial, >>> mas o ideal é monitorar o uso de arquivos temporários e aumentar se estiver >>> gerando muitos e muito grandes (o parâmetro log_temp_files é a maneira que >>> acho melhor analisar isso). >>> >>> - maintenance_work_mem = é útil aumentar em SET's na sessão ao criar >>> índices, alter tables, etc. O padrão (no postgresql.conf) vai ser muito >>> útil para o autovacuum. Assim o mais agressivo que esse valor pode ser é: >>> tamanho da maior tabela, ou RAM disponível / 3 (o 3 seria na verdade o >>> autovacuum_max_workers). Eu, particularmente, não começaria com mais de >>> 256MB (mas isso vai depender muito do banco e sua atividade - e.g. bancos >>> com grandes tabelas que sofram muitos UPDATEs, seria benéfico aumentar). >>> >>> [1] http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server >>> >>> >>> Atenciosamente, >>> -- >>> Matheus de Oliveira >>> Analista de Banco de Dados >>> Dextra Sistemas - MPS.Br nível F! >>> www.dextra.com.br/postgres >>> >>> >>> _______________________________________________ >>> pgbr-geral mailing list >>> pgbr-geral@listas.postgresql.org.br >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >>> >> >> >> -- >> Dilamar >> >> _______________________________________________ >> pgbr-geral mailing list >> pgbr-geral@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Dilamar
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
