On 09/20/2011 09:35 AM, Heikki Linnakangas wrote:
> Yeah, I was thinking of write()s, not fsyncs. I agree this might have
> some effect during fsync phase.
Right; that's where the most serious problems seem to pop up at anyway
now. All the testing I did earlier this year suggested Linux at least
is happy to do a granular fsync, and it can also use things like
barriers when appropriate to schedule I/O. The hope here is that the
background writer work to clean ahead of the strategy point is helpful
to backends, and that should keep going even during the sync
phase--which currently doesn't pause for anything else once it's
started. The cleaner writes should all queue up into RAM in a lazy way
rather than block the true I/O, which is being driven by sync calls.
There is some risk here that the cleaner writes happen faster than the
true rate at which backends really need buffers, since it has a
predictive component it can be wrong about. Those could in theory
result in the write cache filling faster than it would in the current
environment, such that writes truly block that would have been cached in
the current code. If you're that close to the edge though, backends
should really benefit from the cleaner--that same write done by a client
would turn into a serious stall. From that perspective, when things
have completely filled the write cache, any writes the cleaner can get
out of the way in advance of when a backend needs it should be the
biggest win most of the time.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us