Re: Choosing a filesystem

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Greg Smith" <gsmith(at)gregsmith(dot)com>
Cc: "Guillaume Cottenceau" <gc(at)mnc(dot)ch>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Choosing a filesystem
Date: 2008-09-12 14:35:32
Message-ID: b42b73150809120735r663d8687had9da4b1a936cbe5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <gsmith(at)gregsmith(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message H. Hall 2008-09-12 18:07:09 Re: Postgres Performance on CPU limited Platforms
Previous Message George McCollister 2008-09-12 14:13:13 Postgres Performance on CPU limited Platforms