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@ |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Rodrigo Ruiz | 2011-12-26 20:51:05 | Re: Trigger no actúa al eliminar en tabla padre |
Previous Message | Lazaro Rubén García Martinez | 2011-12-26 20:33:05 | RE: Trigger no actúa al eliminar en tabla padre |