Re: Too many WAL(s) despite low transaction

Поиск
Список
Период
Сортировка
От Selva manickaraja
Тема Re: Too many WAL(s) despite low transaction
Дата
Msg-id BANLkTinsoW-XHifcX9E+wHHXaHjWgR5ytA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Too many WAL(s) despite low transaction  ("Benjamin Krajmalnik" <kraj@servoyant.com>)
Ответы Re: Too many WAL(s) despite low transaction
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: shared_preload_libraries
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Too many WAL(s) despite low transaction