Re: libpq contention due to gss even when not using gss - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: libpq contention due to gss even when not using gss
Date
Msg-id k5cduszzvlv2jv4k6d7yk6lec37rnk5l37jl56376vamaw6bpd@giopefhr2ffh
Whole thread Raw
In response to Re: libpq contention due to gss even when not using gss  (Andres Freund <andres@anarazel.de>)
Responses Re: libpq contention due to gss even when not using gss
Re: libpq contention due to gss even when not using gss
List 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 by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: may be a buffer overflow problem
Next
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences