Re: Wait free LW_SHARED acquisition - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: Wait free LW_SHARED acquisition
Date
Msg-id 53B3440A.7060407@catalyst.net.nz
Whole thread Raw
In response to Re: Wait free LW_SHARED acquisition  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 01/07/14 23:25, Heikki Linnakangas wrote:
> On 07/01/2014 01:08 PM, Andres Freund wrote:
>> Hi,
>>
>> Over at -performance Mark Kirkwood tested a recent version of this
>> (http://archives.postgresql.org/message-id/53B283F3.7020005%40catalyst.net.nz)
>>
>> . I thought it's interesting to add the numbers to this thread:
>>
>>> Test: pgbench
>>> Options: scale 500
>>>           read only
>>> Os: Ubuntu 14.04
>>> Pg: 9.3.4
>>> Pg Options:
>>>      max_connections = 200
>>>      shared_buffers = 10GB
>>>      maintenance_work_mem = 1GB
>>>      effective_io_concurrency = 10
>>>      wal_buffers = 32MB
>>>      checkpoint_segments = 192
>>>      checkpoint_completion_target = 0.8
>>>
>>>
>>> Results
>>>
>>> Clients | 9.3 tps 32 cores | 9.3 tps 60 cores
>>> --------+------------------+-----------------
>>> 6       |  70400           |  71028
>>> 12      |  98918           | 129140
>>> 24      | 230345           | 240631
>>> 48      | 324042           | 409510
>>> 96      | 346929           | 120464
>>> 192     | 312621           |  92663
>>>
>>> So we have anti scaling with 60 cores as we increase the client
>>> connections.
>>> Ouch! A level of urgency led to trying out Andres's 'rwlock' 9.4
>>> branch [1]
>>> - cherry picking the last 5 commits into 9.4 branch and building a
>>> package
>>> from that and retesting:
>>>
>>> Clients | 9.4 tps 60 cores (rwlock)
>>> --------+--------------------------
>>> 6       |  70189
>>> 12      | 128894
>>> 24      | 233542
>>> 48      | 422754
>>> 96      | 590796
>>> 192     | 630672
>>
>> Now, this is a bit of a skewed comparison due to 9.4 vs. 9.3 but still
>> interesting.
>
> It looks like the issue I reported here:
>
> http://www.postgresql.org/message-id/5190E17B.9060804@vmware.com
>
> fixed by this commit:
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b03d196be055450c7260749f17347c2d066b4254.
>
>
> So, definitely need to compare plain 9.4 vs patched 9.4, not 9.3.
>

Here's plain 9.4 vs patched 9.4:

Clients | 9.4 tps 60 cores | 9.4 tps 60 cores (rwlock)
--------+------------------+--------------------------
6       |  69490           |  70189
12      | 128200           | 128894
24      | 232243           | 233542
48      | 417689           | 422754
96      | 464037           | 590796
192     | 418252           | 630672

It appears that plain 9.4 does not exhibit the dramatic anti scaling 
that 9.3 showed, but there is still evidence of some contention in the 
higher client numbers, and we peak at the 96 client mark. The patched 
variant looks pretty much free from this, still scaling at 192 
connections (might have been interesting to try more, but had 
max_connections set to 200)!

Cheers

Mark



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.
Next
From: Gurjeet Singh
Date:
Subject: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.