Re: libpq contention due to gss even when not using gss
От | Dmitry Dolgov |
---|---|
Тема | Re: libpq contention due to gss even when not using gss |
Дата | |
Msg-id | paw37ffzcdynl5i5lp7rdkkulbdqht6i5okro2q42nf5kft4mb@eo227nurgo5x обсуждение исходный текст |
Ответ на | libpq contention due to gss even when not using gss (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: libpq contention due to gss even when not using gss
|
Список | pgsql-hackers |
> On Mon, Jun 10, 2024 at 11:12:12AM GMT, Andres Freund wrote: > Hi, > > To investigate a report of both postgres and pgbouncer having issues when a > lot of new connections aree established, I used pgbench -C. Oddly, on an > early attempt, the bottleneck wasn't postgres+pgbouncer, it was pgbench. But > only when using TCP, not with unix sockets. > > c=40;pgbench -C -n -c$c -j$c -T5 -f <(echo 'select 1') 'port=6432 host=127.0.0.1 user=test dbname=postgres password=fake' > > host=127.0.0.1: 16465 > host=127.0.0.1,gssencmode=disable 20860 > host=/tmp: 49286 > > Note that the server does *not* support gss, yet gss has a substantial > performance impact. > > Obviously the connection rates here absurdly high and outside of badly written > applications likely never practically relevant. However, the number of cores > in systems are going up, and this quite possibly will become relevant in more > realistic scenarios (lock contention kicks in earlier the more cores you > have). By not supporting gss I assume you mean having built with --with-gssapi, but only host (not hostgssenc) records in pg_hba, right?
В списке pgsql-hackers по дате отправления: