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

Re: BBU Cache vs. spindles

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Rob Wultsch <wultsch(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, jd(at)commandprompt(dot)com, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, Ben Chobot <bench(at)silentmedia(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: BBU Cache vs. spindles
Date: 2010-10-26 12:41:13
Message-ID: AANLkTi=hyctfYdQMsF2bQpsoswB5=+CSma5gbNKW=YoK@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performancepgsql-www
On Fri, Oct 22, 2010 at 3:05 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Rob Wultsch <wultsch(at)gmail(dot)com> wrote:
>
>> I would think full_page_writes=off + double write buffer should be
>> far superior, particularly given that the WAL is shipped over the
>> network to slaves.
>
> For a reasonably brief description of InnoDB double write buffers, I
> found this:
>
> http://www.mysqlperformanceblog.com/2006/08/04/innodb-double-write/
>
> One big question before even considering this would by how to
> determine whether a potentially torn page "is inconsistent".
> Without a page CRC or some such mechanism, I don't see how this
> technique is possible.

There are two sides to this problem: figuring out when to write a page
to the double write buffer, and figuring out when to read it back from
the double write buffer.  The first seems easy: we just do it whenever
we would XLOG a full page image.  As to the second, when we write the
page out to the double write buffer, we could also write to the double
write buffer the LSN of the WAL record which depends on that full page
image.  Then, at the start of recovery, we scan the double write
buffer and remember all those LSNs.  When we reach one of them, we
replay the full page image.

The good thing about this is that it would reduce WAL volume; the bad
thing about it is that it would probably mean doing two fsyncs where
we only now do one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-performance by date

Next:From: Christian ElmerotDate: 2010-10-26 12:55:06
Subject: CPUs for new databases
Previous:From: Mladen GogalaDate: 2010-10-26 12:32:54
Subject: Re: which one is faster

pgsql-www by date

Next:From: Rob WultschDate: 2010-10-26 14:13:53
Subject: Re: BBU Cache vs. spindles
Previous:From: Scott CareyDate: 2010-10-26 07:22:44
Subject: Re: BBU Cache vs. spindles

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