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

Re: Could synchronous streaming replication really degrade the performance of the primary?

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Robert Klemme <shortcutter(at)googlemail(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Could synchronous streaming replication really degrade the performance of the primary?
Date: 2012-05-09 18:58:04
Message-ID: CAHyXU0wc6ZxSK2E2R78QVNVu03Cym5+vawyt82Lx-p_ZD9pLBw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Wed, May 9, 2012 at 12:03 PM, Robert Klemme
<shortcutter(at)googlemail(dot)com> wrote:
> On Wed, May 9, 2012 at 5:45 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> On Wed, May 9, 2012 at 12:41 PM, Robert Klemme
>> <shortcutter(at)googlemail(dot)com> wrote:
>>> I am not sure whether the replicant can be triggered to commit to disk
>>> before the commit to disk on the master has succeeded; if that was the
>>> case there would be true serialization => 50%.
>>>
>>> This sounds like it could actually be the case (note the "after it commits"):
>>> "When synchronous replication is requested the transaction will wait
>>> after it commits until it receives confirmation that the transfer has
>>> been successful."
>>> http://wiki.postgresql.org/wiki/Synchronous_replication
>>
>> That should only happen for very short transactions.
>> IIRC, WAL records can be sent to the slaves before the transaction in
>> the master commits, so bigger transactions would see higher
>> parallelism.
>
> I considered that as well.  But the question is: when are they written
> to disk in the slave?  If they are in buffer cache until data is
> synched to disk then you only gain a bit of advantage by earlier
> sending (i.e. network latency).  Assuming a high bandwidth and low
> latency network (which you want to have in this case anyway) that gain
> is probably not big compared to the time it takes to ensure WAL is
> written to disk.  I do not know implementation details but *if* the
> server triggers sync only after its own sync has succeeded *then* you
> basically have serialization and you need to wait twice the time.
>
> For small TX OTOH network overhead might relatively large compared to
> WAL IO (for example with a battery backed cache in the controller)
> that it shows.  Since we do not know the test cases which lead to the
> 50% statement we can probably only speculate.  Ultimately each
> individual setup and workload has to be tested.

yeah. note the upcoming 9.2 synchronous_commit=remote_write setting is
intended to improve this situation by letting the transaction go a bit
earlier -- the slave basically only has to acknowledge receipt of the
data.


merlin

In response to

pgsql-performance by date

Next:From: MauMauDate: 2012-05-09 22:34:04
Subject: Re: Could synchronous streaming replication really degrade the performance of the primary?
Previous:From: Robert KlemmeDate: 2012-05-09 17:03:14
Subject: Re: Could synchronous streaming replication really degrade the performance of the primary?

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