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

Re: Vacuumdb

From: Mario Soto Cordones - Venezuela <msotocl(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-es postgresql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Vacuumdb
Date: 2005-07-26 14:26:10
Message-ID: e9b17cde0507260726426f0114@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
El 25/07/05, Alvaro Herrera<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> On Mon, Jul 25, 2005 at 03:06:07PM -0400, Mario Soto Cordones - Venezuela wrote:
> > Hola Lista tengo la siguiente consulta,  tengo una base de datos con
> > muchas tablas, una de ellas tiene aproximadamente 5 millones de
> > registros y tambien varios indices..... Al hacer el vacuumdb -z -v -a
> > -f ,  cuando llega a esta tabla se demora casi 12 horas en
> > completarlo.... Y los discos se vuelven locos trabajando, alguien
> > tiene alguna idea de como poder hacer esto mas rapido ya que por lo
> > general debo parar el vacuumdb ya que el sistema se torna
> > inaccesiblemente lento, trate de hacer un pg_resetxlog pero el
> > resultado es el mismo
> 
> Primero que nada, pg_resetxlog no tiene nada que ver con el problema.
> 
> Segundo, lo mas probable es que cada vez que ejecutas vacuum y lo cortas
> despues de un tiempo de ejecucion, vayas "echando a perder" cada vez mas
> la tabla y los indices, porque van acumulando tuplas obsoletas y el
> problema es cada vez peor.
> 
> Tercero, en este momento estas en una situacion critica e indeseable, la
> cual es importante evitar en el futuro.  Si eliminas o actualizas muchas
> tuplas de esa tabla, quizas seria conveniente que ejecutaras vacuumdb
> sin -f (es decir vacuum no full), con una frecuencia mayor que un dia.
> 
> Cuarto, para salir del problema actual, tienes al menos tres
> alternativas:
> 
> 1. aumentar maintenance_work_mem o vacuum_mem (dependiendo de la
> version) a un valor bastante alto, usando SET, y luego ejecutar el
> vacuum full sobre esa tabla.  Ojo que el incremento debe ser solo para
> la conexion que ejecuta el vacuum full.  Dejalo todo el tiempo que
> necesite, no lo cortes antes de que haya terminado.
> 
> 2. no usar vacuum, sino CLUSTER.  Esto es mejor que vacuum, porque este
> ultimo empeora la situacion de los indices, en cambio cluster reescribe
> toda la tabla y los indices desde cero.  Yo diria que esta es tu mejor
> apuesta.  Dejalo corriendo todas las horas que necesite.
> 
> 3. Haz un pg_dump -t de esa tabla, luego la cargas en una tabla nueva,
> borras la antigua y le cambias el nombre a la nueva.  (Esto es casi
> exactamente lo mismo que hacer CLUSTER)
> 

Creo que esta es la mejor opcion, por tiempo, que creen ustedes ????

> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> <Schwern> It does it in a really, really complicated way
> <crab> why does it need to be complicated?
> <Schwern> Because it's MakeMaker.
> 


-- 
cordialmente,

Ing. Mario Soto Cordones

In response to

pgsql-es-ayuda by date

Next:From: Martín MarquésDate: 2005-07-26 14:36:22
Subject: Re: Vacuumdb
Previous:From: Ing. Jhon Carrillo - Caracas, VenezuelaDate: 2005-07-26 14:25:25
Subject: Maximo de argumentos en una function

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