Re: PROBLEMA CON IDLE IN TRANSACTION

Gracias a todos, por lo menos, tengo la seguridad del lado por el cual esta
nuestro problema.. la verdad que es una dura batalla.. jaja.. Los select,
update, insert son generados por el hibernate, y segun lo q m dicen, tiene
configurado un autocommit, q es el encargado de cerrar la transaccion de
forma automatica ?? en fin, ..!!! , ademas de que las excepciones cuentan
con el rollback.. lo mejor seria repensar la aplicacion y q se vea una
herramienta menos tormentosa de desarrollo..

El 25 de abril de 2011 11:42, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:

> El día 25 de abril de 2011 08:52, Diego Ayala <netdiego81(at)gmail(dot)com>
> escribió:
> > Buenos dias a todos, tal vez, este sea un tema ya repetido, pero como ya
> no
> > se que pensar o que hacer recurro a ustedes, tenemos un sistema web de
> > subasta a la baja electronica, desarrollado en java, y base de datos
> > PostgreSQL 8.4.1 de 64 bits, con 12 GB de RAM y 2 cuad core de cpu. con
> un
> > disco de 300 GB. en 1+0.
> >
> > El tema es el siguiente, algunas subastas tienen entre 40 a 50 oferentes,
> > los cuales, a su vez cuentan con 4 a 5 maquinas que constantemente
> ejecutan
> > el proceso de lances y mensajes, el sistema ejecuta cada 10 seg. de forma
> > automatica algunos select, para refrescar la ventana, obviamente, se
> > generan locks, pero desde web server donde se encuentra la aplicacion de
> la
> > subasta casi todas las conexiones quedan en IDLE IN TRANSACTION, teniendo
> > una discusion con los desarrolladores, defendi la teoria de que el
> problema
> > es la aplicacion, pero ellos, obviamente, dicen q es la base la que no
> > responde por lo tanto eso hace que queden los IDLE IN TRANSACTION.
> > Esto hace q incluso todo el sistema aparte del de subasta se enlentezca
> > bastante.. que podria hacer, o q m recomiendan
> >
> > Actualmente las tablas del sistema de subasta estan en un esquema, tengo
> > solo 1 base de datos con varios esquemas, lo ideal seria separar, tener
> en
> > diferentes bases de datos
> > Implementar la replicacion para balancear algo la carga
> > Mejorar la configuracion del postgresql
> > Los desarrolladores utilizan hibernate, q no fue optimizado ya que no
> saben
> > como hacerlo..! podria ser ese el problema..?
> > Actualmente estamos trabajando para ver si podemos optimizar algunos
> querys.
> >
> > Yo realice la configuracion de mi postgresql basandome en lo que me
> genera
> > el pgtune, les paso la cofiguracion actual que tengo
> >
> > max_connections=300
> > shared_buffers =3GB
> > tem_buffers = 8MB
> > work_men = 10MB
> > maintenance_work_mem = 768MB
> > checkpoint_segments =16
> > checkpoint_completion_target= 0.9
> > random_page_cost=2.0
> > effective_cache_size=7GB
> > default_statistics_target=50
> > constraint_exclusion=on
> > from_collapse_limit=10
> > join_collapse_limit=10
> >
> >
> > gracias por el tiempo..
> >
> >
> >
>
> Como bien te dicen, el error está en el aplicativo, que no cierra
> correctamente las transacciones. Lo de "la base no responde" está
> totalmente fuera de toda lógica. Si no responde, no queda IDLE.
> En java, un error recurrente es olvidar los rollback en los "catch".
> Lo que podés hacer es verificar qué tablas están siendo lockeadas, ver
> en qué "cachos" de código se están actualizando y verificar esta
> situación.
>
> Saludos!
> Silvio
>