Re: procesos ocupan el total de la RAM

gracias Marco, paso a responderte...

2011/6/30 Marcos Ortiz <mlortiz(at)uci(dot)cu>

> **
> 1- Debes revisar tu aplicación si está cerrando correctamente las
> transacciones, porque veo
> que tienes muchos procesos IDLE y ese problema muchas veces está derivado
> de la aplicación.
> Específicamente en la base de datos siganew.
>
> 2- Haz algo como esto:
> SELECT
> procpid,
> waiting,
> current_timestamp - least(query_start,xact_start) AS runtime,
> substr(current_query,1,100) AS current_query
> FROM
> pg_stat_activity
> WHERE NOT procpid=pg_backend_pid();
> para ver el tiempo de ejecución y estado de los procesos
>
aquí el resultado de la consulta

procpid waiting runtime current_query
20191 False 00:00:00.480706 SELECT count(depe_id) FROM estadisticas WHERE
esta_identificador='PORTALES' and depe_id=4
20192 False 00:00:00.386197 <IDLE>
20193 False 00:00:00.923059 <IDLE>
20356 False 00:00:00.025542 "SELECT a.*, b.pers_apellpaterno||'
'||b.pers_apellmaterno||' '||b.p"
20195 False 00:00:00.386546 <IDLE>
*20355 False 00:21:16.105578 <IDLE>*
20337 False 00:00:00.016017 <IDLE>
20198 False 00:00:00.938753 <IDLE>
20199 False 00:00:00.372024 <IDLE>
20200 False 00:00:00.25493 <IDLE>
20201 False 00:00:00.737709 <IDLE>
20202 False 00:00:00.25672 <IDLE>
20203 False 00:00:00.073319 <IDLE>
20330 False 00:00:36.45948 <IDLE>
20205 False 00:00:01.528662 <IDLE>
20206 False 00:00:02.344311 <IDLE>
20207 False 00:00:00.494526 <IDLE>
20208 False 00:00:00.605292 <IDLE>
20209 False 00:00:01.271361 <IDLE>
20350 False 00:00:00.664512 <IDLE>
20211 False 00:00:00.089469 <IDLE>
20212 False 00:00:00.415914 <IDLE>
20213 False 00:00:01.415578 <IDLE>
20214 False 00:00:01.415396 <IDLE>
20215 False 00:00:00.089136 <IDLE>
20216 False 00:00:03.255382 <IDLE>
20217 False 00:00:00.414608 <IDLE>
20218 False 00:00:00.712893 <IDLE>
20394 False 00:15:16.820199 <IDLE>
20220 False 00:00:00.012025 <IDLE>
20221 False 00:00:00.566778 <IDLE>
20224 False 00:00:01.488197 <IDLE>
*20248 False 00:15:02.336603 <IDLE>*
*20259 False 00:29:55.395372 <IDLE>*
2*0260 False 00:29:55.322777 <IDLE>*
*20261 False 00:29:49.844099 <IDLE>*
*20263 False 00:29:35.91811 <IDLE>*
*20264 False 00:29:29.938763 <IDLE>*
20265 False 00:15:13.597104 <IDLE>
20266 False 00:29:34.070183 <IDLE>
20267 False 00:14:39.723603 <IDLE>
20269 False 00:15:11.412347 <IDLE>
*20270 False 00:29:32.580263 <IDLE>*
*20277 False 00:29:26.742965 <IDLE>*
20317 False 00:00:06.020122 <IDLE>
*20395 False 00:15:13.600668 <IDLE>*
*20402 False 00:13:33.794011 <IDLE>*
20520 False 00:00:24.907521 <IDLE>
20521 False 00:00:36.55953 <IDLE>
20522 False 00:00:36.157622 <IDLE>
20529 False 00:00:16.409113 <IDLE>
20530 False 00:00:02.556944 <IDLE>

esos procesos que no tienen query y que demandan mucho tiempo (los
resaltados), crees que sea porque en mi aplicación haya conexiones no
cerradas???, te comento que utilizo también pgpool.

>
3- Si pudieras adjuntar un historial aunque sea de 1 min de vmstat y iostat
> también podríamos
> ayudarte un poco más.
> # vmstat -n 1 10
>

te adjunto el resultado

>
# iostat -k -p 1 2
>
> # ps auxww | grep "postgres: " | sort -k 9
>
> Si el resultado de ps, te da como resultado varios IDLE IN TRANSACTION,
> debes mirar
> el código de tu aplicación
>

he notado que hay varios IDLE (pero no IDLE IN TRANSACTION, es lo mismo???)
te comento que tengo varios usuarios que se conectan simultaneamente.

> Saludos
>
>
>
>
> On 06/30/2011 09:19 AM, felix gonzales wrote:
>
> Jaime esto muestra el free
>
> total used free shared buffers cached
> Mem: 43132744 42929092 203652 0 13204 11795108
> -/+ buffers/cache: 31120780 12011964
> Swap: 16771852 5305632 11466220
>
> te adjunto lo que muestra el pg_stat_activity
>
>
>
> 2011/6/30 Jaime Casanova <jaime(at)2ndquadrant(dot)com>
>
>> felix gonzales <jfgonzales(at)gmail(dot)com> writes:
>>
>> >
>> > te adjunto mi archivo postgres.conf (si no pasa tendré que pegarlo)
>> >
>>
>> algunas configuraciones que no me parece que esten bien:
>>
>> - shared_buffers = 2048MB
>> supongo que 43Gb de RAM tranquilamente podrias darle al menos 8Gb a
>> shared buffers
>>
>> - temp_buffers = 128MB
>> cual es la razon de poner este valor tan alto?
>>
>> - work_mem = 64MB
>> esto es peligroso y quiza sea la causa de lo que estas viendo
>>
>> tienes max_connections en 512 y c/u de esas conexiones puede
>> utilizar hasta work_mem memoria para ordenamientos o tablas hash... si
>> estas procesando algo para lo que requiere una o varias de esas
>> operaciones tranquilamente te puedes quedar sin memoria...
>>
>> por ejemplo imagina que en algun momento las 512 conexiones estan
>> activas y cada una ordenando una gran cantidad de datos... para eso
>> requeririas (512*64MB=32768MB) 32Gb
>>
>> bajalo a 32 o 16 Mb o baja max_connections
>>
>> - max_stack_depth = 7MB
>> en serio necesitan tener esto en 7MB, en realidad no se si les pueda
>> causar un problema pero generalmente me parece que subir esto es mas
>> parte de esconder un problema...
>>
>> - effective_cache_size = 4096MB
>> esto lo podrias tener mas alto... 15 o 20 Gb? asi la base sabe que el SO
>> tiene suficiente memoria para su cache y otras cosas...
>>
>> que dice el comando free a todo esto? podrias mostrar la salida de free
>> antes de hacer algun cambio?
>>
>> >
>> > aunque ademas me gustaria ver que dice pg_stat_activity sobre
>> > lo que esta pasando en la base
>> >
>> > te refieres a que ejecute "select * from pg_stat_activity" y que
>> te envié el resultado ???
>> >
>>
>> exactamente
>>
>> --
>> Jaime Casanova www.2ndQuadrant.com
>> Professional PostgreSQL
>> Soporte 24x7, desarrollo, capacitación y servicios
>>
>
>
>
> --
> Ing. Felix Gonzales
> (c) 979720762
>
>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
> Para cambiar tu suscripción:http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
> --
> Marcos Luís Ortíz Valmaseda
> Software Engineer (UCI)
> http://marcosluis2186.posterous.com
> http://twitter.com/marcosluis2186
>
>

--
Ing. Felix Gonzales
(c) 979720762