Re: Possible performance regression in version 10.1 with pgbench read-write tests. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Possible performance regression in version 10.1 with pgbench read-write tests.
Date
Msg-id 16533.1532204391@sss.pgh.pa.us
Whole thread Raw
In response to Re: Possible performance regression in version 10.1 with pgbenchread-write tests.  (Andres Freund <andres@anarazel.de>)
Responses Re: Possible performance regression in version 10.1 with pgbenchread-write tests.  (Thomas Munro <thomas.munro@enterprisedb.com>)
List 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 by date:

Previous
From: Darafei "Komяpa" Praliaskouski
Date:
Subject: JIT breaks PostGIS
Next
From: Fabien COELHO
Date:
Subject: Re: Make foo=null a warning by default.