Re: sobre vacuum

deepthroat escribió:
> On 1/4/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:

> >> Se me plantean estas preguntas porque no es facil lidiar con un
> >> proceso vacuum que tarde mas de 48 horas cuando la BD es gigantesca.
> >
> >48 horas? Creo que tienes un problema de configuracion o algo, no puede
> >demorarse 48 horas. Cuanto pesa tu BD?
> >
> 130gb.
> existe una tabla bastante grande con varios índices con muchos GB de
> tamaño y procesos que hacen delete y update masivamente en ella.

Ok. Me imagino que el vacuum de esa tabla es lo problematico, no el
resto. Hace poco me tope con un problema parecido, donde la tabla mas
grande del sistema es tambien la que sufre la mayor cantidad de updates
e inserts. Lo malo es que el diseño no es muy bueno, lo cual perjudica
aun mas. Lamentablemente es un caso patologico para Postgres, y debes
evitarlo de ser posible. Que tan grande es esa tabla?

Algunas sugerencias:

- en lo posible, trata de cambiar el modelo de manera que los updates y
deletes ocurran en tablas mas chicas (dividiendo la tabla grande segun
sea apropiado). No recomiendo que hagas esto si es que viola la
normalizacion, pero si el diseño es malo entonces es conveniente
hacerlo y no "sacarle el poto a la jeringa" solo para evitar modificar
la aplicacion. Es posible que estes pagando muy caro (en I/O
innecesario, y molestias de VACUUM) con un diseño malo, pero como no
conozco el diseño es dificil decirlo ;-)
(Si quieres puedes publicarlo y lo podemos comentar. Todo campo que
no sea NOT NULL es candidato de ser enviado a otra tabla.)

- trata de utilizar particionamiento (idealmente, con Postgres 8.2.1,
que es muy superior en este aspecto a los anteriores; pero con 8.1
tambien podria ser)

- desactiva autovacuum para esta tabla, y hazle vacuum manualmente a la
hora que mas te acomode. Ademas, ajusta maintenance_work_mem a un
valor mucho mas alto para que vacuum pueda hacerse mas rapidamente.

Te explico un poco este ultimo comentario. Cuando se hace vacuum de una
tabla, lo que hace es recorrer el "heap" buscando tuplas que deban
eliminarse, y almacena los CTIDs (direcciones del heap) de esas tuplas
en memoria, en un trozo de memoria de tamaño maintenance_work_mem.
Cuando se llena esa memoria, empieza un recorrido completo de cada uno
de los indices, buscando todas las referencias a alguno de esos CTIDs, y
los elimina tambien. Cuando eso esta listo, entonces continua el
recorrido del heap y vuelve a recolectar maintenance_work_mem CTIDs, y
vuelve a recorrer completamente todos los indices. Se hace eso hasta
que el heap se ha recorrido completamente.

Obviamente, cada recorrido de un indice lleva un costo bastante alto,
por lo que mientras menos veces se haga, mejor. De esto se desprende
que mientras mas alto sea maintenance_work_mem, menos recorridos se
hacen, y menos tiempo se tarda el vacuum.

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