Skip site navigation (1) Skip section navigation (2)

Re: Choosing a filesystem

From: david(at)lang(dot)hm
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Guillaume Cottenceau <gc(at)mnc(dot)ch>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Choosing a filesystem
Date: 2008-09-13 21:26:40
Message-ID: alpine.DEB.1.10.0809131423570.17867@asgard.lang.hm (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 12 Sep 2008, Merlin Moncure wrote:

> 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.

although for postgres the thing that you are doing the fsync on is the WAL 
log file. that is a single (usually) contiguous file. As such it is very 
efficiant to write large chunks of it. so while you will degrade from the 
battery-only mode, the fact that the controller can flush many requests 
worth of writes out to the WAL log at once while you fill the cache with 
them one at a time is still a significant win.

David Lang

In response to

Responses

pgsql-performance by date

Next:From: Merlin MoncureDate: 2008-09-15 02:49:14
Subject: Re: Choosing a filesystem
Previous:From: davidDate: 2008-09-13 21:21:51
Subject: Re: Effects of setting linux block device readahead size

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group