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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
