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 k5cduszzvlv2jv4k6d7yk6lec37rnk5l37jl56376vamaw6bpd@giopefhr2ffh
обсуждение исходный текст
Ответ на Re: 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
Re: libpq contention due to gss even when not using gss
Список pgsql-hackers
> On Thu, Jun 13, 2024 at 10:30:24AM GMT, Andres Freund wrote:
> > > 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?
>
> Yes, the latter. Or not having kerberos set up on the client side.

I've been experimenting with both:

* The server is built without gssapi, but the client does support it.
  This produces exactly the contention you're talking about.

* The server is built with gssapi, but do not use it in pg_hba, the
  client does support gssapi. In this case the difference between
  gssencmode=disable/prefer is even more dramatic in my test case
  (milliseconds vs seconds) due to the environment with configured
  kerberos (for other purposes, thus gss_init_sec_context spends huge
  amount of time to still return nothing).

At the same time after quick look I don't see an easy way to avoid that.
Current implementation tries to initialize gss before getting any
confirmation from the server whether it's supported. Doing this other
way around would probably just shift overhead to the server side.



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

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: may be a buffer overflow problem
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Logical Replication of sequences