Laurenz writes:
> On Tue, 2020-08-18 at 14:53 +0200, Adam Sjøgren wrote:
>>
>> We have 60 processes (workers) running on different machines accessing
>> the database, that all grab jobs from a queue and update rows in a table
>> after doing some calculations (which vary in time from <1s to perhaps a
>> minute, many of them fast).
>>
>> Sometimes new database logins slow down, from usually taking <0.05s to
>> taking minutes. This is for psql as a normal user using Kerberos, for
>> psql as the postgres superuser, for the web-application logging into the
>> database, for everything.
>
> I would suspect that the problem is with the authentication method.
Interesting, how are you suspecting the interaction to be playing out?
> How is authenticatoin configured?
Primarily using gss (for the web-application, delegated credentials),
md5 (system users), and a few trust (for legacy access).
> I'd "strace" a connection that is hanging in "authenticating" and
> see what the process does.
I did that one of the previous times I have seen this problem, and saw
stuff like this:
2020-06-10 11:22:14 strace: Process 101559 attached
2020-06-10 11:22:14 futex(0x7f46df29e138, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0
...
2020-06-10 11:24:09 futex(0x7f46df29e138, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, ffffffff) = 0
2020-06-10 11:24:09 futex(0x7f46df2a2e38, FUTEX_WAKE, 1) = 1
2020-06-10 11:24:09 brk(0x55c197084000) = 0x55c197084000
2020-06-10 11:24:09 brk(0x55c1970b0000) = 0x55c1970b0000
2020-06-10 11:24:09 open("global/pg_filenode.map", O_RDONLY) = 6
(where the elided part is futex() calls).
The slow login is regardless of whether I login with Kerberos or as the
postgres superuser with psql.
Best regards,
Adam
--
"Sometimes I feel like going home, walking in the Adam Sjøgren
boardroom asjo@xxxxxxxxxxxx
Sometimes I feel like I wanna go, walk into the
ballroom"
