On Fri, 12 Sep 2008, Merlin Moncure wrote:
On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <gsmith@xxxxxxxxxxxxx> 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
