Srs Retornando para dar um feedback e agradecendo o apoio, resolvemos o problema desabilitando o parâmetro abaixo:
autovacuum_vacuum_cost_delay = -1 Este parâmetro estava setado no valor default 20s. http://www.postgresql.org/docs/9.1/static/runtime-config-autovacuum.html Neste momento o daemon(autovacuum) não aguarda mais por 20s ele executa independentemente se a tabela estiver sendo muito requisitada ou não.Entendemos que isto pode ter um impacto em IO, por isto continuamos monitorando.Mas não temos um autovacuum em uma tabela de sistema demorando mais de 2000s. att Em 13 de junho de 2012 17:38, Tiago Valério <[email protected]>escreveu: > > > Em 13 de junho de 2012 15:52, Euler Taveira <[email protected]> escreveu: > > On 13-06-2012 14:25, Tiago Valério wrote: >> > Possuimos funções que criam tabelas temporárias do tipo on commit >> drop, estas >> > funções rodam frequentemente e isto esta gerando um gargalo na execução >> do >> > daemon autovacuum conforme resumo abaixo.Em especial gostaria de citar a >> > pg_catalog.pg_attribute com seus 4599 segundos de execução constante. >> Essas >> > tabelas da pg_catalog terminam o vacuum e iniciam novamente num ciclo >> sem fim. >> > >> Com log_autovacuum_min_duration = 0 capture todas as execuções do >> autavacuum >> na tabela pg_catalog.pg_attribute. Um tempo de execução alto do >> autovacuum não >> é normal se ele não estiver mal configurado. >> >> Qual o tamanho dessa tabela? >> >> SELECT pg_relation_size(oid),reltuples,relpages FROM pg_class WHERE >> relname = >> 'pg_attribute'; >> >> 1334796288 8284 162939 > > > >> Qual a saída da consulta abaixo em um determinado intervalo: >> >> select now(),* from pg_stat_sys_tables where relname = 'pg_attribute'; >> >> > Para um intervalo de1 minuto aproximadamente. > > 2012-06-13 17:27:32.720202-03 1249 pg_catalog pg_attribute 355556 2411208 > 3424253774 11110786336 704558131 40 704512163 17 8284 2317852 2012-06-13 > 14:53:51.335012-03 2012-06-13 17:00:00.41695-03 2012-06-11 > 18:02:28.787207-03 2012-06-13 17:06:36.313106-03 14 1864 2 1833 > > 2012-06-13 17:28:31.091304-03 1249 pg_catalog pg_attribute 355578 2411350 > 3424344943 11111095351 704583613 40 704537645 17 8284 2343334 2012-06-13 > 14:53:51.335012-03 2012-06-13 17:00:00.41695-03 2012-06-11 > 18:02:28.787207-03 2012-06-13 17:06:36.313106-03 14 1864 2 1833 > > > >> > select count (*) from pg_catalog.pg_attribute >> > 8943 >> > rows >> > >> Com esse número de tuplas a execução do autovacuum deveria ser rápida. >> Qual é >> a saída do comando abaixo (se é que o processo do autovacuum na >> pg_attribute >> ainda existe): >> >> strace -p 21225 >> > > > >> >> > Aumentamos o autovacuum_max_workers para 10 e mesmo assim todos eles >> ficam >> > alocados o tempo todo.O que pode estar acontecendo? >> > >> Há alguma menção nos logs de uma mensagem no estilo 'canceling autovacuum >> task'? >> > > Não > >> >> >> -- >> Euler Taveira de Oliveira - 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
