Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter

From: Venkat Balaji <venkat(dot)balaji(at)verse(dot)in>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: : PG9.0 - Checkpoint tuning and pg_stat_bgwriter
Date: 2011-10-24 12:16:41
Message-ID: CAFrxt0ikC=GTvDQG52kKJhFoMZZ03xK8A4PDp8puw67_ix-7Uw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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(at)2ndQuadrant(dot)com Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
>
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Amitabh Kant 2011-10-24 14:04:20 Usage of pg_stat_database
Previous Message Stephen Frost 2011-10-24 00:41:41 Re: hstore query: Any better idea than adding more memory?