On 29.01.2025 21:52, Ilia Evdokimov wrote:
... I also attached the benchmark.sh
script used to generate the output.
In my opinion, if we can't observe bottleneck of spinlock on 32 CPUs,
we should determine the CPU count at which it becomes. This will help
us understand the scale of the problem. Does this make sense, or are
there really no real workloads where the same query runs on more than
32 CPUs, and we've been trying to solve a non-existent problem?
I ran the same benchmark on 48 CPUs for -c 48 -j 20 for objectivity.
### 48 connections
pgbench -c48 -j20 -S -Mprepared -T120 --progress 10
sample_rate = 1
tps = 643251.640175 (without initial connection time)
waits
-----
932 ClientRead
911 CPU
44 SpinDelay
sample_rate = .75
tps = 653946.777122 (without initial connection time)
waits
-----
939 CPU
875 ClientRead
3 SpinDelay
sample_rate = .5
tps = 651654.348463 (without initial connection time)
waits
-----
932 ClientRead
841 CPU
sample_rate = .25
tps = 652668.807245 (without initial connection time)
waits
-----
910 ClientRead
860 CPU
sample_rate = 0
tps = 659111.347019 (without initial connection time)
waits
-----
882 ClientRead
849 CPU
There is a small amount ofSpinDelay, as the user mentioned. However, we
can identify the threshold where the problem appears.
To summarize the results of all benchmarks, I compiled them into a table:
CPUs | sample_rate | tps | CPU waits | ClientRead wait | SpinDelay wait
192 | 1.0 | 484338| 9568 | 929 | 11107
192 | 0.75 | 909547| 12079 | 2100 | 4781
192 | 0.5 |1028594| 13253 | 3378 | 174
192 | 0.25 |1019507| 13397 | 3423 | -
192 | 0.0 |1015425| 13106 | 3502 | -
48 | 1.0 | 643251| 911 | 932 | 44
48 | 0.75 | 653946| 939 | 939 | 3
48 | 0.5 | 651654| 841 | 932 | -
48 | 0.25 | 652668| 860 | 910 | -
48 | 0.0 | 659111| 849 | 882 | -
32 | 1.0 | 620667| 1782 | 560 | -
32 | 0.75 | 620667| 1736 | 554 | -
32 | 0.5 | 624094| 1741 | 648 | -
32 | 0.25 | 628638| 1702 | 576 | -
32 | 0.0 | 630483| 1638 | 574 | -
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
