Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Euler Taveira 
On 27-01-2017 14:51, Danilo Silva wrote:
> ​OK, achei no histórico [1] um tópico onde fala que podemos nos basear
> pela view pg_stat_all_tables (coluna n_dead_tup) para verificar a
> eficiência do autovacuum, mas em relação a coluna n_dead_tup, qual
> número seria relevante, fazer valer a pena, para executarmos​ um VACUUM
> FULL? Pergunto isso pois estou com problemas de espaço em disco, então
> estamos tentando tirar cada Mb de onde der pra tirar, mas não queremos
> comprometer a eficiência do banco.
> 
A cada disparo do autovacuum, n_dead_tup é reiniciado. Não dá para
confiar nele se o autovacuum estiver ativado. VF é péssimo para
ambientes com restrição de espaço (a não ser que sua versão seja < 9.0),
como disse o Fabrizio, o postgres pode utilizar até o dobro de espaço
dos datafiles da tabela e índices.

Para detectar o inchaço real, use o pgstattuple (em um horário com baixa
atividade pois ele pode ler *todos* os blocos da relação). Ele vai te
dar o valor exato do inchaço na tabela ou índice. A partir da 9.5 existe
uma versão aproximada para tabelas que é mais rápida por não ler todos
os blocos; use-a, se possível.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Leandro Guimaraens Faria Corcete DUTRA 
Le ven. 27 janv. 2017 à 15:51, Danilo Silva 
 a écrit :
Pergunto isso pois estou com problemas de espaço em disco, então 
estamos tentando tirar cada Mb de onde der pra tirar, mas não 
queremos comprometer a eficiência do banco.


Problemas de espaço em disco são perigosíssimos para a 
disponibilidade de um sistema de dados.  Considere outras medidas de 
economia, como por exemplo arquivamento de informações históricas 
(‘arquivo morto’) fora de linha, e (ou) eliminação de algumas 
chaves artificiais (/surrogate keys/, ou identificadores [IDs]) em 
favor de naturais (ainda que compostas)...


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] VACUUM FULL

2017-01-27 Por tôpico Danilo Silva 
Em 26 de janeiro de 2017 13:53, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 26-01-2017 12:19, Danilo Silva wrote:
> > Pessoal,
> >
> > Atualmente utilizo a versão 9.3 com replicação nativa para um escravo,
> > fazendo cópia dos archives para o escravo + servidor de backup.
> >
> > Como podemos identificar a necessidade ou não de rodar um VACUUM FULL?
> >
>
> Se vc der uma pesquisada no histórico [1] desta lista irá encontrar
> diversas discussões a respeito de como detectar inchaço de objetos
>

​OK, achei no histórico [1] um tópico onde fala que podemos nos basear pela
view pg_stat_all_tables (coluna n_dead_tup) para verificar a eficiência do
autovacuum, mas em relação a coluna n_dead_tup, qual número seria
relevante, fazer valer a pena, para executarmos​ um VACUUM FULL? Pergunto
isso pois estou com problemas de espaço em disco, então estamos tentando
tirar cada Mb de onde der pra tirar, mas não queremos comprometer a
eficiência do banco.


>
> > Em média, quanto tempo leva para o espaço em disco ocupado pelo VACUUM
> > FULL ser liberado?
> >
>
> Difícil mensurar isso porque, por exemplo, seu servidor pode estar
> retendo wal files porque seu procedimento de archive pode estar
> demorando por latência de rede ou algo do gênero. Com archive_mode
> ligado e o archive_command devidamente configurado o PostgreSQL só irá
> reciclar o wal (remover segmentos antigos do pg_xlog) quando o
> arquivamento for bem sucedido. Entao se vc faz um "scp" ou "rsync", por
> exemplo, o sinal de que o segmento foi copiado com sucesso para outro
> local só será enviado ao PostgreSQL após o comando ser executado.
>
> Note que eu apenas "imaginei" um cenário baseado nas informações que
> você forneceu, mas existem outras variáveis a considerar.
>

​Quais seriam essas variáveis?

[1]
https://listas.postgresql.org.br/pipermail/pgbr-geral/2015-March/040234.html

[]s
Danilo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral