Re: LDAP authentication slow

From: Tim Cross <theophilusx(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: C GG <cgg0007(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: LDAP authentication slow
Date: 2018-06-03 21:55:45
Message-ID: 87y3fvilge.fsf@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:

> On Thu, May 31, 2018 at 8:23 AM, C GG <cgg0007(at)gmail(dot)com> wrote:
>
> In the meantime, I did what I promised Adrian Klaver I would do and I added
>> the AD servers to the /etc/hosts file. That had an immediate and dramatic
>> effect on the performance. That confirms (at least to me) that DNS
>> resolution was playing a large part in the slowdown. I'm going to
>> experiment with running a local DNS caching server to see if that will give
>> the same effect.
>>
>
> I had this problem at one site, and with the same solution. As best as I
> could tell, Windows was not using DNS as the main way of resolving
> hostnames. (People assure me that NetBIOS and WINS are almost completely
> dead, but WireShark tells a different tail--I don't recall the exact name,
> but it was certainly something other than DNS). So the fact that AD's
> built in DNS sucks was not a problem for Windows users, which means there
> was no impetus on the Windows admin to fix it. And the delay on resolution
> was always 5 seconds plus a very small handful of milliseconds. So it was
> clearly some kind of designed throttling or timeout, there is no way random
> congestion could get you so close to 5.00 every time.
>

We had particular problems with a specific client. In the end, it turned
out that this client used a DNS resolve library which, unlike most other
libraries, did not use local DNS cache. Every name lookup involved a
full DNS resolution process. Temporary solution was to use IP addresses
until admins/devs could work out how to fix the client or find a more
robust solution where address isn't 'hard coded'.

At the time, the admins responsible for managing the DNS were getting
frustrated as their service was being blamed for a local client
problem.

Key take away, this stuff can be complex to diagnose and a systematic
evidence based investigation is often required - problem is, that takes
time and is seldom welcomed.

--
Tim Cross

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2018-06-03 21:58:12 Re: Code of Conduct plan
Previous Message Berend Tober 2018-06-03 21:54:16 Re: Code of Conduct plan