From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Scott Carey <scott(at)richrelevance(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Kenneth Cox <kenstir(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Advice configuring ServeRAID 8k for performance |
Date: | 2010-08-16 21:05:52 |
Message-ID: | 20100816210552.GC3911@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 16, 2010 at 04:54:19PM -0400, Greg Smith wrote:
> Andres Freund wrote:
> >A new checkpointing logic + a new syncing logic
> >(prepare_fsync() earlier and then fsync() later) would be a nice
> >thing. Do you plan to work on that?
> The background writer already caches fsync calls into a queue, so
> the prepare step you're thinking needs to be there is already. The
> problem is that the actual fsync calls happen in a tight loop. That
> we're busy fixing.
That doesn't help that much on many systems with a somewhat deep
queue. An fsync() equals a barrier so it has the effect of stopping
reordering around it - especially on systems with larger multi-disk
arrays thats pretty expensive.
You can achieve surprising speedups, at least in my experience, by
forcing the kernel to start writing out pages *without enforcing
barriers* first and then later enforce a barrier to be sure its
actually written out. Which, in a simplified case, turns the earlier
needed multiple barriers into a single one (in practise you want to
call fsync() anyway, but thats not a big problem if its already
written out).
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Burnett | 2010-08-17 01:06:30 | Very poor performance |
Previous Message | Greg Smith | 2010-08-16 20:54:19 | Re: Advice configuring ServeRAID 8k for performance |