Hi,
On 2023-10-16 11:04:25 +0300, Anton A. Melnikov wrote:
> On 13.10.2023 05:05, Andres Freund wrote:
> > Could you provide a bit more details about how you ran the benchmark? The
> > reason I am asking is that ~330 TPS is pretty slow for -c20. Even on spinning
> > rust and using the default settings, I get considerably higher results.
> >
> > Oh - I do get results closer to yours if I use pgbench scale 1, causing a lot
> > of row level contention. What scale did you use?
>
>
> I use default scale of 1.
That means you're largely going to be bottlenecked due to row level
contention. For read/write pgbench you normally want to use a scale that's
bigger than the client count, best by at least 2x.
Have you built postgres with assertions enabled or such?
What is the server configuration for both versions?
> And run the command sequence:
> $pgbench -i bench
> $sleep 1
> $pgbench -c20 -T10 -j8
I assume you also specify the database name here, given you specified it for
pgbench -i?
As you're not doing a new initdb here, the state of the cluster will
substantially depend on what has run before. This can matter substantially
because a cluster with prior substantial write activity will already have
initialized WAL files and can reuse them cheaply, whereas one without that
activity needs to initialize new files. Although that matters a bit less with
scale 1, because there's just not a whole lot of writes.
At the very least you should trigger a checkpoint before or after pgbench
-i. The performance between having a checkpoint during the pgbench run or not
is substantially different, and if you're not triggering one explicitly, it'll
be up to random chance whether it happens during the run or not. It's less
important if you run pgbench for an extended time, but if you do it just for
10s...
E.g. on my workstation, if there's no checkpoint, I get around 633 TPS across
repeated runs, but if there's a checkpoint between pgbench -i and the pgbench
run, it's around 615 TPS.
Greetings,
Andres Freund