Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Major pgbench synthetic SELECT workload regression, Ubuntu 23.04+PG15
Date: 2023-06-08 19:52:53
Message-ID: 140065.1686253973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Smith <gregsmithpgsql(at)gmail(dot)com> writes:
> Pushing SELECT statements at socket speeds with prepared statements is a
> synthetic benchmark that normally demos big pgbench numbers. My benchmark
> farm moved to Ubuntu 23.04/kernel 6.2.0-20 last month, and that test is
> badly broken on the system PG15 at larger core counts, with as much as an
> 85% drop from expectations.
> ... I could use some confirmation of where this happens from
> other tester's hardware and Linux kernels.

FWIW, I can't reproduce any such effect with PG HEAD on RHEL 8.8
(4.18.0 kernel) or Fedora 37 (6.2.14 kernel). Admittedly this is
with less-beefy hardware than you're using, but your graphs say
this should be obvious with even a dozen clients, and I don't
see that. I'm getting results like

$ pgbench -S -T 10 -c 16 -j 16 -M prepared pgbench
tps = 472503.628370 (without initial connection time)
$ pgbench -S -T 10 -c 16 -j 16 pgbench
tps = 297844.301319 (without initial connection time)

which is about what I'd expect.

Could it be that the breakage is Ubuntu-specific? Seems unlikely,
but ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2023-06-08 19:57:51 Re: Named Prepared statement problems and possible solutions
Previous Message Jan Wieck 2023-06-08 19:49:55 Re: Named Prepared statement problems and possible solutions