Re: Choosing a filesystem - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Choosing a filesystem
Date
Msg-id b42b73150809120735r663d8687had9da4b1a936cbe5@mail.gmail.com
Whole thread Raw
In response to Re: Choosing a filesystem  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: Choosing a filesystem
List pgsql-performance
On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <gsmith@gregsmith.com> wrote:
> On Fri, 12 Sep 2008, Guillaume Cottenceau wrote:
>
> That's the main thing, and nothing else you can do will accelerate that.
> Without a useful write cache (which usually means RAM with a BBU), you'll at
> best get about 100-200 write transactions per second for any one client, and
> something like 500/second even with lots of clients (queued up transaction
> fsyncs do get combined).  Those numbers increase to several thousand per
> second the minute there's a good caching controller in the mix.

While this is correct, if heavy writing is sustained, especially on
large databases, you will eventually outrun the write cache on the
controller and things will start to degrade towards the slow case.  So
it's fairer to say that caching raid controllers burst up to several
thousand per second, with a sustained write rate somewhat better than
write-through but much worse than the burst rate.

How fast things degrade from the burst rate depends on certain
factors...how big the database is relative to the o/s read cache in
the controller write cache, and how random the i/o is generally.  One
thing raid controllers are great at is smoothing bursty i/o during
checkpoints for example.

Unfortunately when you outrun cache on raid controllers the behavior
is not always very pleasant...in at least one case I've experienced
(perc 5/i) when the cache fills up the card decides to clear it before
continuing.  This means that if fsync is on, you get unpredictable
random freezing pauses while the cache is clearing.

merlin

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: Choosing a filesystem
Next
From: George McCollister
Date:
Subject: Postgres Performance on CPU limited Platforms