Re: Sobre uso de memoria RAM

Leonardo ... lo de:

work_men = 96MB

Fue error de transcripción o relamnete lo tienes así?

Atentamente,

RAUL DUQUE
Bogotá, Colombia

----- Original Message -----
From: "Leonardo Castillo" <leonardo(at)hacer(dot)ula(dot)ve>
To: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Friday, December 15, 2006 2:39 PM
Subject: [pgsql-es-ayuda] Sobre uso de memoria RAM

Saludos Amigos listeros..

En dias pasados comenté que necesitaba algunos tips para la entonación del
server postgres. Ahora bien esas recomendaciones del compañero Alvaro
Herrera efectivamente mejoraron en el ambiente de prueba, ahora en el
ambiente de producción los resultados siguen siendo pateticos. Les comento
mi configuración: Windows 2003 - Postgres 8.2, con 1Gb de RAM, 3 DD 33 GB
SCSI, 1 para el SO y 1 para el tablespace y 1 para documentos. La
aplicación que se conecta vía ODBC. Ahora bien luego de este largo cuento,
les comento lo del Subject del correo, la cuestión es que veo que la
aplicación no consumen RAM, consume CPU pero la RAM nada. Otro punto es que
llegan 10 Cgis ejecutandose con la misma operación, en teoría el primero
que comienza deberia terminar, pues no al contrario el primero que comienza
es de los últimos en terminar.

Sobre mi configuración, les comento las variables que toqué:

max_connections = 120
shared_buffers = 48MB //Postgres 8.2 acepta estas unidades
work_men = 96MB
maintenance_work_mem = 48MB
max_stack_depth = 1MB
max_fsm_pages = 204800
wal_buffers = 512kB
commit_delay = 1000
checkpoint_segments = 12
checkpoint_timeour = 30min
checkpoint_warning = 60s
efective_cache_size = 768MB
stats_start_collector = on
stats_row_level = on
autovacuum = on
autovacuum_naptime = 5min

Otros datos a tomar en cuenta: La bd cuenta con 126 Tablas, pero en
realidad las criticas son unas 12, las cuales poseen alrededor 500.000 a lo
sumo, se efectuan simultaneamente operaciones de edición (INSERT, UPDATE)
con operaciones de consulta.

He tratado de darle la vuelta y todo, se que Postgres puede darme más, y
espero eso, pues esa bd estaba antes en SQL Anywhere 9 y está dando
resultados simalares o peores.

Espero y agradezco la ayuda que me puedan prestar..

Atte.
Leonardo Castillo
Hacer Sistemas C.A.

Oficina: +58(274)2527198, 2528808
Movil: +58(416)4718010

---------------------------(fin del mensaje)---------------------------
TIP 9: el optimizador ignorará el uso de recorridos de índice si los
tipos de datos de las columnas no coinciden