Flávio,
Em 5 de setembro de 2013 15:47, Flavio Henrique Araque Gurgel < [email protected]> escreveu: > Em 05-09-2013 15:31, JotaComm escreveu: > > Como autovacuum_vacuum_cost_limit = -1, ele usa vacuum_cost_limit. >>> Tá quanto lá? >>> >> >> >> postgres=# SHOW vacuum_cost_delay; >> vacuum_cost_delay >> ------------------- >> 0 >> (1 row) >> > > Cara, fiz uma confusão aqui. > > Acabei de olhar um post do Tom Lane (a orelha dele deve estar quente hoje) > explicando que a operação de vacuum para realocar os xids (prevent > wraparound) tem redução de velocidade proposital. Então, o valor de > vacuum_cost_limit e vacuum_cost_delay não vai ser observado. > > Ele é mais lento mesmo. > > > Mas faz assim pra acabar o mais rápido possível (só que vai fazer >>> I/O pra burro e interferir em transações, então, faça em horário de >>> baixo movimento): >>> SET vacuum_cost_delay = 0; >>> VACUUM ANALYZE tabela; >>> >> >> >> Pior é que o vaccum_cost_delay já está em 0. >> > > Então, um vacuum manual vai respeitar isso, o autovacuum to prevent > wraparound não vai. Então, o vacuum manual vai ser mais rápido. Pensei nisso também, de qualquer forma obrigado pela dica :) > > > > Se não der tempo/resolver, um dump/restore da tabela seria bem >>> vindo, já que ela não é tão grande, ou um CLUSTER. >>> >> >> >> O grande problema é que esta tabela deriva muitos relacionamentos, e >> isso será um problema, mas senão tiver solução, esta será a saída. >> > > Usando CLUSTER/VACUUM FULL você não precisa se preocupar com > relacionamentos, só com o lock exclusivo na tabela enquanto a operação rola. > Isso é digamos um pequeno grande problema devido a característica do sistema. > > Todavia, e já vi isso acontecer em cluster 8.3, o autovacuum to prevent > wraparound terminou. Um dia ele termina. Era um banco de dados extremamente > ocupado e não houve bloqueio de uso da tabela, ele terminou em tempo. > O problema é que semana retrasada eu já tive este mesmo sintoma, e precisei reiniciar o sistema por outro motivo, porém o pg_ctl stop -mf não conseguiu parar, ficou esperando pelo processo do autovacuum. Tive que usar a força bruta e fazer um shutdown. Agora na semana passada ele voltou com este autovacuum. > > Ah, a cada vez que se tenta cancelar o backend, parte do trabalho já feito > pode se perder e o processo começa do zero. Então, evite cancelar isso. > Detalhe interessante, porém acho que ele não esta conseguindo enviar o sinal para o processo :( > > Se você estiver realmente preocupado, você pode subir o PostgreSQL em modo > monousuário e fazer o vacuum na tabela sem ninguém te atrapalhando. > > Terei que usar esta abordagem em último caso, a dica é sempre válida. Obrigado. > > []s > > ______________________________**____ > Flavio Henrique A. Gurgel > Líder de Projetos Especiais > Consultoria, Projetos & Treinamentos 4LINUX > Tel1: +55-11.2125-4747 ou 2125-4748 > www.4linux.com.br > email: [email protected] > ______________________________ > FREE SOFTWARE SOLUTIONS > ______________________________**_________________ > pgbr-geral mailing list > [email protected].**org.br<[email protected]> > https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geral<https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral> > Abraços -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
