2013/9/5 JotaComm <[email protected]> > Bom dia!!! > > > Em 5 de setembro de 2013 09:07, Matheus de Oliveira < > [email protected]> escreveu: > > >> 2013/9/4 JotaComm <[email protected]> >> >>> >>> Pessoal, >>> >>> Boa tarde!!! >>> >>> >> Opa. Bom dia, =D... >> >> >>> Vou expor o meu problema e gostaria de saber se alguém já passou por >>> situação semelhante: >>> >>> Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27 18:58: >>> 41.527238-03, no entanto a tabela não é grande: 5.428.982 - (8243 MB >>> incluindo indices). >>> >>> Estou achando muito estranho a demora e não encontrei nada que me >>> indicasse problema, porém tenho tabelas maiores e o vaccum roda >>> normalmente. Tentei cancelar o processo e não obtive sucesso: >>> >>> billing=# SELECT localtimestamp(0); >>> -[ RECORD 1 ]------------------ >>> timestamp | 2013-09-04 11:23:06 >>> >>> billing=# SELECT >>> pg_stat_activity.procpid,pg_stat_activity.current_query,pg_stat_activity.query_start >>> FROM pg_stat_activity WHERE pg_stat_activity.current_query ~ >>> 'public.mensagem' AND pg_stat_activity.procpid!=pg_backend_pid(); >>> -[ RECORD 1 >>> ]-+----------------------------------------------------------- >>> procpid | 2738 >>> current_query | autovacuum: VACUUM public.mensagem (to prevent >>> wraparound) >>> query_start | 2013-08-27 18:58:41.527238-03 >>> >>> billing=# SELECT pg_cancel_backend(2738); >>> -[ RECORD 1 ]-----+-- >>> pg_cancel_backend | t >>> >>> billing=# SELECT localtimestamp(0); >>> -[ RECORD 1 ]------------------ >>> timestamp | 2013-09-04 11:23:18 >>> >>> billing=# SELECT >>> pg_stat_activity.procpid,pg_stat_activity.current_query,pg_stat_activity.query_start >>> FROM pg_stat_activity WHERE pg_stat_activity.current_query ~ >>> 'public.mensagem' AND pg_stat_activity.procpid!=pg_backend_pid(); >>> -[ RECORD 1 >>> ]-+----------------------------------------------------------- >>> procpid | 2738 >>> current_query | autovacuum: VACUUM public.mensagem (to prevent >>> wraparound) >>> query_start | 2013-08-27 18:58:41.527238-03 >>> >>> >> Sempre que consultar a pg_stat_activity, inclua a coluna waiting. >> Acredito que você omitiu a principal informação para ajudarmos a resolver o >> problema. >> >> >> Outras informações: >>> >>> procpid | 2738 >>> relname | mensagem >>> current_query | autovacuum: VACUUM public.mensagem (to prevent >>> wraparound) >>> query_start | 2013-08-27 18:58:41.527238-03 >>> virtualtransaction | 3/301 >>> mode | ShareUpdateExclusiveLock >>> n_tup_ins | 448414 >>> n_tup_upd | 2665536 >>> n_tup_del | 0 >>> n_live_tup | 448375 >>> n_dead_tup | 1129161 >>> last_vacuum | >>> last_autovacuum | >>> last_analyze | >>> last_autoanalyze | >>> >>> >> Bom, apesar de *você não informar* qual foi essa última consulta, vejo >> que é um join entre pg_stat_activity, pg_locks e pg_stat_user_tables, e, >> pelo ShareUpdateExclusiveLock podemos assumir que o VACUUM está bloqueado >> (por favor, inclua a coluna pg_locks.granted ou pg_stat_activity.waiting >> para garantir). Bom, agora temos que descobrir quem está bloqueando o >> VACUUM, eu chutaria, pelo tempo, que você está usando "prepared >> transactions", por favor verifique o resultado da consulta (conectado à >> base em questão): >> > > Exato, é um JOIN entre estas tabelas. O vacuum não está bloqueado (waiting > = FALSE) e em pg_locks granded=TRUE. Não tenho prepared statements > bloqueadas neste banco. > > O mais estranho é que não consigo "matar", conforme descrevi acima. > > Essa questão de não conseguir "matar" o processo é mesmo estranha (será algum bug?)... Tente usar o pg_terminate_backend ao invés do pg_cancel_backend, pois o primeiro é um pouco mais agressivo...
Logo depois disso é possível que o autovacuum seja disparado nessa tabela novamente, se não terminar rápido "de novo", tente desabilitar temporariamente o autovacuum "só para essa tabela" e tente fazer o vacuum na mão com verbose e ver se te dé alguma pista. > > >> SELECT * FROM pg_prepared_xacts; >> >> E verifique se alguma pode ser "matada" (provavelmente uma com o >> timestamp "prepared" antigo), se puder execute o seguinte para matá-la: >> > > Não tem nada lá. > >> >> ROLLBACK PREPARED 'foo'; >> > > Já havia feito as duas análises: O vacuum não esta bloqueado e também não > há nada nesta view. > >> >> Onde "foo" seria o identificador da transação, que pode ser recuperado na >> coluna "gid". >> >> >> A versão do PostgreSQL é a 9.0.4. >>> >>> >> Atualize imediatamente (sem desculpas) para a versão 9.0.13 (ou se puder, >> para a 9.2.4, mas essa não precisa do "imediatamente", =P ). >> >> A versão do SO é CentOS release 6.3 (Final). >>> >>> >> Também vale a pena atualizar para o 6.4, mas não vejo como algo tão >> crítico/urgente. >> > > Concordo, porém nem tudo é tão simples :( > "nem tudo é tão simples"? Quanto a atualizar o SO, eu entendo, ok não é tão simples/rápido. Mas atualizar os binários do PostgreSQL é extremamente rápido. Dependendo da forma como instalou o ambiente não é nada mais que o tempo de um restart do 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
