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
-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
