Quizas el problema se encuentra en mis parametros tcp_keepalives, estos
valores los cambiamos buscando solucionar el problema de los bloqueos, es
posible que generen este comportamiento.
tcp_keepalives_idle = 300
tcp_keepalives_interval = 30
tcp_keepalives_count = 4
Anexo Salida "iostat".
Se pueden apreciar bueno valores.
*Linux 2.6.18-164.6.1.el5PAE (localhost.localdomain) 28/12/10
avg-cpu: %user %nice %system %iowait %steal %idle
0,78 0,03 0,39 0,13 0,00 98,66
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 19,21 0,76 658,93 4090399 3531833720
sdb 19,27 0,76 658,93 4085823 3531833720
dm-0 82,40 1,46 658,93 7847806 3531833720
dm-1 0,00 0,00 0,00 1776 112
dm-2 82,40 1,46 658,93 7845766 3531833608
dm-3 82,40 1,46 658,93 7844402 3531832872
dm-4 0,00 0,00 0,00 1128 736*
2010/12/28 Javier Fritz Aliste <[email protected]>
>
> El comportamiento que se puede apreciar en el motor de datos cuando ocurren
> estos "bloqueos",p. ejemplo al ejecutar una consulta a la base de datos (en
> pgadmin) , la respuesta nunca es obtenida (5 min. sin respuesta), en
> situacion normal el mismo query solo toma unas milesimas. Cuando se detecta
> este problema la consulta a pg_locks arroja resultados similares a los
> enviados, tambien pueden apreciarse conexiones con "*<idle> in transaction
> *" , pero cuando la respuesta es rapida (sin bloqueo) la misma consulta no
> arroja resultados.
>
> continuo revisando valores en la maquina.
>
> Al momento de la muestra enviada se encontraban alrededor de 120 conexiones
> activas.
>
> slds, gracias.
>
> 2010/12/28 Javier Fritz Aliste <[email protected]>
>
> Hola.
>>
>>
>> Revisando la maquina se ve el siguiente resumen al sacar "top".
>>
>> Tasks: 243 total, 1 running, 242 sleeping, 0 stopped, 0 zombie
>> Cpu(s): 0.2%us, 0.2%sy, 0.0%ni, 99.4%id, 0.1%wa, 0.1%hi, 0.1%si,
>> 0.0%st
>> Mem: 8300676k total, *7961668k used*, 339008k free, 169756k
>> buffers
>> Swap: 5144568k total, 96k used, 5144472k free, 7234280k cached
>>
>> En cuanto a disco un df me muestra 6% de uso en el raid, que es donde se
>> encuentra la instalacion de los datos postgresql. La maquina tiene como
>> funcion principal el servicio de datos postgresql.
>> los otros servicio son de monitoreo y control.
>> *
>> *Donde mas puedo encontrar alguna pista para detectar el problema*
>>
>> Otros datos*
>> pg_ctl (PostgreSQL) 8.3.8
>>
>> *postgresql.conf (algunos parametros)*
>> max_connections = 200
>> ssl = on
>> tcp_keepalives_idle = 300
>> tcp_keepalives_interval = 30
>> tcp_keepalives_count = 4
>> shared_buffers = 512MB
>> temp_buffers = 8MB
>> max_prepared_transactions = 200
>> work_mem = 3MB
>> maintenance_work_mem = 32MB
>> max_fsm_pages = 204800
>> max_stack_depth = 2MB
>>
>>
>>
>> 2010/12/28 Alvaro Herrera <[email protected]>
>>
>> Excerpts from Javier Fritz Aliste's message of mar dic 28 14:45:06 -0300
>>> 2010:
>>> > Hola a todos.
>>> >
>>> > Hace algun tiempo hice una consulta sobre lock's que se generan en mmis
>>> > bases de datos, aun no he logrado determinar cual es el motivo de la
>>> > generacion de estos bloqueos, he notado que estos se produce
>>> principalmente
>>> > cuando el rendimiento de las comunicaciones baja, el problema es que
>>> genera
>>> > cuelgues de la aplicacion de todos quienes acceden a los datos, incluso
>>> en
>>> > aquellos que poseen conexiones adecuadas.
>>>
>>> Dado que no hay ningún lock con granted=false (que son los que
>>> bloquean), obviamente el problema no son los locks; ¿quizás el disco o
>>> la CPU están saturados?
>>>
>>> --
>>> Álvaro Herrera <[email protected]>
>>> The PostgreSQL Company - Command Prompt, Inc.
>>> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>>>
>>
>>
>>
>> --
>> Javier Fritz
>>
>>
>
>
> --
> Javier Fritz
>
>
--
Javier Fritz
