Re: Wait free LW_SHARED acquisition

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: Wait free LW_SHARED acquisition
Дата
Msg-id 53B3440A.7060407@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: Wait free LW_SHARED acquisition  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список 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 по дате отправления:

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.