This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: slow startup after upgrade

Corinna Vinschen wrote:
> On Feb 16 20:02, Roger Orr wrote:
>> Corinna Vinschen wrote:
>>> So I'd think the best way forward is to update to the
>>> 1.7.35-0.1 test release and report further from there.
>> Thanks, this does help a little. However I will still be using the
>> 'files' setting.
> The idea was to test this stuff to find a better solution which is
> acceptable.  If you simply revert to "files" without helping to test
> we'll probably never find the culprit.  

I'm very happy to continue testing; I was merely meaning the 1.7.35
performance is still not adequate in my environment.

> It would be nice to know what part of the code is so slow.  The
> LookupAccountSid calls shouldn't be so slow because they only fetch
> information already cached on the local machine.  So it's probably
> the LDAP call.  Why does an LDAP call take 4 secs?!?   
> Are you remote from your DC, by any chance?

I have made some progress with analysis (slightly handicapped as I'm a
novice with ldap and am not an admin)

According to nltest /dclist:
Our environment has 6 London based DCs 

According to ldp.exe Live Enterprise Tree we have a tree structure for LDAP.

6 leaf nodes at the top matching ther 6 DCs
4 leaf nodes under an "AUS" (Australia) node
3 leaf nodes under a "CHI" (Chicago) node
and a few more similar to this in other regions.

When running mkpasswd I see active sessions to all the nodes in the tree on
port 389 (ldap)

I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see what
requests are made with 'echo.exe'

There are two searches shown:

A) RootDSE:LDAP_SCOPE_BASE:(objectclass=*)  (1.113ms)
B) <London DNS>:LDAP_SCOPE_SUBTREE:((objectClass=trustedDomain) AND
(name=<Australian DNS>))     (4.426s)

I don't know why the second query is being made with the Australian DNS name
but I suspect this is the problem.
(Perhaps it as simple as A coming first in the alphabet ...)

Happy to investigate further if someone can suggest some useful avenues.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]