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


Hi Roger,

On Feb 17 19:13, Roger Orr wrote:
> Corinna Vinschen wrote:
> > 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.

Thanks for doing that!  It's really cool to get this info since it seems
to point to the culprit.

It's not the problem that the Australian DNS is mentioned here.  This is
perfectly valid.  The LDAP query is going to the London DNS DC
(apparently, I hope that's right in your case) and the query is for
information on a trusted domain.  It looks like you have a group from
the australian domain in your user token.  To compute the gid of the
group, cygwin asks *your* DC for a value called "posixOffset" for *that*
trusted domain.

The bottom line is, this is not going to Australia, because all DCs have
this info for their trusted domains in their own DB so it's a planly
local query.

However, that mean this local LDAP query is *extremly* slow.  I changed
the query now to limit the scope of the database search.  This should speed
up the request a lot.

I've just built a new developer snapshot and uploaded it to
https://cygwin.com/snapshots/  The latest one is it.  Just replacing
the Cygwin DLL is sufficient for this.  Can you please run the above
timing test again with the developer snapshot DLL, please?

On second thought, there's another screw I could use to speed up this
specific LDAP query even more, but I won't be able to come up with the
change today anymore.  I'm going to provide another developer snapshot
tomorrow for another test, ok?  It would be very helpful probably if we
can get this trustedDomain query into the millisecond area as well.


Idle musing:  It's apparently quite a difference between a real-world
AD and the funny little AD I'm using for testing at home...


Thanks a lot,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgp7Uvh4Hn2C4.pgp
Description: PGP signature


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