Re: Too many WAL(s) despite low transaction

From: Selva manickaraja <mavles78(at)gmail(dot)com>
To: Benjamin Krajmalnik <kraj(at)servoyant(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Too many WAL(s) despite low transaction
Date: 2011-04-03 03:53:37
Message-ID: BANLkTinsoW-XHifcX9E+wHHXaHjWgR5ytA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

This is what we did and monitored the situation for one day.

1. We did vacuum/freeze/analyze first. Did not see any changes. WAL(s)
were still building up. So as recommended in the thread, we switched of
archiving and reran vacuum.
2. Set archive_timeout to 20min.
3. Deleted all old WAL(s) and started the db.

After about 10 minutes, the database started settling down on the WAL
generation.

There are points note and lessons to learn.

1. Changing archive_timeout did not have any effect without restarting
the db.I'm not sure why, perhaps due to not running the vacuum perhaps. But
to rule out this, we will attempt this tomorrow to see if it takes effect
without restating the db.
2. When the db was in development just changing the checkpoint_timeout
was sufficient to set the interval between WAL(s) that were shipped out.

Next actions to do:

1. Implement pg_compress, or pg_lesslog, pg_clearxlogtail
2. Check on how well autovacuum is running and how much to tune it.

Regards,

Selvam

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Stephen Frost 2011-04-03 10:52:51 Re: Too many WAL(s) despite low transaction
Previous Message Tom Lane 2011-04-02 20:00:27 Re: shared_preload_libraries