Re: Possible performance regression in version 10.1 with pgbench read-write tests.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Possible performance regression in version 10.1 with pgbench read-write tests.
Дата
Msg-id 16533.1532204391@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Possible performance regression in version 10.1 with pgbenchread-write tests.  (Andres Freund <andres@anarazel.de>)
Ответы Re: Possible performance regression in version 10.1 with pgbenchread-write tests.
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-07-20 16:43:33 -0400, Tom Lane wrote:
>> On my RHEL6 machine, with unmodified HEAD and 8 sessions (since I've
>> only got 8 cores) but other parameters matching Mithun's example,
>> I just got

> It's *really* common to have more actual clients than cpus for oltp
> workloads, so I don't think it's insane to test with more clients.

I finished a set of runs using similar parameters to Mithun's test except
for using 8 clients, and another set using 72 clients (but, being
impatient, 5-minute runtime) just to verify that the results wouldn't
be markedly different.  I got TPS numbers like this:

                8 clients    72 clients

unmodified HEAD            16112        16284
with padding patch        16096        16283
with SysV semas            15926        16064
with padding+SysV        15949        16085

This is on RHEL6 (kernel 2.6.32-754.2.1.el6.x86_64), hardware is dual
4-core Intel E5-2609 (Sandy Bridge era).  This hardware does show NUMA
effects, although no doubt less strongly than Mithun's machine.

I would like to see some other results with a newer kernel.  I tried to
repeat this test on a laptop running Fedora 28, but soon concluded that
anything beyond very short runs was mainly going to tell me about thermal
throttling :-(.  I could possibly get repeatable numbers from, say,
1-minute SELECT-only runs, but that would be a different test scenario,
likely one with a lot less lock contention.

Anyway, for me, the padding change is a don't-care.  Given that both
Mithun and Thomas showed some positive effect from it, I'm not averse
to applying it.  I'm still -1 on going back to SysV semas.

            regards, tom lane


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

Предыдущее
От: Darafei "Komяpa" Praliaskouski
Дата:
Сообщение: JIT breaks PostGIS
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Make foo=null a warning by default.