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

Re: [pgbr-geral] VACUUM FULL

2017-01-26 Por tôpico Fabrízio de Royes Mello 
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

> Como teste, rodei o VACUUM FULL apenas em uma tabela de 700mb e o
> diretório pg_xlog cresceu 400mb a mais e levou um tempo para ser
> liberado esse espaço adicional, esse comportamento é normal? 
> 

Sim. O VACUUM FULL reescreve os datafiles da sua tabela (heap + toast +
indexes), e isso quer dizer que ele faz "literalmente" uma cópia física
dos datafiles, ou seja, ele consome espaço em disco além do já utilizado
pelos datafiles atuais.

E além dos datafiles como qualquer operação transacional normal do
PostgreSQL (com exceção de Unlogged Tables) ele além de reescrever os
datafiles também escreve os logs de transações (diretório xlog).

Ele é implementado desta forma porque precisa garantir as
características "Atomicidade" e "Durabilidade" do ACID através das
técnicas de Write-ahead Logging [2]. E como os wal files são gerados
(pg_xlog) a replicação física poderá se beneficiar pois usa os registros
dos logs de transação para aplicar a mudança nas páginas também no(s)
slave(s).


> 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.

Att,


[1] https://www.postgresql.org.br/historico
[2] https://en.wikipedia.org/wiki/Write-ahead_logging

-- 
   Fabrízio de Royes Mello 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

[pgbr-geral] VACUUM FULL

2017-01-26 Por tôpico Danilo Silva 
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?

Como teste, rodei o VACUUM FULL apenas em uma tabela de 700mb e o diretório
pg_xlog cresceu 400mb a mais e levou um tempo para ser liberado esse espaço
adicional, esse comportamento é normal?

Em média, quanto tempo leva para o espaço em disco ocupado pelo VACUUM FULL
ser liberado?

[]s
Danilo
___
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 ANALYZE VERBOSE

2016-04-14 Por tôpico Luiz Carlos L. Nogueira Jr. 
Versão atualizada pra 9.3.12.
O problema aparentemente foi corrigido.
Fiz os mesmos testes .

[QUERY] VACUUM  FULL analyze verbose jbpm_byteblock
INFO:  vacuuming "public.jbpm_byteblock"
INFO:  "jbpm_byteblock": found 8994 removable, 18829714
nonremovable row versions in 2620337 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 71.97s/27.34u sec elapsed 231.67 sec.
INFO:  analyzing "public.jbpm_byteblock"
INFO:  "jbpm_byteblock": scanned 30 of 2619065 pages,
containing 2158397 live rows and 0 dead rows; 30 rows in sample,
18831267 estimated total rows
[QUERY] VACUUM  FULL analyze verbose jbpm_variableinstance
INFO:  vacuuming "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": found 679 removable, 12736203
nonremovable row versions in 225672 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 5.43s/8.46u sec elapsed 14.66 sec.
INFO:  analyzing "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": scanned 225654 of 225654 pages,
containing 12736203 live rows and 0 dead rows; 30 rows in sample,
12736203 estimated total rows
___
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 ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr. 
Flavio,

É uma questão que não depende só de mim, mas vou tentar.
___
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 ANALYZE VERBOSE

2016-04-06 Por tôpico Flavio Henrique Araque Gurgel 

Rafael,
Iremos fazer isso em breve.


Atualizar pra 9.3.12 é um processo simples, basta atualizar os binários 
e reiniciar o banco. É a única sugestão que você não seguiu e não 
entendemos o porquê.


Você não precisa ir "direto pra 9.5.2", entendo que você precisa 
corrigir o seu problema na versão em que está (9.3), sem impacto pras 
suas operações, mas com enorme diminuição de riscos e possíveis 
problemas. Deveria ser sua política por padrão, aliás a de todo mundo.


[]s
Flavio Gurgel
___
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 ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr. 
Rafael,
Iremos fazer isso em breve.
___
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 ANALYZE VERBOSE

2016-04-06 Por tôpico Rafael Fialho 
Em 6 de abril de 2016 09:01, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> 
> Se tiverem interesse de replicar o problema
>
> Tenham uma tabela grande (uns 30GB com blobs)
> façam um
> begin;
> muitos deletes (50% da base)
> commit;
> Vacuum full analyse verbose 
>
> Mesmo quando fiz:
> checkpoint
> Vacuum full analyse verbose 
>
> não fez diferença
>

Você já verificou a situação da atualização dos binários, como já relataram
anteriormente? Pelo que li nas mensagens, essa situação parece ter sido
ignorada.
Se não houve atualização da release, creio que seria um bom ambiente pra
você mesmo tentar fazer a reprodução do problema em uma versão atualizada.

[]'s
___
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 ANALYZE VERBOSE

2016-04-06 Por tôpico Luiz Carlos L. Nogueira Jr. 
Flávio,

Não estava ocorrendo backup na hora, inclusive o banco nem está no modo
archivelog. Ele é um banco que copiamos todo dia de produção pro ambiente
de homologação.

Euler,
Sim, mas não tinha nenhuma presa, inclusive nenhuma aplicação usa esse
banco. Ele só fica como template se pedirem pra criar uma cópia de testes
com a base de produção do dia anterior.


O que é estranho é que o banco está isolado, somente sendo utilizado por
mim (1 conexão), sem transações preparadas presas nem nada.
De manhã deu problema no vacuum full (logo após os deletes) e à tarde deu
certo, sem nenhuma intervenção.

Como o "paliativo" dos checkpoints deu certo, vamos "levando" dessa forma e
estamos nos programando já pra ir pra 9.5.2.

Mas que é estranho é.


Se tiverem interesse de replicar o problema

Tenham uma tabela grande (uns 30GB com blobs)
façam um
begin;
muitos deletes (50% da base)
commit;
Vacuum full analyse verbose 

Mesmo quando fiz:
checkpoint
Vacuum full analyse verbose 

não fez diferença
___
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 ANALYZE VERBOSE

2016-04-05 Por tôpico Euler Taveira 
On 05-04-2016 08:23, Luiz Carlos L. Nogueira Jr. wrote:
>  max_prepared_transactions   | 2000
>
Você utiliza transações preparadas?

> Apesar de ter resolvido o problema dando uma porrada de checkpoints, não
> acho que esse seja um comportamento "normal" para o banco
> 
Checkpoint não tem relação com isso. Algo (transação aberta, DELETE bem
recente, replicação) estava impedindo o avanço do id de transação. Como
você está utilizando um versão desatualizada (e repleta de bugs
conhecidos inclusive relacionado ao vacuum), sugiro que faça a
atualização e se o problema do VACUUM persistir, investigaremos.


-- 
   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 ANALYZE VERBOSE

2016-04-05 Por tôpico Flavio Henrique Araque Gurgel 

Euler,
Sem replicação.


E backup na hora do vacuum?

(...)


  server_version  | 9.3.4


Você ainda não atualizou. Lembra que eu disse que um bug relativo ao seu 
problema está corrigido?



Apesar de ter resolvido o problema dando uma porrada de checkpoints, não
acho que esse seja um comportamento "normal" para o banco


Não, não é normal.
1) Atualize, você deveria estar rodando 9.3.12
2) Veja se houve backup no momento do seu teste.

[]s
Flavio Gurgel
___
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 ANALYZE VERBOSE

2016-04-05 Por tôpico Luiz Carlos L. Nogueira Jr. 
Euler,
Sem replicação.



  name   |   current_setting
 |source|   sourcefile
  | sourceline
-+--+--+-+
 application_name| psql
| client   | |

 archive_command | cp /var/lib/pgsql/9.3/data/%p
/backup/wal/%f | configuration file   |
/var/lib/pgsql/9.3/data/postgresql.conf |196
 archive_mode| on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   194
 archive_timeout | 10min
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   200
 autovacuum_analyze_scale_factor | 0.02
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   467
 autovacuum_max_workers  | 9
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   459
 autovacuum_vacuum_scale_factor  | 0.05
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   466
 bgwriter_lru_maxpages   | 150
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   149
 checkpoint_segments | 25
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   186
 checkpoint_timeout  | 10min
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   187
 client_encoding | UTF8
| client   | |

 data_checksums  | off
 | override | |

 DateStyle   | ISO, MDY
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   511
 default_statistics_target   | 1000
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   286
 default_text_search_config  | pg_catalog.english
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   533
 effective_cache_size| 60GB
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   272
 lc_collate  | en_US.UTF-8
 | override | |

 lc_ctype| en_US.UTF-8
 | override | |

 lc_messages | en_US.UTF-8
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   526
 lc_monetary | en_US.UTF-8
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   528
 lc_numeric  | en_US.UTF-8
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   529
 lc_time | en_US.UTF-8
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   530
 listen_addresses| *
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
59
 lo_compat_privileges| on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   567
 log_autovacuum_min_duration | 0
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   455
 log_checkpoints | on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   392
 log_connections | on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   393
 log_destination | stderr
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   300
 log_directory   | pg_log
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   312
 log_disconnections  | on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   394
 log_filename| postgresql-%Y%m%d.log
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   314
 log_line_prefix | %t [%p]: [%l-1] db=%d,user=%u@%r %x:%v
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   398
 log_lock_waits  | on
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   418
 log_min_duration_statement  | 1s
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   380
 log_rotation_age| 1d
| configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   326
 log_rotation_size   | 100MB
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   328
 log_statement   | ddl
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   419
 log_temp_files  | 0
 | configuration file   | /var/lib/pgsql/9.3/data/postgresql.conf |
   420
 log_timezone| America/Recife
| configuration file   |

Re: [pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-04-04 Por tôpico Euler Taveira 
On 04-04-2016 09:26, Luiz Carlos L. Nogueira Jr. wrote:
> Não entendo o motivo desse comportamento.
> 
Você não apresentou o cenário do seu ambiente. Você possui replicação?
Quais os parâmetros diferente do padrão [1] da sua configuração?


[1] https://gist.github.com/eulerto/450501d8ef00404e665b46a2f2a6e8e2


-- 
   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 ANALYZE VERBOSE

2016-04-04 Por tôpico Luiz Carlos L. Nogueira Jr. 
Só consegui fazer o vacuum full depois de dar uma porrada de chekpoints na
base.
Mas com um checkpoint só não funcionou.
Não entendo o motivo desse comportamento.
___
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 ANALYZE VERBOSE

2016-04-01 Por tôpico Flavio Henrique Araque Gurgel 

select version();
PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit


9.3.4 -> 9.3.12
O release notes que te mandei já é da 9.3.6, você está bemm 
atrasado. Atualiza e depois nos diz se seu problema foi resolvido. Senão 
talvez tenhamos de ir lá na lista internacional, ou talvez a turma da 
Timbira tenha alguma ideia, eles estão mais por dentro do código que eu.



select * from pg_prepared_xacts
Sem linhas afetadas



Obrigado, não é teu caso.

[]s
Flavio Gurgel
___
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 ANALYZE VERBOSE

2016-04-01 Por tôpico Luiz Carlos L. Nogueira Jr. 
Completando

WITH list(file) AS (SELECT * FROM pg_ls_dir('pg_multixact/offsets'))
SELECT EXISTS (SELECT * FROM list WHERE file = '') AND
   NOT EXISTS (SELECT * FROM list WHERE file = '0001') AND
   NOT EXISTS (SELECT * FROM list WHERE file = '') AND
   EXISTS (SELECT * FROM list WHERE file != '')
   AS file__removal_required;

f
___
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 ANALYZE VERBOSE

2016-04-01 Por tôpico Luiz Carlos L. Nogueira Jr. 
Flávio,

select version();
PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-4), 64-bit

select * from pg_prepared_xacts
Sem linhas afetadas
___
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 ANALYZE VERBOSE

2016-04-01 Por tôpico Flavio Henrique Araque Gurgel 
Em qui, 31 de mar de 2016 22:28, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:

> versão 9.3
>
> Nesse contexto isso não é relavante.
>
> --É relevante porque eu garanto que não estão sendo incluídas nem apagadas
> as linhas. (pra naõ termos distorções nos valores)
>
> Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
> em até 30.000 linhas. Dessas linhas, ele estima que 12486234 são vivas (ou
> seja, estão validas) e 3070018 estão mortas (ou invalidas). Isso
> normalmente quer dizer que tua tabela está inchada devido ao comportamento
> do MVVC.
>
> --Nas duas tabelas foi feito um vacuum full antes, não devendo mais
> aparecer linhas mortas
>
> Oi Luiz

Verifique duas coisas, a primeira, qual a versão completa? Existe um bug já
corrigido que tem relação com vacuum, veja este release notes:
http://www.postgresql.org/docs/9.4/static/release-9-3-5.html

Se for seu caso, siga as instruções ao atualizar removendo o arquivo
indicado.

A segunda, me recordo que sua aplicação é escrita em Java. Veja se por
acaso não estão usando transações preparadas com um select na visão
pg_prepared_xacts

Se alguma transação não foi corretamente encerrada ela fica no servidor de
banco indefinidamente. Isso deixa locks, mesmo sem outros usuários
conectados e mesmo se o servidor foi reiniciado. Aí as tuplas não são
removidas.

[]s
Flavio Gurgel
___
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 ANALYZE VERBOSE

2016-03-31 Por tôpico Luiz Carlos L. Nogueira Jr. 
versão 9.3

Nesse contexto isso não é relavante.

--É relevante porque eu garanto que não estão sendo incluídas nem apagadas
as linhas. (pra naõ termos distorções nos valores)

Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
em até 30.000 linhas. Dessas linhas, ele estima que 12486234 são vivas (ou
seja, estão validas) e 3070018 estão mortas (ou invalidas). Isso
normalmente quer dizer que tua tabela está inchada devido ao comportamento
do MVVC.

--Nas duas tabelas foi feito um vacuum full antes, não devendo mais
aparecer linhas mortas
___
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 ANALYZE VERBOSE

2016-03-31 Por tôpico Sebastian Webber 
2016-03-31 16:10 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:

> [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock
> INFO:  vacuuming "public.jbpm_byteblock"
> INFO:  "jbpm_byteblock": found 15505882 removable, 18439352
> nonremovable row versions in 4762603 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> CPU 106.46s/45.32u sec elapsed 433.55 sec.
> INFO:  analyzing "public.jbpm_byteblock"
> INFO:  "jbpm_byteblock": scanned 30 of 2564994 pages,
> containing *2156123* live rows and 0 dead rows; 30 rows in sample,
> 18438821 estimated total rows
>
> [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_variableinstance
> INFO:  vacuuming "public.jbpm_variableinstance"
> INFO:  "jbpm_variableinstance": found 0 removable, 15556252
> nonremovable row versions in 283202 pages
> DETAIL:  3070018 dead row versions cannot be removed yet.
> CPU 7.59s/16.67u sec elapsed 65.72 sec.
> INFO:  analyzing "public.jbpm_variableinstance"
> INFO:  "jbpm_variableinstance": scanned 276005 of 276005
> pages, containing *12486234* live rows and *3070018* dead rows; 30
> rows in sample, 12486234 estimated total rows
>

Boa tarde!


>
> Não entendi esses números coloridos. O banco não tem nenhuma conexão, só a
> minha.
>

Nesse contexto isso não é relavante.


> O que significaria live rows no analyze? Não deveria ser igual ao
> nonremovable do vacuum full? (VERMELHO)
> Esse valor seria apenas das 30 páginas?
>

Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
em até 30.000 linhas. Dessas linhas, ele estima que 12486234 são vivas (ou
seja, estão validas) e 3070018 estão mortas (ou invalidas). Isso
normalmente quer dizer que tua tabela está inchada devido ao comportamento
do MVVC.


> Se sim por que na 2a tabela está diferente já que pegou todas as páginas?
>
> Aparentemente a diferença é que apenas umas das tabelas, o analyze
acredita que tenha mais tuplas mortas do que a outra.



> Por que existem dead rows, já que passei um vacuum full na tabela ? (AZUL)
>
> Qual seria a diferença do live rows do nonremovable rows?
>

Curioso isso. Ao meu ver o processo de vacuum full deveria reescrever o
datafile e sumir com essas paginas "mortas".  Qual é a versão do seu
PostgreSQL?

-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] VACUUM FULL ANALYZE VERBOSE

2016-03-31 Por tôpico Luiz Carlos L. Nogueira Jr. 
[QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock
INFO:  vacuuming "public.jbpm_byteblock"
INFO:  "jbpm_byteblock": found 15505882 removable, 18439352
nonremovable row versions in 4762603 pages
DETAIL:  0 dead row versions cannot be removed yet.
CPU 106.46s/45.32u sec elapsed 433.55 sec.
INFO:  analyzing "public.jbpm_byteblock"
INFO:  "jbpm_byteblock": scanned 30 of 2564994 pages,
containing *2156123* live rows and 0 dead rows; 30 rows in sample,
18438821 estimated total rows

[QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_variableinstance
INFO:  vacuuming "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": found 0 removable, 15556252
nonremovable row versions in 283202 pages
DETAIL:  3070018 dead row versions cannot be removed yet.
CPU 7.59s/16.67u sec elapsed 65.72 sec.
INFO:  analyzing "public.jbpm_variableinstance"
INFO:  "jbpm_variableinstance": scanned 276005 of 276005 pages,
containing *12486234* live rows and *3070018* dead rows; 30 rows in
sample, 12486234 estimated total rows

Não entendi esses números coloridos. O banco não tem nenhuma conexão, só a
minha.

O que significaria live rows no analyze? Não deveria ser igual ao
nonremovable do vacuum full? (VERMELHO)
Esse valor seria apenas das 30 páginas?
Se sim por que na 2a tabela está diferente já que pegou todas as páginas?

Por que existem dead rows, já que passei um vacuum full na tabela ? (AZUL)

Qual seria a diferença do live rows do nonremovable rows?

Não estou entendendo a diferença dos valores das linhas no vacuum e no
analyze.
___
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 não remove dead rows

2015-11-27 Por tôpico Euler Taveira 
On 24-11-2015 10:21, Bruno Silva wrote:
> Estou executando um vacuum full que me retorna 121000 dead rows em uma
> tabela que tem 1275820 registros.
> Porém o Vacuum Full sempre alega que não pode removê-las ainda.
> O que pode ocasionar isso?
> 
Isso me parece transação (preparada) em execução a algum tempo.


-- 
   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 não remove dead rows

2015-11-27 Por tôpico Bruno Silva 
Em 24 de novembro de 2015 15:53, JotaComm  escreveu:

>
> Em 24 de novembro de 2015 11:21, Bruno Silva 
> escreveu:
>
>> Estou executando um vacuum full que me retorna 121000 dead rows em uma
>> tabela que tem 1275820 registros.
>> Porém o Vacuum Full sempre alega que não pode removê-las ainda.
>> O que pode ocasionar isso?
>>
>
> ​Qual a mensagem que o vacuum full te retorna?
>
Opa Jota, desculpa a demora. Segue a mensagem:

INFO:  vacuuming "public.jbpm_taskinstance"
INFO:  "jbpm_taskinstance": found 2 removable, 1308649 nonremovable row
versions in 32918 pages
DETAIL:  6710 dead row versions cannot be removed yet.
CPU 0.79s/3.19u sec elapsed 4.98 sec.
INFO:  analyzing "public.jbpm_taskinstance"
INFO:  "jbpm_taskinstance": scanned 28088 of 28088 pages, containing
1301939 live rows and 6711 dead rows; 3 rows in sample, 1301939
estimated total rows

Dessa vez baixou o valor

>
> Qual o resultado da seguinte consulta:
>
> SELECT * FROM pg_stat_user_tables WHERE
> pg_stat_user_tables.relname='tabela';​
>
>
 relid  | schemaname |  relname  | seq_scan | seq_tup_read |
 idx_scan  | idx_tup_fetch | n_tup_ins | n_tup
_upd | n_tup_del | n_tup_hot_upd | n_live_tup | n_dead_tup |
 last_vacuum  |last_autovacuum
| last_analyze  |   last_autoanalyze|
vacuum_count | autovacuum_count | analyze
_count | autoanalyze_count
++---+--+--++---+---+--
-+---+---+++---+---
+---+---+--+--+
---+---
 545066 | public | jbpm_taskinstance |  466 |456619799 |
2271467371 |1306388791 |124854 |75
1489 | 0 | 27221 |1301964 |   6838 | 2015-11-24
10:03:26.987608-03 | 2015-11-27 08:02:52.34
5902-03 | 2015-11-27 09:01:10.851671-03 | 2015-11-26 11:12:02.149513-03 |
 2 |3 |
 4 | 5


>> PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC)
>> 4.4.7 20120
>> 313 (Red Hat 4.4.7-16), 64-bit
>>
>> Bruno E. A. Silva.
>>
>


Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
MBA Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
"Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!"
___
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 não remove dead rows

2015-11-24 Por tôpico JotaComm 
Opa!

Em 24 de novembro de 2015 11:21, Bruno Silva 
escreveu:

> Estou executando um vacuum full que me retorna 121000 dead rows em uma
> tabela que tem 1275820 registros.
> Porém o Vacuum Full sempre alega que não pode removê-las ainda.
> O que pode ocasionar isso?
>

​Qual a mensagem que o vacuum full te retorna?

Qual o resultado da seguinte consulta:

SELECT * FROM pg_stat_user_tables WHERE
pg_stat_user_tables.relname='tabela';​


>
> PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
> 20120
> 313 (Red Hat 4.4.7-16), 64-bit
>
> Bruno E. A. Silva.
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



Abraços​

-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum Full não remove dead rows

2015-11-24 Por tôpico Bruno Silva 
Estou executando um vacuum full que me retorna 121000 dead rows em uma
tabela que tem 1275820 registros.
Porém o Vacuum Full sempre alega que não pode removê-las ainda.
O que pode ocasionar isso?

PostgreSQL 9.3.10 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120
313 (Red Hat 4.4.7-16), 64-bit

Bruno E. A. Silva.
___
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 não reduz espaço/linhas removidas

2015-03-03 Por tôpico Matheus de Oliveira 
2015-03-02 21:38 GMT-03:00 Fábio Gibon gi...@comexsystem.com.br:

 tenho uma tabela com 184MB, porém consultando o inchaço dela me
 mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas
 mostra 6300 n_live_tup e 168000 n_dead_tup.

 Fiz um create table as select e a nova tabela ficou com 7MB (e com
 6300 linhas, obviamente).

 Por que o vacuum full não recupera este espaço em disco para esta
 tabela? Alguma dica?



Pode ser que tenha alguma transação muito antiga ainda aberta que esteja
impossibilitando o VACUUM de eliminar algumas tuplas. Verifique a view
pg_stat_activity (coluna xact_start) e a view pg_prepared_xact (coluna
prepared) e veja se não há transações antigas no seu banco.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
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 não reduz espaço/linhas removidas

2015-03-03 Por tôpico Fabrízio de Royes Mello 
On 02-03-2015 21:38, Fábio Gibon wrote:
 Pessoal,
 
 tenho uma tabela com 184MB, porém consultando o inchaço dela me
 mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas
 mostra 6300 n_live_tup e 168000 n_dead_tup.
 
 Fiz um create table as select e a nova tabela ficou com 7MB (e com
 6300 linhas, obviamente).
 
 Por que o vacuum full não recupera este espaço em disco para esta
 tabela? Alguma dica?
 

Qual a versão do PostgreSQL?

-- 
   Fabrízio de Royes Mello 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 não reduz espaço/linhas removidas

2015-03-02 Por tôpico Sebastian Webber 
Em 2 de março de 2015 21:38, Fábio Gibon gi...@comexsystem.com.br
escreveu:

 Pessoal,

 tenho uma tabela com 184MB, porém consultando o inchaço dela me
 mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas
 mostra 6300 n_live_tup e 168000 n_dead_tup.



 Fiz um create table as select e a nova tabela ficou com 7MB (e com
 6300 linhas, obviamente).


Normalmente isso não cria os índices. Tentou rodar um select
pg_relation_size e comparar com o pg_total_relation_size?


 Por que o vacuum full não recupera este espaço em disco para esta
 tabela? Alguma dica?


o que tinha na saida do vacuum (full| verbose)?

[]'s


-- 
Sebastian Webber
http://swebber.me
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum full não reduz espaço/linhas removidas

2015-03-02 Por tôpico Fábio Gibon 
Pessoal,

tenho uma tabela com 184MB, porém consultando o inchaço dela me
mostra que a mesma deveria ter menos de 7MB. Nas estatísticas atualizadas
mostra 6300 n_live_tup e 168000 n_dead_tup.

Fiz um create table as select e a nova tabela ficou com 7MB (e com
6300 linhas, obviamente).

Por que o vacuum full não recupera este espaço em disco para esta
tabela? Alguma dica?

-- 
sds

Fábio Henrique Gibon
___
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 - informação de execução

2011-11-08 Por tôpico Leonardo Carneiro 
2011/11/8 Euler Taveira de Oliveira eu...@timbira.com

 On 07-11-2011 19:55, Fábio Gibon - Comex System wrote:
  o vacuum com a opção de full não fica registrado na pg_stat_all_tables
 (em
  last_vacuum). Há algum local do dicionário de dados que eu encontro a
 data do
  último vacuum full de uma tabela?
 
 Isso é verdade a partir da versão 9.0 (quando o VACUUM FULL foi substituído
 por CLUSTER internamente) e está documentado [1]. Talvez algum dia alguém
 corrija isso mas como o VF é uma operação programada (e esporádica) em um
 ambiente de produção não vejo problema em não reportar essa estatística (já
 que sei quando ela é disparada).



Interessante essa info sobre o vacuum full. Algumas pessoas comentaram
durante o pgbr que o vacuum full não deveria ser usado antes da versão 9
sem executar reindex, pois iria ser prejudicial aos índices.

Existe alguma documentação dessa mudança do funcionamento do VACUUM FULL
ser igual ao CLUSTER?

Att.
Leonardo Chester Carneiro
___
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 - informação de execução

2011-11-08 Por tôpico Euler Taveira de Oliveira 
On 08-11-2011 07:51, Leonardo Carneiro wrote:
 Interessante essa info sobre o vacuum full. Algumas pessoas comentaram durante
 o pgbr que o vacuum full não deveria ser usado antes da versão 9 sem executar
 reindex, pois iria ser prejudicial aos índices.

Eu não o recomendado desde 7.4. A implementação antiga do VF inchava os 
índices ao longo do tempo mas a implementação atual não.

 Existe alguma documentação dessa mudança do funcionamento do VACUUM FULL ser
 igual ao CLUSTER?

É um detalhe de implementação. A única menção que há é nas notas de lançamento 
da versão 9.0. Vale ressaltar que não é igual, ele utiliza a mesma rotina do 
CLUSTER para recuperar espaço não utilizado.


-- 
Euler Taveira de Oliveira - 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

[pgbr-geral] Vacuum full - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System 
Pessoal,
 o vacuum com a opção de full não fica registrado na pg_stat_all_tables 
(em last_vacuum). Há algum local do dicionário de dados que eu encontro a data 
do último vacuum full de uma tabela?

abraços
 
Fábio Henrique Gibon___
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 - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System 
Complementando... versão 9.0.3

  - Original Message - 
  From: Fábio Gibon - Comex System 
  To: PostgreSQL - BR List 
  Sent: Monday, November 07, 2011 7:55 PM
  Subject: [pgbr-geral] Vacuum full - informação de execução


  Pessoal,
   o vacuum com a opção de full não fica registrado na 
pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que 
eu encontro a data do último vacuum full de uma tabela?

  abraços
   
  Fábio Henrique Gibon


--


  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
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 - informação de execução

2011-11-07 Por tôpico JotaComm 
Olá, Fábio

Em 7 de novembro de 2011 21:22, Fábio Gibon - Comex System 
gi...@comexsystem.com.br escreveu:

 **
 Complementando... versão 9.0.3


 - Original Message -
 *From:* Fábio Gibon - Comex System gi...@comexsystem.com.br
 *To:* PostgreSQL - BR List pgbr-geral@listas.postgresql.org.br
 *Sent:* Monday, November 07, 2011 7:55 PM
 *Subject:* [pgbr-geral] Vacuum full - informação de execução

 Pessoal,
  o vacuum com a opção de full não fica registrado na
 pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados
 que eu encontro a data do último vacuum full de uma tabela?


 A execução do vacuum fica registrado na tabela pg_stat_user_tables,
tabelas criadas pelo usuário. O registro é do último vacuum independente se
é vacuum full ou vacuum.



 abraços

 Fábio Henrique Gibon

 --

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


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



Abraços
-- 
JotaComm
http://jotacomm.wordpress.com
___
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 - informação de execução

2011-11-07 Por tôpico Fábio Gibon - Comex System 
JotaComm,
 obrigado pelo retorno, mas infelizmente nos testes que fiz não 
funciona. Ah, a pg_stat_user_tables é uma view sobre a view que citei 
(pg_stat_all_tables).

vacuum tabela - registra
vacuum full tabela - não registra

Alguma outra dica? Será que tem algum parâmetro diferente nas bases que testei?

um abraço
Gibon
  - Original Message - 
  From: JotaComm 
  To: Fábio Gibon - Comex System ; Comunidade PostgreSQL Brasileira 
  Sent: Monday, November 07, 2011 8:59 PM
  Subject: Re: [pgbr-geral] Vacuum full - informação de execução


  Olá, Fábio


  Em 7 de novembro de 2011 21:22, Fábio Gibon - Comex System 
gi...@comexsystem.com.br escreveu:

Complementando... versão 9.0.3

  - Original Message - 
  From: Fábio Gibon - Comex System 
  To: PostgreSQL - BR List 
  Sent: Monday, November 07, 2011 7:55 PM
  Subject: [pgbr-geral] Vacuum full - informação de execução


  Pessoal,
   o vacuum com a opção de full não fica registrado na 
pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que 
eu encontro a data do último vacuum full de uma tabela?

  A execução do vacuum fica registrado na tabela pg_stat_user_tables, tabelas 
criadas pelo usuário. O registro é do último vacuum independente se é vacuum 
full ou vacuum. 


  abraços
   
  Fábio Henrique Gibon


--


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




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




  Abraços
  -- 
  JotaComm
  http://jotacomm.wordpress.com
___
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 - informação de execução

2011-11-07 Por tôpico Euler Taveira de Oliveira 
On 07-11-2011 19:55, Fábio Gibon - Comex System wrote:
 o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em
 last_vacuum). Há algum local do dicionário de dados que eu encontro a data do
 último vacuum full de uma tabela?

Isso é verdade a partir da versão 9.0 (quando o VACUUM FULL foi substituído 
por CLUSTER internamente) e está documentado [1]. Talvez algum dia alguém 
corrija isso mas como o VF é uma operação programada (e esporádica) em um 
ambiente de produção não vejo problema em não reportar essa estatística (já 
que sei quando ela é disparada).


[1] 
http://www.postgresql.org/docs/current/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE


-- 
Euler Taveira de Oliveira - 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 Silmutaneo é possíve l?

2010-10-07 Por tôpico jeffersondias 

Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas.
Percebo que não é usado quase nada de Processamento do servidor e nem de
memória.

Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao
invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos.
Isso pode dar algum problema?
-- 
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Vacuum-Full-Silmutaneo-e-possivel-tp3201953p3202817.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
___
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 Silmutaneo é possível ?

2010-10-07 Por tôpico Jefferson Dias 

Uma vez por semana (domingo inteiro hoje) Sim eu rodo do catalogo mas rodo um a 
um e isso demora 22h . 
A maior tabela demora 8h ai dividiria em varios arquivos a fim de fazer todo 
esse vaccum em 8 horas ao  invéz de 22h e colocaria eles no crontab do linux.
Bem o banco tem 6 processadores six core e 128Gb de memória o banco esta com 
150Gb de uso hoje.



Date: Wed, 6 Oct 2010 17:38:02 -0300
From: fabriziome...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral]   Vacuum Full Silmutaneo é possível?




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

O que pode ser feito é criar um script para rodar o vaccum
individualmente em tabelas da tua base de dados, tendo como ponto de
partida o catálogo do PostgreSQL, ou seja, ler as tabelas do catálogo e
rodar o vaccum nelas, seja uma a uma ou algumas simultâneas... mas
tenha cuidado em executar vacuum simultaneo em tabelas muito grandes...

Não sei como vc definiu a periodicidade das tuas
manutenções, mas creio que um vacuum full não seja necessário
diariamente... vc usa autovacuum?? No autovacuum (apartir da 8.3) tem
uma opcao chamada max_workers que realiza exatamente isso, realiza mais
de um vaccum ao mesmo tempo em objetos que necessitem que seja
realizada a manutenção.

-- 
Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: 
 http://br.linkedin.com/in/fabriziomello




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





Em 6 de outubro de 2010 16:36, jeffersondias jefferso...@hotmail.com escreveu:



Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas.

Percebo que não é usado quase nada de Processamento do servidor e nem de

memória.



Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao

invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos.

Isso pode dar algum problema?


  ___
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 Silmutaneo é possível ?

2010-10-07 Por tôpico Osvaldo Kussama 
Em 6 de outubro de 2010 16:36, jeffersondias jefferso...@hotmail.com escreveu:

 Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas.
 Percebo que não é usado quase nada de Processamento do servidor e nem de
 memória.

 Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao
 invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos.
 Isso pode dar algum problema?
 --


Repare no que diz o manual:
The FULL option is not recommended for routine use, but might be
useful in special cases.
http://www.postgresql.org/docs/current/interactive/sql-vacuum.html

Osvaldo
___
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 Silmutaneo é possível ?

2010-10-07 Por tôpico Euler Taveira de Oliveira 
Jefferson Dias escreveu:
 Uma vez por semana (domingo inteiro hoje) Sim eu rodo do catalogo mas
 rodo um a um e isso demora 22h .
 A maior tabela demora 8h ai dividiria em varios arquivos a fim de fazer
 todo esse vaccum em 8 horas ao  invéz de 22h e colocaria eles no crontab
 do linux.
 Bem o banco tem 6 processadores six core e 128Gb de memória o banco esta
 com 150Gb de uso hoje.
 
Qual é a versão do PostgreSQL? Quais são os valores dos parâmetros
vacuum_cost_*? Não é recomendado executar VACUUM FULL porque ele gera muita
I/O e incha os índices. O recomendado é habilitar o autovacuum e de tempos em
tempos utilizar CLUSTER e/ou REINDEX para reorganizar as tuplas das tabelas e
índices.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum Full Silmutaneo é possíve l?

2010-10-06 Por tôpico jeffersondias 

Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas.
Percebo que não é usado quase nada de Processamento do servidor e nem de
memória.

Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao
invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos.
Isso pode dar algum problema?
-- 
View this message in context: 
http://postgresql.1045698.n5.nabble.com/Vacuum-Full-Silmutaneo-e-possivel-tp3201953p3201953.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
___
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 Silmutaneo é possível ?

2010-10-06 Por tôpico Fabrízio de Royes Mello 
Em 6 de outubro de 2010 16:36, jeffersondias jefferso...@hotmail.comescreveu:


 Quando rodo o Vacuum em todas as tabelas isso leva quase 24horas.
 Percebo que não é usado quase nada de Processamento do servidor e nem de
 memória.

 Consigo ou posso rodar vacuum simultaneamente (vacuumdb -f -v -z -d ) ao
 invez de hoje q faço um a um eu rodar varios vaccumdb simutaneos.
 Isso pode dar algum problema?



O que pode ser feito é criar um script para rodar o vaccum individualmente
em tabelas da tua base de dados, tendo como ponto de partida o catálogo do
PostgreSQL, ou seja, ler as tabelas do catálogo e rodar o vaccum nelas, seja
uma a uma ou algumas simultâneas... mas tenha cuidado em executar vacuum
simultaneo em tabelas muito grandes...

Não sei como vc definiu a periodicidade das tuas manutenções, mas creio que
um vacuum full não seja necessário diariamente... vc usa autovacuum?? No
autovacuum (apartir da 8.3) tem uma opcao chamada max_workers que realiza
exatamente isso, realiza mais de um vaccum ao mesmo tempo em objetos que
necessitem que seja realizada a manutenção.

-- 
Fabrízio de Royes Mello
 Blog sobre TI: http://fabriziomello.blogspot.com
 Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Vacuum full e analyse

2010-08-27 Por tôpico marlon david de souza 
Bom dia a todos,

 

  Tenho a seguinte dúvida: dento do processo do vaccum full já é feito o
processo de analyse ou é necessário executar os dois processos
separadamente?

 

Sem mais,

 

Marlon David de Souza

Desenvolvedor

 

___
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 e analyse

2010-08-27 Por tôpico JotaComm 
Olá,
Em 27 de agosto de 2010 11:37, marlon david de souza
mar...@sysmo.com.brescreveu:

  Bom dia a todos,



   Tenho a seguinte dúvida: dento do processo do *vaccum full* já é feito o
 processo de *analyse* ou é necessário executar os dois processos
 separadamente?


Depende.

Se você simplesmente digitar VACUUM FULL no ambiente do psql somente
executará o vacuum, para executar o analyze é necessário especifica-lo como
parte do comando.

VACUUM FULL ANALYZE VERBOSE;



 *Sem mais,*

 * *

 *Marlon David de Souza*

 *Desenvolvedor*



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



[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral