Re: PROBLEMAS CON POSTGRES EN MAQUINAS MULTIPROCESADORES

Bueno les cuento que modificamos los siguientes parametros:

shared_buffers, work_mem y maintenance_work_mem

aplicando la formula de la pagina

http://www.juancarlosmoral.es/hardware_tunning.html

es decir :
------
Una buen comienzo es asignar entre un 2% y un 4% del total de la memoria
si prevemos pocos accesos simultáneos a grandes sesiones de ordenación y
mucho menor, si esperamos muchos accesos simultáneos a sesiones de
ordenación pequeñas. Como antes, lo mejor es ir probando distintos
valores y ver en qué pueden afectar a la paginación adversa (swap
pagein). El valor hay que expresarlo en KB.

En nuestro ejemplo, hemos optado por usar un 4% de la memoria:

El 4% de 1 GB: 41943 KB (1048576 KB*4)/100
work_mem = 41943
---
modificamos el work_men como si solo tubieramos 2gb de memoria (solo para hacer la prueba)
en realidad tenemos 8Gb

work_mem = 83886

se redujo razonablemente el tiempo de ejecución del proceso de 4h a
3h-30min (aunque no lo esperado inicialmente por el cambio de 2 a 4
procesadores)

en el momento nos encontramos realizando una prueba con los parametros
al limite posible para ver que sucede... (es decir el work_mem para 8Gb)

fue de gran ayuda que nos informaran sobre esta modificación ... pues
era tema desconocido para nosotros.

hemos realizado un seguimiento al funcionamiento de los 4 procesadores y
notamos que la carga esta recargada al procesador #1 y los demas no
tienen casi participación... CREEMOS QUE ESE ES EL PROBLEMA... aunque
los expertos de HP dicen que los procesadores estan configurados para
trabajar en forma conjunta.

Nuevamente MUCHAS GRACIAS POR LA COLABORACION RECIBIDA POR TODOS...
y espero que esta experiencia le sirva a otros que tengan el mismo
problema...

si tienen nuevos aportes agradeceriamos nos sean comentados...

El mié, 24-05-2006 a las 23:13 -0400, Mario Soto Cordones - Venezuela
escribió:
> Lo que dice alvato es muy correcto, yo pase por eso y ahora estoy con
> opteron de 64 bit y ya no hay problemas.
>
> Antes era mas rapido y funcionaba mejor 1 procesador xeon que 2 .
>
> Por eso me cambie, de procesadores, pero jamas de RDB.
>
>
> El 24/05/06, Alvaro Herrera<alvherre(at)commandprompt(dot)com> escribió:
> > Mario escribió:
> > > On 24/05/06, Jimmy Salazar <jsalazar(at)solati(dot)com(dot)co> wrote:
> > > >SI CLARO ESTAMOS HABLANDO DE UNA BASE DE DATOS DE MAS DE 10GB con
> > > >millones de registros...
> > > >
> > > >no creemos que sean los discos...
> > > >
> > > Humm, definitivamente hay un costo altisimo extra que se esta
> > > generando. Pero es muy extraño que suceda eso, como te decian no hay
> > > problema si en la maquina hay mas de una cpu.
> >
> > En realidad algunos Xeon multiprocesador si se ha reportado que pueden
> > tener problemas con Postgres, con algunas versiones. No estoy seguro si
> > se ha resuelto todo; pero "the bottom line" es que si quieres tener
> > servidores multiprocesador para Postgres, de alto rendimiento, mejor te
> > olvidas de los Xeon y compras Opteron.
> >
> > Para verificar si el problema realmente son los Xeon, verifica la
> > cantidad de context switch que ocurren (creo que puedes ver eso con
> > vmstat). Si la tasa de c.s. es muy alta, probablemente tengas el
> > problema en cuestion. Otro experimento es bootear un kernel Linux
> > uniprocesador; si anda mas rapido que con el kernel multiproc, tienes el
> > problema en cuestion.
> >
> > --
> > Alvaro Herrera http://www.CommandPrompt.com/
> > The PostgreSQL Company - Command Prompt, Inc.
> >
> > ---------------------------(fin del mensaje)---------------------------
> > TIP 4: No hagas 'kill -9' a postmaster
> >
>
>