pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedWrong docs on checkpoint_segments?
4+ messages / 2 participants
[nested] [flat]
* Wrong docs on checkpoint_segments?
@ 2011-01-07 12:45 Florian Weimer <fweimer@bfk.de>
0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2011-01-07 12:45 UTC (permalink / raw)
To: pgsql-performance
On 9.0, this configuration
checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
results in 1034 segments, so the effective logfile segment size is 32 MB.
The documentation says this:
Maximum number of log file segments between automatic WAL
checkpoints (each segment is normally 16 megabytes). The default
is three segments. Increasing this parameter can increase the
amount of time needed for crash recovery. This parameter can only
be set in the postgresql.conf file or on the server command line.
It would probably make sense to change this to
checkpoint_segments = 3 # each one effectively needs about 32MB on disk
and:
Number of log file segments between automatic WAL checkpoints. The
default is three segments. Increasing this parameter can increase
the amount of time needed for crash recovery. This parameter can
only be set in the postgresql.conf file or on the server command
line.
Each segment normally requires 16 megabytes on disk. Segments can
only be recycled after a checkpoint has completed, so disk space
is required for twice the number of configured segments, plus some
reserve.
Perhaps it would also make sense to mention that increasing the
segment count decreases WAL traffic, and that changing this value does
not have an impact on transaction sizes?
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Wrong docs on checkpoint_segments?
@ 2011-01-07 13:39 Andres Freund <andres@anarazel.de>
parent: Florian Weimer <fweimer@bfk.de>
0 siblings, 1 reply; 4+ messages in thread
From: Andres Freund @ 2011-01-07 13:39 UTC (permalink / raw)
To: pgsql-performance; +Cc: Florian Weimer <fweimer@bfk.de>
On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
> On 9.0, this configuration
>
> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
>
> results in 1034 segments, so the effective logfile segment size is 32 MB.
Um. Is it possible that you redefined XLOG_SEG_SIZE or used --with-wal-
segsize=SEGSIZE?
The default is still:
andres@alap2:~/src/postgresql$ grep XLOG_SEG_SIZE src/include/pg_config.h
/* XLOG_SEG_SIZE is the size of a single WAL file. This must be a power of 2
XLOG_BLCKSZ). Changing XLOG_SEG_SIZE requires an initdb. */
#define XLOG_SEG_SIZE (16 * 1024 * 1024)
Andres
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Wrong docs on checkpoint_segments?
@ 2011-01-07 13:45 Florian Weimer <fweimer@bfk.de>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2011-01-07 13:45 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-performance
* Andres Freund:
> On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
>> On 9.0, this configuration
>>
>> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
>>
>> results in 1034 segments, so the effective logfile segment size is 32 MB.
> Um. Is it possible that you redefined XLOG_SEG_SIZE or used --with-wal-
> segsize=SEGSIZE?
No, the individual files are still 16 MB. It's just that the
checkpoint_segments limit is not a hard limit, and you end up with
slightly more than twice the configured number of segments on disk.
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Wrong docs on checkpoint_segments?
@ 2011-01-07 13:47 Andres Freund <andres@anarazel.de>
parent: Florian Weimer <fweimer@bfk.de>
0 siblings, 0 replies; 4+ messages in thread
From: Andres Freund @ 2011-01-07 13:47 UTC (permalink / raw)
To: Florian Weimer <fweimer@bfk.de>; +Cc: pgsql-performance
On Friday, January 07, 2011 02:45:02 PM Florian Weimer wrote:
> * Andres Freund:
> > On Friday, January 07, 2011 01:45:25 PM Florian Weimer wrote:
> >> On 9.0, this configuration
> >>
> >> checkpoint_segments = 512 # in logfile segments, min 1, 16MB each
> >>
> >> results in 1034 segments, so the effective logfile segment size is 32
> >> MB.
> >
> > Um. Is it possible that you redefined XLOG_SEG_SIZE or used --with-wal-
> > segsize=SEGSIZE?
>
> No, the individual files are still 16 MB. It's just that the
> checkpoint_segments limit is not a hard limit, and you end up with
> slightly more than twice the configured number of segments on disk.
Thats documented:
"
There will always be at least one WAL segment file, and will normally not be
more files than the higher of wal_keep_segments or (2 +
checkpoint_completion_target) * checkpoint_segments + 1. Each segment file is
normally 16 MB (though this size can be altered when building the server). 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 3 * checkpoint_segments + 1 segment files, the
unneeded segment files will be deleted instead of recycled until the system
gets back under this limit.
"
Andres
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2011-01-07 13:47 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-01-07 12:45 Wrong docs on checkpoint_segments? Florian Weimer <fweimer@bfk.de>
2011-01-07 13:39 ` Andres Freund <andres@anarazel.de>
2011-01-07 13:45 ` Florian Weimer <fweimer@bfk.de>
2011-01-07 13:47 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox