Re: Too many WAL(s) despite low transaction - Mailing list pgsql-admin

From Selva manickaraja
Subject Re: Too many WAL(s) despite low transaction
Date
Msg-id AANLkTinoAVz9qH=fV=qNxMyZnzBXsweDgGK4hQCEebZr@mail.gmail.com
Whole thread Raw
In response to Re: Too many WAL(s) despite low transaction  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Too many WAL(s) despite low transaction  (Stephen Frost <sfrost@snowman.net>)
List pgsql-admin
Where you mentioned "after the reload" I suppose you meant restart right?

About compressing you mentioned iirc, but how do I use it? are there any examples. I read about pg_compress before. Is that same?

The configuration file shows that autovacuum=on and track_count=on to be commented out. That means that it is not running right? If that's the case, just uncommenting it now should get it working right?

OK, I'm going to hold on to the VACUUM FREEZE ANALYZE for time being.

Yes Stephen you have been extraordinarily helpful.

I will wait for your reply.


On Fri, Apr 1, 2011 at 10:22 AM, Stephen Frost <sfrost@snowman.net> wrote:
* Selva manickaraja (mavles78@gmail.com) wrote:
> 1. Set archive_timeout = 20m (Does the change require db restart to take
> effect?)

I *think* it can be changed with just a reload, but I'm not 100% sure.
Check your logs after doing the reload, it'll complain if it isn't able
to change that parameter on reload.

20m sounds reasonable, still would recommend compressing the WALs if
they're likely to be less than full (less than 16M of data in 20m).

> 2. Set  autovacuum=on and track_count=on (Does the change require db restart
> to take effect?)
>     Does that mean we are running autovacuum?

This is the default, so unless you changed the default, yes, it's
already running.

> 3. Run VACUUM FREEZE ANALYZE since bulk loading was done earlier. (Can this
> be done while the db is active and on production?)

Yes, you can freeze records while the DB is running (erm, I don't know
that you can run it w/o the DB running..).  I don't know that I'd jump
to running it right away though, unless you know that you need it...?

> All 3 steps is to lower the WAL files that are being shipped out.

Uhh, the only option that's going to affect that is the first one..

> Is this a workable action to achieve the result required?

You probably just need to change archive_timeout and reload the
database.  Well, you also need to go read the documentation, but that's
beside the point.

> Please assist.

Uhm, pretty sure I have been?

       Thanks,

               Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk2VNtEACgkQrzgMPqB3kig1ugCeMqz9PWDozSYpfVsJh4SxzitJ
EKAAmQFPiVurdCDNxW5YEKE4JICHHUFq
=mJol
-----END PGP SIGNATURE-----


pgsql-admin by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Too many WAL(s) despite low transaction
Next
From: Stephen Frost
Date:
Subject: Re: Too many WAL(s) despite low transaction