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
