One of the more useful bits of
PostgreSQL documentation I ever worked on is Tuning Your PostgreSQL
Server. When that was written in the summer of 2008, a few months after the
release of PostgreSQL 8.3, it was hard to find any similar guide that
was both (relatively) concise and current. Since then, myself and
many other PostgreSQL contributors have helped keep that document up
to date as changes to PostgreSQL were made.
The interesting and helpful trend
during that period is that parameters keep disappearing from the set
of ones you need to worry about. In PostgreSQL 8.2, there was a long
list of parameters you likely needed to adjust for good performance
on a PostgreSQL server: shared_buffers, effective_cache_size,
checkpoint_segments, autovacuum, max_fsm_pages,
default_statistics_target, work_mem, wal_buffers, and (if using
partitioning) constraint_exclusion.
8.3 made autovacuum default to being
turned on with reasonable behavior, along with removing a few
background writer parameters that caused nothing but trouble (they
never made it onto the list). 8.4 removed the need for the two
max_fsm_* parameters, increased default_statistics_target to a much
better starting value, and made setting constraint_exclusion
unnecessary in the most common cases. That’s six less parameters
that you are likely to need to adjust.
Unfortunately version 9.0 only made
server configuration more complicated. And newer Linux kernels even
pushed default behavior backwards. Starting with Linux kernel
2.6.33, the default value picked for wal_sync_method changed to
open_datasync. This turns out to have terrible performance
implications for PostgreSQL, particularly when combined with the low
default setting for wal_buffers in the server.
But the march toward better default
behavior has recently resumed for what is eventually planned to be
PostgreSQL 9.1. During the last CommitFest, a patch originated Marti
Raudsepp to fix the wal_sync_method problem was committed
after some heavy arguments over what form that change should take.
Discovering that this behavior change broke PostgreSQL altogether
when running on ext4 with “data=journal” option helped
settle the right thing to do here by default.
Two parameters I don’t recommend
touching in most cases are commit_siblings and commit_delay,
artifacts of an older attempt to improve performance on systems with
slow commit times (which includes most systems that don’t have a
battery-backed write cache for accelerating that area). Nowadays
turning off the synchronous_commit parameter introduced in 8.3 is
much more likely to help here. While these are unlikely to improve
performance, people who do try setting them have suffered more than
necessary from the downsides of that decision. The worst-case
behavior here was improved considerably in a patch I wrote to optimize how the logic those parameters control executes.
And this week the latest parameter to
be effectively eliminated in most cases is wal_buffers. A change I
suggested was commited to set this automatically as a percentage of the size (about 3%)
allocated to the normally much larger shared_buffers parameters.
This sets the value of wal_buffers to the normal upper limit of its
effective range, 16MB, once you’re allocated at least 512MB to
shared_buffers. And if you’ve increased shared_buffers from its tiny
default at all, you’ll get a corresponding improvement in this
important commit performance parameter. You’ll have to go out of
your way to break the setting of this parameter to hit the bad
situations possible in earlier versions.
Having the amount of configuration you
need to do to the server by default get less complicated is always
worthwhile, and seeing parameters disappear form the critical list is
a welcome change. What’s next? The core issues with allocating
shared memory on UNIX-derived operating systems, particularly Linux,
make it very difficult to eliminate shared_buffers. And concerns
over the server taking over the system altogether limit the ability
to automatically set parameters like work_mem to the right range.
Some proposals for better managing the working memory pool have been
suggested, so that one might see some improvement.
The next parameter I have my eye on is
checkpoint_segments. After adding just extra logging in this area in
the last CommitFest, there are some improvements in this area nearing
commit now to actually improve checkpoint behavior. I hope to
eventually switch over checkpoint tuning to be strictly controlled
via time-oriented parameters, rather than requiring users to
understand the mechanics of how the write-ahead log works to tune the
system. There’s still too many ugly situations possible here to do
that in time for 9.1, but setting the segments count automatically is
feasible to target for 9.2.