Re: [HACKERS] Should we cacheline align PGXACT?

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: [HACKERS] Should we cacheline align PGXACT?
Дата
Msg-id CAE9k0PkiDXkmcoTN=Lm0iMqP0W6+niONWzdyOZyoWCy3HcCCSg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Should we cacheline align PGXACT?  (Ashutosh Sharma <ashu.coek88@gmail.com>)
Ответы Re: [HACKERS] Should we cacheline align PGXACT?  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
Hi,

>> On Thu, Feb 16, 2017 at 5:07 AM, Alexander Korotkov
>> <a.korotkov@postgrespro.ru> wrote:
>> > On Wed, Feb 15, 2017 at 8:49 PM, Alvaro Herrera
>> > <alvherre@2ndquadrant.com>
>> > wrote:
>> >> Alexander Korotkov wrote:
>> >>
>> >> > Difference between master, pgxact-align-2 and pgxact-align-3 doesn't
>> >> > exceed
>> >> > per run variation.
>> >>
>> >> FWIW this would be more visible if you added error bars to each data
>> >> point.  Should be simple enough in gnuplot ...
>> >
>> > Good point.
>> > Please find graph of mean and errors in attachment.
>>
>> So ... no difference?
>
>
> Yeah, nothing surprising.  It's just another graph based on the same data.
> I wonder how pgxact-align-3 would work on machine of Ashutosh Sharma,
> because I observed regression there in write-heavy benchmark of
> pgxact-align-2.

I am yet to benchmark pgxact-align-3 patch on a read-write workload. I
could not do it as our benchmarking machine was already reserved for
some other test work. But, I am planning to do it on this weekend.
Will try to post my results by Monday evening. Thank you and sorry for
the delayed response.

Following are the pgbench results for read-write workload, I got with pgxact-align-3 patch. The results are for 300 scale factor with 8GB of shared buffer i.e. when data fits into the shared buffer. For 1000 scale factor with 8GB shared buffer the test is still running, once it is completed I will share the results for that as well.

pgbench settings:
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading  postgres

where, time_for_reading = 30mins

non default GUC param:
shared_buffers=8GB
max_connections=300

pg_xlog is located in SSD.

Machine details:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                128
On-line CPU(s) list:   0-127
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             8
NUMA node(s):          8
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 47
Model name:            Intel(R) Xeon(R) CPU E7- 8830  @ 2.13GHz


CLIENT COUNTTPS (HEAD)TPS (PATCH)% IMPROVEMENT
442834220-1.47093159
872917261-0.4114661912
1611909121492.015282559
322078920745-0.211650392
642841227831-2.044910601
1282936928765-2.056590282
1562794927189-2.719238613
1802787627171-2.529057254
1962884927872-3.386599189
2563032128188-7.034728406

Also, Excel sheet (results-read-write-300-SF) containing the results for all the 3 runs is attached.

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] UPDATE of partition key
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] GUC for cleanup indexes threshold.