Euller, O parâmetro autovacuum_vacuum_cost_delay está em 20 ms. Sobre o FREEZE, acredito que não seria o caso, porque na teoria, ele só seria problema se não estivesse habilitado o auto_vacuum, correto? A operação FREEZE, congela as linhas para não ser alterada e reinicia o contador de transações, correto? Porque seria realizado essa operação nesse momento? 24MB eu medi através do comando "top" do linux, encontrei o PID da operação e calculei o consumo da memória, porque no comando top é exibido a porcentagem consumida de memória para cada processo, com base na memória total, apenas fiz um calculo para chegar nos 24MB. Sobre a quantidade de 6Bytes por tupa não vigente, se multiplicar 6Bytes * 55577 (tuplas não vigentes) = 333462 Bytes / 1024 (transformar para KB) = 325 KB aproximadamente, isso não equivale a 24MB. Sobre o auto-vacuum estar desabilitado, fiz a conferencia na tabela e concluí que não está desabilitado. Para a base de dados, também está habilitado.
Obrigado. De: "Euler Taveira" <[email protected]> Para: "Comunidade PostgreSQL Brasileira" <[email protected]> Enviadas: Quarta-feira, 4 de maio de 2016 1:52:03 Assunto: Re: [pgbr-geral] [memória autovacuum] On 03-05-2016 16:17, Daniel Luiz da Silva wrote: > - mesmo utilizando 24MB, na sessão, e demorando 40 mintuos, porque não > utilizou total disponível 32MB, como funciona o rastreio de tuplas não > vigentes? > Ele pode ter demorado tanto tempo assim porque a tabela está muito inchada e/ou o autovacuum_vacuum_cost_delay está alto. Outra teoria é porque ele estava fazendo FREEZE. Quanto ao tamanho, como você mediu os 24 MB? Para o rastreio são geralmente 6 bytes por tupla não vigente. Além disso, o worker não é só memória para rastreio. Como você mediu 24 MB? RES? VIRT? > - é um processo do autovacuum, e não wrap-around; > Tenha em mente que o autovacuum pode disparar para realizar ação anti-wraparound. > - Segue estatísticas da tabela: > 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 > > "tbsession";33874;63090745;64590117;62505457;1051135;31172552;1050387;29656406;2159;55577;"30/04/2016 > > 13:07:15";"03/05/2016 16:01:44";"30/04/2016 13:07:15";"03/05/2016 16:01:45" > Tamanho total 11.3GB > A sua tabela está exageradamente inchada (2159 tuplas vigentes e 55.577 tuplas não-vigentes). Para ter 11 GB, deve haver muitas páginas quase vazias. Neste caso, eu aconselho executar o VACUUM FULL para voltar ao tamanho normal. O autovacuum está desabilitado nessa tabela? > Minha preocupação final além disso é porque trata-se uma tabela com muio > update, ou seja, muito inchada, porém, estou estudando para entender > e tratar essa tabela. > Talvez você precise de: (i) valores personalizados do autovacuum ou (ii) uma rotina manual. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ 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
