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 BANLkTinsoW-XHifcX9E+wHHXaHjWgR5ytA@mail.gmail.com
Whole thread Raw
In response to Re: Too many WAL(s) despite low transaction  ("Benjamin Krajmalnik" <kraj@servoyant.com>)
Responses Re: Too many WAL(s) despite low transaction
List 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


pgsql-admin by date:

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