From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: libpq contention due to gss even when not using gss |
Date: | 2024-06-13 17:30:24 |
Message-ID: | 20240613173024.zdz5xb3v6h6pgzhw@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2024-06-13 17:33:57 +0200, Dmitry Dolgov wrote:
> > 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?
Yes, the latter. Or not having kerberos set up on the client side.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-06-13 17:47:53 | Re: RFC: adding pytest as a supported test framework |
Previous Message | Jelte Fennema-Nio | 2024-06-13 17:28:00 | Re: RFC: adding pytest as a supported test framework |