Concordo com Telles. Acho que o ideal antes de fazer um BDCR é achar o problema. Analisar o resultado dos vaccum analyze. Ja vi o pgagent inchar a base ele usa o pgagent ? Vericar se as tabelas temporarias estão sendo deletadas com o fechamento da sessão.
Não quero gerar polemica e sim entender o problema e achar uma solução menos drastica. Fábio Telles Rodriguez wrote: > > Ok, você respondeu de forma equilibrada. Ponto para você. > > De toda forma, recomendo encaminhar o problema numa lista internacional. > Pode ser mesmo que o você tenha encontrado algum problema crônico no > PostgreSQL que valha a pena ser investigado e talvez até que uma melhoria > nele deva ser desenvolvida. Pode ser também que algum ajuste passou > desapercebido. Pode ser. > > De toda forma, sempre vale a pena ir atrás para descobrir a raiz do > problema. Sei que nem sempre temos tempo para isso, mas se um dia destes > tiver, recomendo entrar na > http://archives.postgresql.org/pgsql-performance/e reportar o seu > problema. > > Vale a pena também brigar com o fornecedor para homologarem uma nova > versão > do PostgreSQL. É bem possível que o seu problema tenha sido resolvido numa > versão mais nova, quem sabe? > > Um grande abraço, > Fábio Telles > > Em 6 de maio de 2010 11:14, Sergio Santi <[email protected]> > escreveu: > >> Fábio, minha intenção é a mesma tua, isto é, ajuda, mas de boas >> intenções >> o inferno está cheio e pode estar sendo o meu caso. >> >> No caso em questão o mal-falado BDCR me "manteve vivo" e em condições de >> procurar alternativas para esses e outros problemas que ainda tenho >> classificados como "inexplicados". Para você e os demais terem uma idéia: >> >> 1. Bases grandes que não são "enchugadas" pelo vacuum, mas que o são por >> um >> BDCR. >> 2. Vacuum que leva de 6 a 8 horas rodando, mas que após um restart do >> servidor rodam em 2 horas. >> 3. Índices não utilizados pelo otimizador que "escolhe" usar caminhos >> inexplicáveis e onerosos. >> 4. Critérios para definição de parâmetros do postgresql.conf. >> >> Todos esses temas já foram discutidos diversas vezes nesta excelente e >> por >> vezes salvadora lista e esses e outros casos que não lembro, muitas vezes >> são difíceis ou demorados de reproduzir e todos nós temos, via de regra, >> pouco tempo disponível, então o assunto acaba se esvaindo e a pobre >> vítima >> que se deparou com o problema precisa dar um jeito de sobreviver. Por >> exemplo, acredito que o particionamento de tabelas que estamos projetando >> possivelmente resolva ou atenue um ou mais desses problemas, mas isto >> quer >> dizer que contornei o problema e não que o identifiquei e resolví. >> >> Assim não acho que usar um BDCR em determinados casos e enquanto uma >> solução elegante não aparece seja um demérito ao banco. Pode ser um >> demérito >> nosso que ainda não achamos a solução adequada (por falta de tempo, etc), >> mas não do banco que utilizo largamente. A propósito é o único banco que >> tenho homologado com nosso ERP, mas isto não quer dizer que não existam >> coisas a serem criadas, melhoradas e corrigidas, que o digam as versões e >> releases ... >> >> Não quero polemizar com esse assunto, mas acho que temos que achar outra >> forma, mais produtiva de RESOLVER / encaminhar este tipo de caso que por >> vezes ocorre, porque normalmente as pessoas acabam cansando/desistindo de >> discutir o caso quando o esforço é grande e os resultados pequenos ou >> inexistentes e mais adiante o problema volta pelas mãos de outro membro. >> >> abraços, >> >> Sergio Medeiros Santi >> >> >> Em 06/05/2010 10:22, Fábio Telles Rodriguez escreveu: >> >> Em 6 de maio de 2010 08:48, Sergio Santi >> <[email protected]>escreveu: >> >>> Primeiramente ninguém disse para fazer backup, drop, create e restore >>> (bdcr) toda a semana. Eu disse faça hoje a noite se possível, ou no >>> próximo >>> final de semana. Eu tentei seguir essa teoria da manutenção tradicional, >>> mas quando isto não resolveu foi necessário apelar para esta medida >>> paleativa e "absurda", mas que resolveu o caso. >>> >>> Posso até concordar que não deveria ser necessário que o vacuum deveria >>> dar conta disto, mas não dá. Essa discussão já rolou umas duas vezes e >>> ninguém conseguiu mostrar que este procedimento não é útil de tempos em >>> tempos. Em bases pequenas não executo nunca, em bases médias (<30GB) 2 >>> ou 3 >>> vezes por ano, já em bases grandes faço a cada 2 meses se existirem >>> feriados >>> disponíveis. Na época em que tive essa experiência desagradável busquei >>> socorro nesta lista, tentei de tudo, e o que manteve o paciente vivo foi >>> essa "benzedura". Um dia os estudiosos do postgresql vão descobrir uma >>> explicação científica para isto, mas enquanto isto .... >>> >>> Sérgio, minha intenção aqui é ajudar o Marcio que apareceu com uma >> dúvida. >> >> Veja que a coisa mais importante no caso dele é que ele faz o Vacuum. >> Isso é a PRIMEIRA coisa que ele deve testar. >> >> Não tenho acompanhado a lista com tanta frequência como eu gostaria. >> Talvez algum problema seu tenha passado desapercebido por alguns gurus >> aqui >> da lista. Recomendo enfaticamente tentar as listas internacionais em >> casos >> extremos como o seu. De toda forma, eu jamais colocaria todas as fichas >> no >> vacuum. Veja que eu citei também o REINDEX[1] e o CLUSTER[2] e de cabeça >> poderia sugerir para mexer nos parâmetros de storage de algumas tableas >> como >> o parâmetro fillfactor [3]. São algumas sugestões. É claro que cada >> aplicação é uma aplicação. Se você realiza cargas monstruosas, com >> frequência, realiza DELETEs em % significativa de registros de grandes >> tabelas, tudo isso vai fazer o seu banco sofrer (não só o PostgreSQL, >> como >> qualquer outro SGDB). >> >> O particionamento de tabelas pode lhe ajudar muito também. É sempre um >> conjunto de técnicas que são utilizadas para manter um banco de dados no >> ar >> com boa performance. Nunca é um único problema. >> >> Por fim, dizer publicamente que você precisa realizar um "DUMP, DROP, >> CREATE, IMPORT" (estou trocando as palavras "backup" por "dump" e >> "restore" >> por "import" para não fazer confusão com o backup físico) seja um >> procedimento recomendável é dizer que o SGDB não presta definitivamente. >> Eu >> não utilizaria um SGDB assim. Espero nunca ter de me retratar por dizer >> isso, mas esta é a minha expectativa. >> >> []s >> Fábio Telles >> -- >> blog: >> http://www.midstorm.org/~telles/<http://www.midstorm.org/%7Etelles/> >> e-mail / jabber: [email protected] >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected]https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > > -- > blog: http://www.midstorm.org/~telles/ > e-mail / jabber: [email protected] > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- View this message in context: http://old.nabble.com/RES%3A-Melhorando-o-desempenho-do-PostGre-tp28454186p28474748.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
