2009/10/20 Euler Taveira de Oliveira <[email protected]> > > Por quê? Talvez a sua configuração esteja inadequada para tal cenário. Se o > autovacuum está bem configurado você não precisa dessa rotina diária mas... > > Perfeito.
> > - vacuum full analyze uma vez por semana > > > Por quê? O VACUUM FULL vai ficar obsoleto [1] daqui a algumas versões. Eu > *nunca* recomendo o seu uso. Ao invés dele, utilize CLUSTER + REINDEX. > > Entendido, mas uma dúvida... é uma boa estratégia "clusterizar" uma tabela pelo índice mais utilizado?? > > - PostgreSQL 8.2 > Sugiro atualizar para 8.4. O autovacuum tem sérios problemas de > escalabilidade > até a 8.2; a partir da 8.3, a arquitetura do autovacuum mudou permitindo > que > ele ficasse mais robusto. Além disso, os parâmetros padrão do autovacuum da > 8.2 são _muito_ agressivos para alguns cenários; os parâmetros do 8.3 já > são > mais conservadores. > > Quanto ao upgrade da versão 8.2 para superiores estamos planejando para o próximo ano (para 8.4), é que nossa aplicação é muito grande e em função da remoção das casts implícitos estamos revisando os pontos de impacto... Sobre o auto_vacuum estou utilizando uma configuração conservadora, assim como a configuração padrão da 8.3 e tenho algumas tabelas especificas configurados manualmente na pg_autovacuum . Depende de quanto os seus índices estão inchadas (aka bloat). Vide [2] para > saber quais os índices estão nessa situação. > > Vou verificar essa questão do inchaço dos índices... > > <corte> > > Como disse acima, migre para o 8.4. Especialmente utilizando SO Windows. > Lembre-se que o 8.2 é a _última_ versão suportada nessa plataforma. Nessa > plataforma, eu sempre executaria a última versão do PostgreSQL pois várias > melhorias foram propostas ao longo das versões e, também, por ser a > _última_ > plataforma portada. > > Estou ciente desses problema e esse upgrade está planejado, mas por enquanto tenho que trabalhar com o que tenho a disposição da melhor forma. Ugh? Como assim travamentos? O que os logs dizem? > > Os logs não dizem absolutamente *nada* (nem os logs de eventos do Windows)... simplesmente a saida do verbose do vacuum, por certos momentos, dá um pulo de horas... parece que algo acontece que o vacuum congela e depois de horas ele acorda novamente e termina... O último teste que efetuamos foi recriar a base de dados e o vacuum que levava (em dias normais) ~2h está demorando menos de 1h... nos momentos desses *travamentos* o vacuum executava em ~8h... fizemos inúmeros testes e a única coisa que resolveu o problema, num primeiro momento, foi reiniciar o servidor antes da manutenção, assim o vacuum ficava no seu tempo normalmde ~2h... mas com o drop/create da base agora leva menos de 1h... por isso minhas dúvidas quanto a essas tarefas de manutenção. (lembrando que esse servidor é um windows 2003 server) Cordialmente, -- Fabrízio de Royes Mello >> Blog sobre TI: http://fabriziomello.blogspot.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
