Bom dia a todos,
Estou com uma aplicação em produção (java + jdbc + postgres 8.4)
A aplicação está constantemente ficando lenta e as vezes parando
totalmente, aparentemente parece ser devido a bloqueios nas tabelas.
Tentei configurar o postgres para usar o pgFouine mas não consegui, existe
alguma
Olá,
Em 1 de agosto de 2012 09:55, Alessandro Lima grandegoia...@gmail.comescreveu:
Bom dia a todos,
Estou com uma aplicação em produção (java + jdbc + postgres 8.4)
A aplicação está constantemente ficando lenta e as vezes parando
totalmente, aparentemente parece ser devido a bloqueios nas
O autovacuum está desabilitado OFF.
Atenciosamente,
Alessandro Lima
email grandegoia...@gmail.com
Em 1 de agosto de 2012 10:36, Flávio Alves Granato flavio.gran...@gmail.com
escreveu:
Em 01/08/2012 10:23, JotaComm escreveu:
Olá,
Em 1 de agosto de 2012 09:55, Alessandro Lima
Alessandro,
Nesse caso, verifique se não há nenhum processo com 'waiting = true' na view
pg_stat_activity.
Date: Wed, 1 Aug 2012 10:42:10 -0300
From: grandegoia...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] Como solucionar bloqueios
O autovacuum está
Dei uma olhada na view pg_locks mas surgiram várias dúvidas de como
analizar seu resultado:
- deveria apresentar uma coluna com a query que está bloqueada?
- deveria apresentar uma coluna com quanto tempo está bloqueado?
- o resultado desta consulta representa que está bloqueado aguardando o
Em 01-08-2012 10:42, Alessandro Lima escreveu:
O autovacuum está desabilitado OFF.
E provavelmente é a causa de sua lentidão.
Ligue-o e configure-o corretamente.
Flavio Henrique A. Gurgel
Consultor e Instrutor 4Linux
Tel: +55-11-2125-4747
www.4linux.com.br
Em 01-08-2012 10:55, Alessandro Lima escreveu:
Dei uma olhada na view pg_locks mas surgiram várias dúvidas de como
analizar seu resultado:
- deveria apresentar uma coluna com a query que está bloqueada?
- deveria apresentar uma coluna com quanto tempo está bloqueado?
- o resultado desta
Então as consultas bloqueadas estarão com waiting TRUE e a consulta que
originou o bloqueio e a lentidão estará com waiting FALSE mas com
query_start e backend_start altos,
seria isto?
Atenciosamente,
Alessandro Lima
email grandegoia...@gmail.com
Em 1 de agosto de 2012 11:02, Flavio Henrique
Isso. Para facilitar, na wiki tem uma página com umas querys prontas pra te
ajudar:http://wiki.postgresql.org/wiki/Lock_Monitoring
Sebastian Webberhttp://swebber.me
Date: Wed, 1 Aug 2012 11:10:13 -0300
From: grandegoia...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re:
Eu não posso ajuda-lo por que não consegui entender como estão
organizadas suas tabelas.
Tente explicar com mais detalhes ou, talvez, algum outro colega tenha
entendido e consiga ajuda-lo.
Osvaldo
-- Tabela documento:
CREATE TABLE documento
(
codemp integer,
codcto integer,
codcli
Danilo,
o que você precisa fazer?
Sebastian Webberhttp://swebber.me
Date: Wed, 1 Aug 2012 11:20:22 -0300
From: danilo.dsg.go...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] Ajuda com select
Eu não posso ajuda-lo por que não consegui entender como estão
Em 1 de agosto de 2012 11:15, Sebastian Webber sweb...@outlook.comescreveu:
Isso. Para facilitar, na wiki tem uma página com umas querys prontas pra
te ajudar:
http://wiki.postgresql.org/wiki/Lock_Monitoring
Tem também essa palestra do Bruce [1] [2] sobre o Lock Manager do
PostgreSQL.
[1]
Em 01/08/2012 10:42, Alessandro Lima escreveu:
O autovacuum está desabilitado OFF.
Como o meu xará disse, é uma boa prática trabalhar com o autovacuum.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
Em 01-08-2012 11:10, Alessandro Lima escreveu:
Então as consultas bloqueadas estarão com waiting TRUE e a consulta que
originou o bloqueio e a lentidão estará com waiting FALSE mas com
query_start e backend_start altos,
seria isto?
É uma das coisas que você pode ver, e o pessoal ja te deu
Em 01/08/12, Danilo Silvadanilo.dsg.go...@gmail.com escreveu:
Eu não posso ajuda-lo por que não consegui entender como estão
organizadas suas tabelas.
Tente explicar com mais detalhes ou, talvez, algum outro colega tenha
entendido e consiga ajuda-lo.
Osvaldo
-- Tabela documento:
CREATE
Prezados,
Há em algum lugar no PostgreSQL 8.2 onde posso verificar o quando uma base
de dados foi acessada pela ultima vez? E o ultimo acesso de
um usuário, também tem como saber?
Fico no aguardo.
--
Atenciosamente,
*Claudio Souto*
(61) 9831-9381
___
Talvez no log, se estiver configurado para tal.
Sebastian Webberhttp://swebber.me
Date: Wed, 1 Aug 2012 14:10:32 -0300
From: clau.s...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: [pgbr-geral] Ultimo acesso Base de dados
Prezados,
Há em algum lugar no PostgreSQL 8.2 onde posso
Quais os campos relacionam estas tabelas?
Nenhum, são tabelas distintas.
São todos aqueles que tem o mesmo nome ou apenas alguns deles? Em
suma: quais as chaves primárias e estrangeiras?
De onde você obtém o nome do usuário?
Por qt (por ex. em qtentrada) você quer dizer a quantidade de
Pesquisei sobre o VACUUM, e pelo que vi é recomendado utilizar o VACUUM
ANALYZE e não o VACUUM FULL ANALYZE, correto?
Posso deixar os parametros do vacuum_cost e autovacuum_ comentados
(default) ou devo otimizar? (por padrão ele roda o autovacuum de quanto em
quanto tempo?)
obs: servidor xeon 32gb
Em 01/08/2012 14:52, Alessandro Lima escreveu:
Pesquisei sobre o VACUUM, e pelo que vi é recomendado utilizar o
VACUUM ANALYZE e não o VACUUM FULL ANALYZE, correto?
Posso deixar os parametros do vacuum_cost e autovacuum_ comentados
(default) ou devo otimizar? (por padrão ele roda o
2012/8/1 Danilo Silva danilo.dsg.go...@gmail.com:
São todos aqueles que tem o mesmo nome ou apenas alguns deles? Em
suma: quais as chaves primárias e estrangeiras?
Ou tu dás as estruturas completas, como pedido, ou fica difícil ajudar.
___
pgbr-geral
Encontrei um momento em que a aplicação trava, ao executar um ALTER TABLE
XXX ADD COLUM XXX BOOLEAN;
Já parei a aplicação, reiniciei o postgres e o comando acima não finaliza a
execução.
Alguma dica?
Atenciosamente,
Alessandro Lima
email grandegoia...@gmail.com
Em 1 de agosto de 2012 14:59,
Em 01/08/2012 16:03, Alessandro Lima escreveu:
Encontrei um momento em que a aplicação trava, ao executar um ALTER
TABLE XXX ADD COLUM XXX BOOLEAN;
Já parei a aplicação, reiniciei o postgres e o comando acima não
finaliza a execução.
Alguma dica?
Dica: Perguntar ao programador que fez esta
Date: Wed, 1 Aug 2012 16:08:23 -0300
From: flavio.gran...@gmail.com
To: pgbr-geral@listas.postgresql.org.br
Subject: Re: [pgbr-geral] Como solucionar bloqueios
Em 01/08/2012 16:03, Alessandro Lima escreveu:
Encontrei um momento em que a aplicação trava, ao executar um ALTER
TABLE XXX
On 01-08-2012 14:52, Alessandro Lima wrote:
Pesquisei sobre o VACUUM, e pelo que vi é recomendado utilizar o VACUUM
ANALYZE e não o VACUUM FULL ANALYZE, correto?
Depende do objetivo.
VACUUM permite que espaço não utilizado seja reaproveitado por novas tuplas.
VACUUM FULL remove espaço não
On 01-08-2012 14:59, Flávio Alves Granato wrote:
Em 01/08/2012 14:52, Alessandro Lima escreveu:
Pesquisei sobre o VACUUM, e pelo que vi é recomendado utilizar o
VACUUM ANALYZE e não o VACUUM FULL ANALYZE, correto?
Posso deixar os parametros do vacuum_cost e autovacuum_ comentados
(default)
26 matches
Mail list logo
