pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Scott Carey <scott@richrelevance.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Kenneth Cox <kenstir@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Advice configuring ServeRAID 8k for performance
Date: Mon, 16 Aug 2010 23:05:52 +0200
Message-ID: <20100816210552.GC3911@anarazel.de> (raw)
In-Reply-To: <4C69A57B.80605@2ndquadrant.com>
References: <201008131817.o7DIH1b03550@momjian.us>
	<4C6591D9.1080206@2ndquadrant.com>
	<5687A8AD-CA70-4272-A32C-6AE5F491CEA4@richrelevance.com>
	<4C69796D.9000408@2ndquadrant.com>
	<20100816200227.GA3911@anarazel.de>
	<4C699BE2.50606@2ndquadrant.com>
	<20100816201838.GB3911@anarazel.de>
	<4C69A57B.80605@2ndquadrant.com>

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



view thread (33+ messages)  latest in thread

Message-ID: <20100816210552.GC3911@anarazel.de>
Permalink:  ../20100816210552.GC3911@anarazel.de/
Also on:    postgresql.org/message-id/20100816210552.GC3911@anarazel.de

 · 

reply

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: andres@anarazel.de, greg@2ndquadrant.com, scott@richrelevance.com, bruce@momjian.us, kenstir@gmail.com
  Subject: Re: Advice configuring ServeRAID 8k for performance
  In-Reply-To: <20100816210552.GC3911@anarazel.de>

* 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