Re: VACUUM y CLUSTER

> Manuel Lamas escribió:
>
>>> Depende. En 8.1 y anteriores si hay diferencia, en 8.2 y superiores no
>>> hay diferencia.
>>
>> Estoy con 8.1.4.
>>
>> En ese caso, es peor en el resultado final si hago VACUUM tabla por tabla ?
>
> La diferencia que se hace es que no hay incremento en
> pg_database.datfrozenxid, y por lo tanto el sistema creerá que hay
> problemas de desborde del contador de transacciones.

Dicho asi, el problema parece serio.

Te explico lo que me pasa a ver si mi idea tiene sentido :

Tengo una base de mas o menos 4 G con mucho trafico.

El CLUSTER seguido de un VACUUM toma en total 90 minutos. En general, el proceso bloquea casi todo movimiento en el programa para los usuarios. Mi idea es de dividir el proceso entre las tablas que no paralizan a los usuarios (dejando los usuarios trabajar en el sistema) y las tablas lentas de procesar (desconectando a todos los usuarios durante ese tiempo).

De esa forma, en vez de impedir de trabajar a los usuarios durante 90 minutos, tal vez podría hacerlo durante solo 30 minutos (a verificar).

Ahora, el hecho que Postgresql crea que hay problemas de desborde del contador de transacciones a causa que pg_database.datfrozenxid no se incrementa, puede tener alguna consecuencia grave... o que consecuencia ?

Muchas gracias.
Manuel

_________________________________________________________________
Changez chaque jour en 1000$. Détails sur connectezetgagnez.ca
http://g.msn.ca/ca55/219

Manuel Lamas escribió:

> > La diferencia que se hace es que no hay incremento en
> > pg_database.datfrozenxid, y por lo tanto el sistema creerá que hay
> > problemas de desborde del contador de transacciones.
>
> Dicho asi, el problema parece serio.

Lo es.

> Te explico lo que me pasa a ver si mi idea tiene sentido :
>
> Tengo una base de mas o menos 4 G con mucho trafico.
>
> El CLUSTER seguido de un VACUUM toma en total 90 minutos. En general,
> el proceso bloquea casi todo movimiento en el programa para los
> usuarios. Mi idea es de dividir el proceso entre las tablas que no
> paralizan a los usuarios (dejando los usuarios trabajar en el sistema)
> y las tablas lentas de procesar (desconectando a todos los usuarios
> durante ese tiempo).

Pero, ¿para qué haces CLUSTER? ¿Es realmente necesario?

Los procesos de mantencion periodica no tienen por que bloquear a los
usuarios del sistema. Si lo hacen, hay algo que estas mal.

Una advertencia: las versiones anteriores a 8.1.6 tienen un bug en
autovacuum con muy malas consecuencias -- aun si tienes autovacuum
desactivado. Te aconsejo actualizar a 8.1.11 (o cual sea la version mas
reciente de 8.1, ya no recuerdo).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

> > Dicho asi, el problema parece serio.> > Lo es.
OK, lo tomo en cuenta.
> Pero, ¿para qué haces CLUSTER? ¿Es realmente necesario?

Hay varias tablas grandes con muchisimos UPDATE's en el día. Por haber hecho muchos test, te puedo explicar que con solo un VACUUM ANALYSE no alcanza... el sistema sigue lento. Lo que mejor resultado me dio es de hacer un CLUSTER seguido de un VACUUM..después queda impecable por 24 horas.
> Los procesos de mantención periodica no tienen por que bloquear a los> usuarios del sistema. Si lo hacen, hay algo que estas mal.
En teoría el sistema sigue funcionando. Lo que pasa es que en el proceso CLUSTER + VACUUM el sistema se enlentece mucho. En ese caso prefiero impedir a los usuarios de conectarse con una advertencia de mantenimiento que de dejarlos frente a un sistema lento (y que interpreten razones incorrectas).
> Una advertencia: las versiones anteriores a 8.1.6 tienen un bug en> autovacuum con muy malas consecuencias -- aun si tienes autovacuum> desactivado. Te aconsejo actualizar a 8.1.11 (o cual sea la version mas> reciente de 8.1, ya no recuerdo).
Estoy con 8.1.4 y tengo activado el autovacuum desde hace mas o menos un año. Por ahora no vi nada raro. En que consisten las malas consecuencias ?

Gracias por tu interés
Manuel
_________________________________________________________________
Trouvez rapidement des réponses à vos questions avec Windows Live Search. Essayez-le maintenant
http://g.msn.ca/ca55/224

Manuel Lamas escribió:

> > > Dicho asi, el problema parece serio.> > Lo es.
> OK, lo tomo en cuenta.
> > Pero, ¿para qué haces CLUSTER? ¿Es realmente necesario?
>
> Hay varias tablas grandes con muchisimos UPDATE's en el día. Por haber
> hecho muchos test, te puedo explicar que con solo un VACUUM ANALYSE no
> alcanza... el sistema sigue lento. Lo que mejor resultado me dio es de
> hacer un CLUSTER seguido de un VACUUM..después queda impecable por 24
> horas.

Entonces lo que necesitas es hacer VACUUM mas a menudo en las tablas
donde se ejecutan esos update. Quizas cada una hora, o algo asi.

> > Los procesos de mantención periodica no tienen por que bloquear a
> > los usuarios del sistema. Si lo hacen, hay algo que estas mal.

> En teoría el sistema sigue funcionando. Lo que pasa es que en el
> proceso CLUSTER + VACUUM el sistema se enlentece mucho. En ese caso
> prefiero impedir a los usuarios de conectarse con una advertencia de
> mantenimiento que de dejarlos frente a un sistema lento (y que
> interpreten razones incorrectas).

Entonces usa vacuum_cost_delay, que hace que vacuum duerma un rato cada
cierto tiempo para afectar menos al resto del sistema.

CLUSTER toma un lock exclusivo en la tabla que procesa, asi que no es
que se enlentezca sino que se detiene totalmente (para esa tabla).

> > Una advertencia: las versiones anteriores a 8.1.6 tienen un bug en>
> > autovacuum con muy malas consecuencias -- aun si tienes autovacuum>
> > desactivado. Te aconsejo actualizar a 8.1.11 (o cual sea la version
> > mas reciente de 8.1, ya no recuerdo).

> Estoy con 8.1.4 y tengo activado el autovacuum desde hace mas o menos
> un año. Por ahora no vi nada raro. En que consisten las malas
> consecuencias ?

Que procesa template0 sin la opcion FREEZE, lo cual hace que queden
tuplas mas marcadas. En el momento mismo no lo notaras, pero cuando
llegue el tiempo de hacerle un segundo vacuum te arrojara un error
porque no puede encontrar un archivo en pg_clog.

Si no quieres hacer el upgrade es cosa tuya, por supuesto, pero no te
quejes cuando falle :-D

Hay otros bugs en 8.1.4 tambien.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

> Subject: Re: [pgsql-es-ayuda] VACUUM y CLUSTER
>
> Manuel Lamas escribió:
>
>>>> Dicho asi, el problema parece serio.>> Lo es.
>> OK, lo tomo en cuenta.
>>> Pero, ¿para qué haces CLUSTER? ¿Es realmente necesario?
>>
>> Hay varias tablas grandes con muchisimos UPDATE's en el día. Por haber
>> hecho muchos test, te puedo explicar que con solo un VACUUM ANALYSE no
>> alcanza... el sistema sigue lento. Lo que mejor resultado me dio es de
>> hacer un CLUSTER seguido de un VACUUM..después queda impecable por 24
>> horas.
>
> Entonces lo que necesitas es hacer VACUUM mas a menudo en las tablas
> donde se ejecutan esos update. Quizas cada una hora, o algo asi.
>
>>> Los procesos de mantención periodica no tienen por que bloquear a
>>> los usuarios del sistema. Si lo hacen, hay algo que estas mal.
>
>> En teoría el sistema sigue funcionando. Lo que pasa es que en el
>> proceso CLUSTER + VACUUM el sistema se enlentece mucho. En ese caso
>> prefiero impedir a los usuarios de conectarse con una advertencia de
>> mantenimiento que de dejarlos frente a un sistema lento (y que
>> interpreten razones incorrectas).
>
> Entonces usa vacuum_cost_delay, que hace que vacuum duerma un rato cada
> cierto tiempo para afectar menos al resto del sistema.
>
> CLUSTER toma un lock exclusivo en la tabla que procesa, asi que no es
> que se enlentezca sino que se detiene totalmente (para esa tabla).
>
>
>>> Una advertencia: las versiones anteriores a 8.1.6 tienen un bug en>
>>> autovacuum con muy malas consecuencias -- aun si tienes autovacuum>
>>> desactivado. Te aconsejo actualizar a 8.1.11 (o cual sea la version
>>> mas reciente de 8.1, ya no recuerdo).
>
>> Estoy con 8.1.4 y tengo activado el autovacuum desde hace mas o menos
>> un año. Por ahora no vi nada raro. En que consisten las malas
>> consecuencias ?
>
> Que procesa template0 sin la opcion FREEZE, lo cual hace que queden
> tuplas mas marcadas. En el momento mismo no lo notaras, pero cuando
> llegue el tiempo de hacerle un segundo vacuum te arrojara un error
> porque no puede encontrar un archivo en pg_clog.
>
> Si no quieres hacer el upgrade es cosa tuya, por supuesto, pero no te
> quejes cuando falle :-D
>
> Hay otros bugs en 8.1.4 tambien.

Gracias Alvaro, tus consejos me parecen muy bien. Haré un test cambiando el vacuum_cost_delay y haciendo un VACUUM en las tablas pesadas todas la horas a ver como se porta el sistema.

Por el upgrade a una versión mas reciente, tambien me parece muy necesario según tus explicaciones. Voy a leer todo lo que encuentre sobre el tema antes de hacerlo porque la verdad es que tengo miedo de hacer un error y dejar el sistema inutilizable durante un buen tiempo.

Estoy con OpenBSD y compilo Postresql a partir del código source. Hasta ahora, cada vez que cambié de versión de Postgres, hice una instalación completa del sistema (OS,database,API,etc). No se muy bien como hacer (y si es complicado y arriesgado) un upgrade a partir del código source.

Muchisimas gracias por tu inmensa ayuda generosa.
Manuel

_________________________________________________________________
Trouvez vos infos rapidement et précisément avec Windows Live Instant Search ! Essayez-le maintenant!
http://g.msn.ca/ca55/220

Manuel Lamas escribió:

> Gracias Alvaro, tus consejos me parecen muy bien. Haré un test
> cambiando el vacuum_cost_delay y haciendo un VACUUM en las tablas
> pesadas todas la horas a ver como se porta el sistema.

Otro consejo: usa VACUUM VERBOSE por un tiempo, almacena la salida, y
analiza cómo se comporta (i.e. cuantas tuplas va limpiando cada vez).
Así puedes ajustar la frecuencia.

Otra cosa a tener en cuenta es que con vacuum_cost_delay harás que
VACUUM se demore un poco más.

> Por el upgrade a una versión mas reciente, tambien me parece muy
> necesario según tus explicaciones. Voy a leer todo lo que encuentre
> sobre el tema antes de hacerlo porque la verdad es que tengo miedo de
> hacer un error y dejar el sistema inutilizable durante un buen tiempo.

Bueno, puedes hacer una instalación de prueba en otra parte antes del
"oficial".

> Estoy con OpenBSD y compilo Postresql a partir del código source.
> Hasta ahora, cada vez que cambié de versión de Postgres, hice una
> instalación completa del sistema (OS,database,API,etc). No se muy bien
> como hacer (y si es complicado y arriesgado) un upgrade a partir del
> código source.

./configure --prefix=/alguna/parte/

Creo que el mayor riesgo es que alguna biblioteca cambie el "soname".
Lo que yo haría sería compilar ambos, 8.1.4 y 8.1.11 y hacer el "make
install" en el 8.1.11. Si algo falla, puedes volver a 8.1.4 facilmente
dandole "make install".

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

> Date: Thu, 24 Apr 2008 11:56:19 -0400
> From: alvherre(at)commandprompt(dot)com
> To: manuel3w(at)hotmail(dot)com
> CC: pgsql-es-ayuda(at)postgresql(dot)org
> Subject: Re: [pgsql-es-ayuda] VACUUM y CLUSTER
>
> Manuel Lamas escribió:
>
>> Gracias Alvaro, tus consejos me parecen muy bien. Haré un test
>> cambiando el vacuum_cost_delay y haciendo un VACUUM en las tablas
>> pesadas todas la horas a ver como se porta el sistema.
>
> Otro consejo: usa VACUUM VERBOSE por un tiempo, almacena la salida, y
> analiza cómo se comporta (i.e. cuantas tuplas va limpiando cada vez).
> Así puedes ajustar la frecuencia.
>
> Otra cosa a tener en cuenta es que con vacuum_cost_delay harás que
> VACUUM se demore un poco más.
>
>
>> Por el upgrade a una versión mas reciente, tambien me parece muy
>> necesario según tus explicaciones. Voy a leer todo lo que encuentre
>> sobre el tema antes de hacerlo porque la verdad es que tengo miedo de
>> hacer un error y dejar el sistema inutilizable durante un buen tiempo.
>
> Bueno, puedes hacer una instalación de prueba en otra parte antes del
> "oficial".
>
>> Estoy con OpenBSD y compilo Postresql a partir del código source.
>> Hasta ahora, cada vez que cambié de versión de Postgres, hice una
>> instalación completa del sistema (OS,database,API,etc). No se muy bien
>> como hacer (y si es complicado y arriesgado) un upgrade a partir del
>> código source.
>
> ./configure --prefix=/alguna/parte/
>
> Creo que el mayor riesgo es que alguna biblioteca cambie el "soname".
> Lo que yo haría sería compilar ambos, 8.1.4 y 8.1.11 y hacer el "make
> install" en el 8.1.11. Si algo falla, puedes volver a 8.1.4 facilmente
> dandole "make install".

Si, es lo que tenia pensado... Voy a hacer una replica exacta de lo que tengo en el servidor y haré una prueba antes de tirarme al agua.

Muchisimas gracias de nuevo.
Manuel
_________________________________________________________________
Trouvez rapidement des réponses à vos questions avec Windows Live Search. Essayez-le maintenant
http://g.msn.ca/ca55/224

>
> Porque si vas aprobar no usa un versión más actual.

Si, es lo que tengo pensado.. a menos que haya algo de contraindicado en la ultima versión.

_________________________________________________________________
Trouvez vos infos rapidement et précisément avec Windows Live Instant Search ! Essayez-le maintenant!
http://g.msn.ca/ca55/220