Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Дата
Msg-id CAEudQAph+KiOXFYBHwo=C3Tw-JpbO=N88J44gW0_puNy62On-A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Andres Freund <andres@anarazel.de>)
Ответы Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers


Em sex., 27 de mai. de 2022 às 18:08, Andres Freund <andres@anarazel.de> escreveu:
Hi,

On 2022-05-27 03:30:46 +0200, Tomas Vondra wrote:
> On 5/27/22 02:11, Ranier Vilela wrote:
> > ./pgbench -M prepared -c $conns -j $conns -T 60 -S -n -U postgres
> >
> > pgbench (15beta1)
> > transaction type: <builtin: select only>
> > scaling factor: 1
> > query mode: prepared
> > number of clients: 100
> > number of threads: 100
> > maximum number of tries: 1
> > duration: 60 s
> >
> > conns            tps head              tps patched
> >
> > 1         17126.326108            17792.414234
> > 10       82068.123383            82468.334836
> > 50       73808.731404            74678.839428
> > 80       73290.191713            73116.553986
> > 90       67558.483043            68384.906949
> > 100     65960.982801            66997.793777
> > 200     62216.011998            62870.243385
> > 300     62924.225658            62796.157548
> > 400     62278.099704            63129.555135
> > 500     63257.930870            62188.825044
> > 600     61479.890611            61517.913967
> > 700     61139.354053            61327.898847
> > 800     60833.663791            61517.913967
> > 900     61305.129642            61248.336593
> > 1000   60990.918719            61041.670996
> >
>
> These results look much saner, but IMHO it also does not show any clear
> benefit of the patch. Or are you still claiming there is a benefit?

They don't look all that sane to me - isn't that way lower than one would
expect?
Yes, quite disappointing.

Restricting both client and server to the same four cores, a
thermically challenged older laptop I have around I get 150k tps at both 10
and 100 clients.
And you can share the benchmark details? Hardware, postgres and pgbench, please?

Either way, I'd not expect to see any GetSnapshotData() scalability effects to
show up on an "Intel® Core™ i5-8250U CPU Quad Core" - there's just not enough
concurrency.
This means that our customers will not see any connections scalability with PG15, using the simplest hardware?


The correct pieces of these changes seem very unlikely to affect
GetSnapshotData() performance meaningfully.

To improve something like GetSnapshotData() you first have to come up with a
workload that shows it being a meaningful part of a profile. Unless it is,
performance differences are going to just be due to various forms of noise.
Actually in the profiles I got with perf, GetSnapShotData() didn't show up.

regards,
Ranier Vilela

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

Предыдущее
От: "Regina Obe"
Дата:
Сообщение: RE: [PATCH] Support % wildcard in extension upgrade filenames
Следующее
От: Ranier Vilela
Дата:
Сообщение: Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)