Skip site navigation (1) Skip section navigation (2)

upping checkpoints on production server

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: upping checkpoints on production server
Date: 2003-09-24 21:24:14
Message-ID: 1064438654.25702.2076.camel@camel (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
All this talk of checkpoints got me wondering if I have them set at an
optimum level on my production servers. I noticed the following in the

 "There will be at least one 16 MB segment file, and will normally not
be more than 2 * checkpoint_segments + 1 files. You can use this to
estimate space requirements for WAL. Ordinarily, when old log segment
files are no longer needed, they are recycled (renamed to become the
next segments in the numbered sequence). If, due to a short-term peak of
log output rate, there are more than 2 * checkpoint_segments + 1 segment
files, the unneeded segment files will be deleted instead of recycled
until the system gets back under this limit." 

In .conf file I have default checkpoints set to 3, but I noticed that in
my pg_xlog directory I always seem to have at least 8 log files. Since
this is more than the suggested 7, I'm wondering if this means I ought
to bump my checkpoint segments up to 4?  I don't really want to bump it
up unnecessarily as quick recover time is important on this box, however
if i would get an overall performance boost it seems like it would be
worth it, and given that I seem to be using more than the default number
anyways... I've always treated wal logs as self maintaining, am I over
analyzing this?

Another thought popped into my head, is it just coincidence that I
always seem to have 8 files and that wal_buffers defaults to 8? Seems
like it's not but I love a good conspiracy theory.

Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-performance by date

Next:From: Tom LaneDate: 2003-09-24 21:57:45
Subject: Re: upping checkpoints on production server
Previous:From: Rod TaylorDate: 2003-09-24 18:35:50
Subject: Re: Performance issue

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group