Re: Too many WAL(s) despite low transaction

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux