Skip site navigation (1) Skip section navigation (2)

Re: Problemas con PostgreSQL 9.1.2

From: Eduardo Morras <nec556(at)retena(dot)com>
To: motum hesa <motums(at)gmail(dot)com>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Problemas con PostgreSQL 9.1.2
Date: 2011-12-26 20:41:05
Message-ID: 4EE6D4B40025CF20@ (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
At 20:47 26/12/2011, you wrote:
>Hola antes que nada gracias por tu respuesta en cunato a lo que preguntas:
>
> > Que s.o. usas en la 9.1.2? No digas que has pasado de un Unix a Windows por
> > favor.
> >
>
>Uso FreeBSD 8.2 64bits en todos los servidores  (en el anterior tenia
>8.1 pero no hay problema con eso por que un servidor de pruebas lo
>tengo con 8.2 y postgres 8.4 y funciona bien).

Vale, aqui si te puedo ayudar, mi principal 
plataforma de desarrollo es FreeBSD, como root haz:

#sysctl -a > /root/sysctl_defaults

Con esto haces una copia de los valores actuales 
de todos los sysctl de tu FreeBSD, por si tienes que deshacer un cambio.

#sysctl kern.ipc.shm_use_phys=1

Esto hace que la memoria compartida de procesos 
este siempre en memoria fisica y no pueda estar 
en el swap. Este tuning aparecio en la rama 8 y 
por defecto esta a 0, orientada a instalaciones genericas, no de servidor.

Ten en cuenta que cada vez mas, FreeBSD esta 
poniendo sus valores de tunning orientados a 
entornos de desktop, mas que a servidores.

> > Has tuneado el sistema aumentando el numero de semaforos, memoria
> > compartida, descriptores de ficheros, el sistema de archivos y demas?
> >
>
>Si he aumetado el numero de semafors, memoria compartida, descriptores
>de ficheros ( no lo habia hecho pero ya realizado sigue igual). En
>cuanto al sistema de archivos la unica modificacion fue en el fstab
>agregar noatime, no se que mas puedo modificar.

ok, prueba estos cambios orientados a 
instalaciones tipo servidor, no creo que mejoren 
el problema de rendimiento especifico que tienes, 
pero si el rendimiento general de Postgresql:

#sysctl vfs.read_max=64

Esto es el read ahead, si usas raid por hardware 
o software, prueba con 96 o 128 aunque valores 
mas altos daran mejoras cada vez mas pequeñas.

#sysctl vm.pmap.pg_ps_enabled=1

Permite el uso de superpages, no estoy muy seguro 
de si es necesario ponerlo a 1 en 8.2, pero por si acaso.

#sysctl kern.maxdsiz="1G"

Comprueba el valor antes de cambiarlo, no lo 
vayas a poner mas bajo de lo que estaba, 
comprobar el valor se hace asi, sin asignar un valor especifico:

#sysctl kern.maxdsiz

Hay algunos mas para la red, sistema de archivos, 
kernel, pero no creo que necesites tocar nada. Si 
fuese necesario, ya seria para otro hilo ;)

> > Supongo que postgres si lo has tuneado acorde con la nueva maquina.
> >
>
>Si, ya hice el tuning de postgres lo mejor posible por ahi movi mas
>datos para ayudarme a mi proceso ( como enable_seqscan=off,
>constraint_exclusion = on, bytea_output='escape' y statement_timeout=5
>min).. pero tambien los cambie en maquina de pruebas y no afecta,
>
> > Como hiciste el paso de los datos de 8.4 a 
> 9.1, con pg_dumpall o pg_upgrade?
> > Si usaste pg_upgrade, has tenido en cuenta que hay tipos de datos que no
> > puede manejar correctamente y has leido el log/registro?
>
>al principio use pg_upgrate, pero como comentas dio problemas con unos
>datos, despues lo hice un pg_dump pero use el del 8.4 y tambien dio un
>par de problemas.. y el que funciono bien fue hacer el respaldo de 8.4
>con el cliente de 9.1
>
> > Uno de los pasos
> > que puede fallar y lo anuncia solo con un 
> warning es el reindex, en especial
> > si hay involucrados tipos de datos que no puede manejar.
> >
>
>Hice el reindex pero ningun error aparecio.. todo normal

No no, me referia a que si haces el pg_upgrade, 
puede fallar el reindex automatico que hace y 
estar usando los indices antiguos o ninguno, con 
lo que la velocidad de la consulta fuese horrorosamente lenta.

> > Conforme usas los triggers en 9.1 mejoran los tiempos de ejecucion o son
> > practicamente iguales que al principio? Si 
> mejora es normal, si son iguales,
> > mira que se esten usando los indices de forma correcta, que los planes de
> > ejecucion no esten haciendo cosas raras.
> >
>
>La mayoria de los triggers mejoraron un poco, pero no se si fue 9.1 o
>el aumento de caracteristicas en el servidor, yo creo k los planes de
>ejecucion estan haciendo cosas raras principalmente en la consulta que
>te comente..  mi idea era depurar la funcion haciendo linea por
>linea.. pero no se si es posible..
>
> > Ya como ultima opcion, reindexa la bd y analiza.
> >
>
>Reindexada y analizada.. todo sigue igual :(

Pues ya como ultima opcion, como ejecutas los 
triggers? Creo que en la web de Alvaro Herrera o 
Jaime Casanova explicaban (no recuerdo quien) 
explicaban que dependiendo como se ejecute una 
funcion esta se ejecutaba mas o menos rapida. Es 
posible que para triggers exista un problema y solucion similar.

>Saludos y gracias por tus ideas...
>
>
>Roberto Campos



In response to

pgsql-es-ayuda by date

Next:From: Rodrigo RuizDate: 2011-12-26 20:51:05
Subject: Re: Trigger no actúa al eliminar en tabla padre
Previous:From: Lazaro Rubén García MartinezDate: 2011-12-26 20:33:05
Subject: RE: Trigger no actúa al eliminar en tabla padre

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group