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.
In response to
pgsql-performance by date
|Next:||From: Merlin Moncure||Date: 2008-09-15 02:49:14|
|Subject: Re: Choosing a filesystem|
|Previous:||From: david||Date: 2008-09-13 21:21:51|
|Subject: Re: Effects of setting linux block device readahead size|