Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter

Поиск
Список
Период
Сортировка
От Venkat Balaji
Тема Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter
Дата
Msg-id CAFrxt0ikC=GTvDQG52kKJhFoMZZ03xK8A4PDp8puw67_ix-7Uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Thanks Greg !

Sorry for delayed response.

We are actually waiting to change the checkpoint_segments in our production systems (waiting for the downtime).

Thanks
VB

On Wed, Oct 5, 2011 at 11:02 AM, Greg Smith <greg@2ndquadrant.com> wrote:
On 10/04/2011 07:50 PM, Venkat Balaji wrote:
I was thinking to increase checkpoint_segments to around 16 or 20.

I think 50 is a bit higher.


Don't be afraid to increase that a lot.  You could set it to 1000 and that would be probably turn out fine; checkpoints will still happen every 5 minutes.

Checkpoints represent a lot of the I/O in a PostgreSQL database.  The main downside to making them less frequent is that recovery after a crash will take longer; a secondary one is that WAL files in pg_xlog will take up more space.  Most places don't care much about either of those things.  The advantage to making them happen less often is that you get less total writes.  People need to be careful about going a long *time* between checkpoints.  But there's very few cases where you need to worry about the segment count going too high before another one is triggered.


--
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us


В списке pgsql-performance по дате отправления:

Предыдущее
От: David Boreham
Дата:
Сообщение: Re: Choosing between Intel 320, Intel 510 or OCZ Vertex 3 SSD for db server
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Tsearch2 - bad performance with concatenated ts-vectors