Re: The shared buffers challenge

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: The shared buffers challenge
Date: 2011-05-28 21:47:12
Message-ID: 4DE16D60.9070804@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 05/27/2011 07:30 PM, Mark Kirkwood wrote:
> Greg, having an example with some discussion like this in the docs
> would probably be helpful.

If we put that example into the docs, two years from now there will be
people showing up here saying "I used the recommended configuration from
the docs" that cut and paste it into their postgresql.conf, turning
autovacuum off and everything. Periodically people used to publish
"recommended postgresql.conf" settings on random web pages, sometimes
with poor suggestions, and those things kept showing up in people's
configurations posted to the lists here for long after they were no
longer applicable. I've resisted publishing specific configuration
examples in favor of working on pgtune specifically because of having
observed that.

There's several new small features in 9.1 that make it a easier to
instrument checkpoint behavior and how it overlaps with shared_buffers
increases: summary of sync times, ability to reset pg_stat_bgwriter,
and a timestamp on when it was last reset. It's not obvious at all how
those all stitch together into some new tuning approaches, but they do.
Best example I've given so far is at
http://archives.postgresql.org/pgsql-hackers/2011-02/msg00209.php ; look
at how I can turn the mysterious buffers_backend field into something
measured in MB/s using these new features.

That's the direction all this is moving toward. If it's easy for people
to turn the various buffer statistics into human-readable form, the way
tuning changes impact the server operation becomes much easier to see.
Documenting the much harder to execute methodology you can apply to
earlier versions isn't real exciting to me at this point. I've done
that enough that people who want the info can find it, even if it's not
all in the manual. The ways you can do it in 9.1 are so much easier,
and more accurate in regards to the sync issues, that I'm more
interested in beefing up the manual in regards to using them at this point.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jarrod Chesney 2011-05-31 00:08:28 Delete performance
Previous Message Mark Kirkwood 2011-05-28 10:15:15 Re: serveRAID M5014 SAS