This is the mail archive of the
mailing list for the Cygwin project.
RE: slow startup after upgrade
- From: "Roger Orr" <rogero at howzatt dot demon dot co dot uk>
- To: <cygwin at cygwin dot com>
- Date: Tue, 17 Feb 2015 19:13:43 -0000
- Subject: RE: slow startup after upgrade
- Authentication-results: sourceware.org; auth=none
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: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple