muchas gracias x tu ayuda, esa es la discusión que tengo con los
desarrolladores ya que ellos creen que la solucion debe estar de parte de
PostgreSQL, se utiliza Hibernate, JBoss y el Framework SEAM, con
programación JAVA.

2010/2/8 "Ing. Marcos Orti­z Valmaseda" <[email protected]>

> Diego Ayala wrote:
>
>> Buenos dias listeros, quisiera saber si podrian ayudarme, ya que estoy con
>> este problema desde mas de 2 semanas, ya busque algunos topicos referentes a
>> esto, pero no he podido solucionarlo, hablando con los desarrolladores, me
>> dicen que las tablas que quedan afectados son de solo lectura, que no se
>> ejecuta ninguna transaccion, en mi postgresql.conf  tengo configurados los
>> parametros
>> tcp_keepalives_idle = 900               # TCP_KEEPIDLE, in seconds;
>>                                        # 0 selects the system default
>> tcp_keepalives_interval = 90            # TCP_KEEPINTVL, in seconds;
>>                                        # 0 selects the system default
>> tcp_keepalives_count = 5, pero al parecer esto no surje efecto ya que
>> algunas transacciones estan x horas y lo mato utilizando el pgadmin, la
>> version de postgresql que tengo es la 8.4.1 sobre CenOS 5.3 de 64 bits.
>>
>> Hay alguna manera de matar o cerrar una transaccion que tiene estado IDLE
>> IN  TRANSACTION hay alguna forma de poner límite por usuario o un timeout
>> para las transacciones bloqueadas y que sólas vayan muriendo si quedaron así
>> zombies, como podria hacer esto, gracias de antemano x la ayuda..!!!
>>
>> --
>> Diego Ayala
>>
> Diego, según me estaba explicando una vez, en la vista pg_locks del
> information_schema, tu puedes averiguar cuáles son las transacciones que
> están IDLE con la consulta:
> SELECT locktype, database, relation, virtualxid, pid, mode, granted FROM
> pg_locks;
>
> locktype  | database | relation | virtualxid |  pid  |      mode       |
> granted
>
> ------------+----------+----------+------------+-------+-----------------+---------
> relation   |    11564 |    10969 |            | 12633 | AccessShareLock | t
> virtualxid |          |          | 5/11974    | 12633 | ExclusiveLock   | t
> (2 rows)
>
>
> Luego con : SELECT * from pg_stat_activity:
>
> datid |   datname   | procpid | usesysid | usename  |
>  current_query          | waiting |          xact_start         |
>  query_start          |         backend_start         | client_addr  |
> client_port
>
> -------+-------------+---------+----------+----------+---------------------------------+---------+---------------------------
>
> ----+-------------------------------+-------------------------------+--------------+-------------
> 16420 | uci_db      |   11760 |    16386 | dba      | <IDLE>
>            | f       |                             | 2010-02-08
> 09:10:05.683647-05 | 2010-02-08 08:52:24.164219-05 | 10.36.18.56  |
>  1399
> 16420 | uci_db      |   11909 |    16386 | dba      | <IDLE>
>            | f       |                             | 2010-02-08
> 08:59:21.524631-05 | 2010-02-08 08:59:21.408665-05 | 10.36.18.56  |
>  3088
> 16421 | uci_test_db |   12328 |    16386 | dba      | <IDLE>
>            | f       |                             |
>       | 2010-02-08 09:18:58.732188-05 | 10.36.18.107 |        1172
> 11564 | postgres    |   12633 |       10 | postgres | select * from
> pg_stat_activity; | f       | 2010-02-08 09:33:32.137225
> -05 | 2010-02-08 09:33:32.137225-05 | 2010-02-08 09:31:53.54647-05  |
>        |          -1
> (4 rows)
>
> Puedes ver en el campo current_query, que los procesos 11760, 11909 y 12328
> que están IDLE.
>
> Lo que se recomienda en este caso es:
> 1- Cerrar las transacciones lo más rápido posible.
> 2- Arreglar la aplicación en caso de que deje abiertas las
> transacciones(Michas veces es causa de los desarrolladores, por eso el
> PostgreSQL DBA debe estar presente en el desarrollo para guiarlos en el
> proceso)
>
> Otra observación:
> En caso de que usen algún ORM para el desarrollo, hay muchos que no hacen
> un uso eficiente de las transacciones en PostgreSQL, y muchas veces bloquean
> la tabla o el registro; y entonces lo que toca es corregir el ORM o no
> usarlo.
>
> Saludos, espero que te ayuden mis comentarios en algo.
>
> --
>
> --------------------------------------------------------------------------------
> "Para ser realmente grande, hay que estar con la gente, no por encima de
> ella."
>
>  Montesquieu
> Ing. Marcos Luís Ortíz Valmaseda
> PostgreSQL System DBA && DWH -- BI Apprentice
>
> Centro de Tecnologías de Almacenamiento y Análisis de Datos (CENTALAD)
> Universidad de las Ciencias Informáticas
>
> Linux User # 418229
>
> -- PostgreSQL --
> "TIP 4: No hagas 'kill -9' a postmaster"
> http://www.postgresql-es.org
> http://www.postgresql.org
> http://www.planetpostgresql.org
>
> -- DWH + BI --
> The Data WareHousing Institute
> http://www.tdwi.org
> http://www.tdwi.org/cbip
>
> ---------------------------------------------------------------------------------
>
>


-- 
Diego Ayala

Responder a