| From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net>, Robbie Harwood <rharwood(at)redhat(dot)com> |
| Subject: | Re: libpq contention due to gss even when not using gss |
| Date: | 2024-06-13 15:33:57 |
| Message-ID: | paw37ffzcdynl5i5lp7rdkkulbdqht6i5okro2q42nf5kft4mb@eo227nurgo5x |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2024-06-13 15:37:00 | Re: jsonpath: Missing Binary Execution Path? |
| Previous Message | David E. Wheeler | 2024-06-13 15:32:38 | jsonpath: Missing Binary Execution Path? |