From: Greg Smith <greg@2ndquadrant.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pierre C <lists@peufeu.com>
Cc: Dave Crooke <dcrooke@gmail.com>
Cc: Paul McGarry <paul@paulmcgarry.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: shared_buffers advice
Date: Tue, 16 Mar 2010 19:54:52 -0400
Message-ID: <4BA01A4C.9090509@2ndquadrant.com> (raw)
In-Reply-To: <20100316213054.GG3037@alvh.no-ip.org>
References: <a056b1d41003101728h2bfe964cg43bf5ef1aabae14d@mail.gmail.com>
<ca24673e1003152217q117b0fd3q7d2d75ff20185c8b@mail.gmail.com>
<4B9F3302.4020900@2ndquadrant.com>
<op.u9nrbeeteorkce@localhost>
<8285.1268749832@sss.pgh.pa.us>
<407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com>
<20100316213054.GG3037@alvh.no-ip.org>
Alvaro Herrera wrote:
> Maybe it would make more sense to try to reorder the fsync calls
> instead.
>
The pretty obvious left behind idea from 8.3 spread checkpoint
development was to similarly spread the fsync calls around. Given that
we know, for example, Linux with ext3 is going to dump the whole
filesystem write cache out when the fsync call comes in, the way they're
currently scheduled has considerably potential for improvement.
Unfortunately, since the tuning on that is going to be very platform
dependent and require a lot of benchmarking work, I think we need a
performance farm up and running as a prerequisite to finishing that work
off. The spread checkpoint stuff was a much more obvious improvement,
and that was hard enough to quantify usefully and test.
Returning to the idea of the sorted checkpoints patch as a simple
example, if it were possible to just push that patch to a test repo and
see how that changed typical throughput/latency against a
well-established history, it would be a lot easier to figure out if
something like that is sensible to consider or not. I'm not sure how to
make progress on similar ideas about tuning closer to the filesystem
level without having something automated that takes over the actual
benchmark running and data recording steps; it's just way too time
consuming to do those right now with every tool that's available for
PostgreSQL so far. That's the problem I work on, there are easily a
half dozen good ideas for improvements here floating around where coding
time is dwarfed by required performance validation time.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: greg@2ndquadrant.com, alvherre@commandprompt.com, gsstark@mit.edu, tgl@sss.pgh.pa.us, lists@peufeu.com, dcrooke@gmail.com, paul@paulmcgarry.com
Subject: Re: shared_buffers advice
In-Reply-To: <4BA01A4C.9090509@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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