Flavio Se fosse esse o caso (antes de usar o pgbounce o problema ja ocorria) eu receberia a mensagem de conexões excedidas. Não é o caso, meu banco tem limite de 50 conexões e nunca chega nem perto disso.
Giancarlo Rubio Em 10 de outubro de 2011 13:46, Flavio Henrique Araque Gurgel < [email protected]> escreveu: > > Estou usando pgbouncer para o pool (antes disso já tinha o mesmo > problema). > > Segue meu pg_stat > > SELECT * FROM pg_stat_activity ; > > datid | datname | procpid | usesysid | usename | > > current_query | waiting | xact_start | > > query_start | backend_start > > | client_addr | client_port > > > -------+------------+---------+----------+------------+----------------------------------+---------+-------------------------------+-------------------------------+--------------------------- > > ----+-----------------+------------- > > 16387 | dbname | 12666 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:30:52.681163-03 | 2011-10-10 > > 13:31:00.825821-03 | 2011-10-10 13:30:52.672718 > > -03 | 10.0.0.12 | 43578 > > 16387 | dbname | 12667 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:33:07.359933-03 | 2011-10-10 > > 13:35:35.106725-03 | 2011-10-10 13:31:11.733524 > > -03 | 10.0.0.12 | 43584 > > 16387 | dbname | 12668 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:32:41.81385-03 | 2011-10-10 > > 13:35:29.632156-03 | 2011-10-10 13:31:12.44895- > > 03 | 10.0.0.12 | 43588 > > 16387 | dbname | 12669 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:32:00.75138-03 | 2011-10-10 > > 13:35:30.78344-03 | 2011-10-10 13:31:13.922268 > > -03 | 10.0.0.12 | 43592 > > 16387 | dbname | 12670 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:33:55.870704-03 | 2011-10-10 > > 13:36:56.777206-03 | 2011-10-10 13:31:17.397598 > > -03 | 10.0.0.12 | 43597 > > 16387 | dbname | 12671 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:31:26.603761-03 | 2011-10-10 > > 13:35:31.670655-03 | 2011-10-10 13:31:26.59695- > > 03 | 10.0.0.12 | 43628 > > 16387 | dbname | 12672 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:35:29.01913-03 | 2011-10-10 > > 13:35:36.997236-03 | 2011-10-10 13:31:27.318486 > > -03 | 10.0.0.12 | 43633 > > 16387 | dbname | 12674 | 16384 | root | SELECT * FROM > > pg_stat_activity ; | f | 2011-10-10 13:37:04.830385-03 | 2011-10-10 > > 13:37:04.830385-03 | 2011-10-10 13:33:14.848317 > > -03 | | -1 > > 16387 | dbname | 12676 | 16386 | dbname | <IDLE> in transaction > > | f | 2011-10-10 13:36:43.234772-03 | 2011-10-10 > > 13:37:04.575148-03 | 2011-10-10 13:35:33.071268 > > -03 | 10.0.0.12 | 53953 > > (9 rows) > > Seu banco de dados não está fazendo *nada*. Está parado em transações > abertas por sua aplicação e esperando novos comandos. > Sua aplicação está travada porque deve ter aberto 200 mil conexões > (exagerando aqui) com o PgBouncer e, como o PgBouncer tem apenas umas > poucas conexões, estão todas em uso. > Sua aplicação certamente está fazendo transações aninhadas. Neste > cenário, qualquer pool de conexões vai lotar. Nenhum banco de dados do > mundo suporta isso. > Nada do que falei acima explica o consumo de 100% de CPU. Conexões > <IDLE> in transaction consomem um mínimo de CPU apenas para existirem. > Só que elas ficam nesse estado, travadas, até que a aplicação mande um > COMMIT ou ROLLBACK. > > Verifique sua aplicação. > > []s > Flavio Gurgel > _______________________________________________ > 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
