Re: vacuumdb -a -f - Mailing list pgsql-admin

From D Kavan
Subject Re: vacuumdb -a -f
Date
Msg-id BAY102-F4193BEA67280458D1C4CDED1B30@phx.gbl
Whole thread Raw
In response to vacuumdb -a -f  ("D Kavan" <bitsandbytes88@hotmail.com>)
List pgsql-admin

CASE CLOSED!

Thanks for the tip on the reindex script.  That did the trick.  It was one
table in particuliar.

~DjK
















>From: Chris Hoover <revoohc@gmail.com>
>To: Guido Barosio <gbarosio@gmail.com>
>CC: D Kavan <bitsandbytes88@hotmail.com>, pgsql-admin@postgresql.org
>Subject: Re: [ADMIN] vacuumdb -a -f
>Date: Wed, 17 Aug 2005 12:57:16 -0400
>
>You might want to try doing a reindexdb -a -e (reindexdb is in the
>contrib directory of your pg source).  The first time I ran this, I
>gained back a significant amount of space.
>
>I now run a vacuumdb -v -f -a and then a reindexdb -a -e every weekend
>to have PostgreSQL give back as much space as it can.  I have ended up
>doing this do to space and i/o constraints.
>
>Give the reindexdb script a try and see if you don't get your space back.
>
>HTH,
>
>Chris
>
>On 8/17/05, Guido Barosio <gbarosio@gmail.com> wrote:
> > How are you finding out the DB size?
> >
> > G.-
> >
> >
> >
> > On 8/17/05, D Kavan <bitsandbytes88@hotmail.com> wrote:
> > > Hi,
> > >
> > > Thanks for the tips.
> > >
> > > Unfortunatley for me,  even after started doing vacuumdb -a 3 times a
>day
> > > and increasing fsm dramatically , the size of the database won't go
>down
> > > even 1 MB.  It's stil at 5.6 GB, size after restore = 4 GB.   I even
>did a
> > > stop/start instead of a re-load to make sure the settings took affect.
> > Would
> > > a reboot help?
> > >
> > > max_fsm_pages = 16000001
> > > max_fsm_relations = 1000000
> > >
> > > shared_buffers = 65536
> > > work_mem = 32768
> > > maintenance work mem = 786432
> > >
> > > checkpoint_segments = 18
> > >
> > >
> > > ##/etc/sysctl.conf
> > >
> > > nel.shmall = 524288
> > > #kernel.shmall = 2097152
> > > #kernel.shmmax = 2147483648
> > > #kernel.shmmax = 1073741824
> > > kernel.shmmax = 6979321856
> > > kernel.shmmni = 4096
> > > kernel.sem = 250 32000 100 128
> > > fs.file-max = 65536
> > > net.ipv4.ip_local_port_range = 1024 65000
> > > vm.overcommit_memory = 2
> > >
> > >
> > > ~DjK
> > >
> > >
> > >
> > >
> > >
> > > >From: Tom Lane <tgl@sss.pgh.pa.us>
> > > >To: "D Kavan" < bitsandbytes88@hotmail.com>
> > > >CC: pgsql-admin@postgresql.org
> > > >Subject: Re: [ADMIN] vacuumdb -a -f Date: Mon, 15 Aug 2005 21:31:01
>-0400
> > > >
> > > >"D Kavan" <bitsandbytes88@hotmail.com> writes:
> > > > > Even though I run vacuumdb -a -f every night with no exceptions or
> > > >problems,
> > > > > my database size remains 5.6 GB.  After I do a dump/restore, the
>new
> > > > > database size is 4.0 GB.  How could that be possible?
> > > >
> > > >The extra 1.6GB probably represents the amount of junk you generate
>in
> > > >one day.  So, forget the -f and instead do plain vacuums on a more
> > > >frequent basis.  Make sure your FSM settings are large enough, too.
> > > >
> > > >                       regards, tom lane
> > >
> > >
> > >
> > > ---------------------------(end of
> > broadcast)---------------------------
> > > TIP 6: explain analyze is your friend
> > >
> >
> >
> >
> > --
> > "Adopting the position that you are smarter than an automatic
> > optimization algorithm is generally a good way to achieve less
> > performance, not more" - Tom Lane.



pgsql-admin by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: GRANT ALL PRIVILEGES ON DATABASE
Next
From: Chris Hoover
Date:
Subject: Re: vacuumdb -a -f