Re: Too many WAL(s) despite low transaction

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

 



* Selva manickaraja (mavles78@xxxxxxxxx) 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

Attachment: signature.asc
Description: Digital signature


[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