Re: PROBLEMA CON IDLE IN TRANSACTION

hola doc, este problema es recurrente debido a que los desarrolladores
no estan probando sus desarrollos con concurrencia, sino en labs, en
labs todo funciona a las mil maravillas, los locks in transaction
ocurren tambien cuando hay un lock de una tabla que maneja secuencias,
como cada documento debe ser correlativo, y estos accesos se hacen en
paralelo, los locks se dan, por eso existe el select for update, otra
salida es repensar la aplicacion para que solo hay un punto de control
en la secuencia. y si no saben tunear hibernate que no se metan a
usar lo que no conozcan.

2011/4/25 Diego Ayala <netdiego81(at)gmail(dot)com>:
> 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..
>
>
>
>
>
>
>

--
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
      more or less, right?
<crab> i.e., "deadly poison"