DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=r64U1xIJFLqjN3vO/GJ0Cr1a6RT3azDKgT0+RuhkJj707gqJ8sdvN
	bIlzi2FoPa7fsBhbdps6OpXIYSzIcSk85E+xHe6teR9lQebggEd4A7/DOnVoNUpE
	GPphHp5RLvotOMSadJS6pxMYPFDRWPTbmMMVuYGifEeu+z88IcJkp4=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Tue, 17 Feb 2015 22:32:55 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: slow startup after upgrade
Message-ID: <20150217213255.GC4340@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20150216210132 DOT GM8493 AT calimero DOT vinschen DOT de> <7C9A9F7AB74D423499279676D7FA905A AT Tamar>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="RIYY1s2vRbPFwWeW"
Content-Disposition: inline
In-Reply-To: <7C9A9F7AB74D423499279676D7FA905A@Tamar>
User-Agent: Mutt/1.5.23 (2014-03-12)

--RIYY1s2vRbPFwWeW
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?!?=20=20=20
> >=20
> > Are you remote from your DC, by any chance?
>=20
> I have made some progress with analysis (slightly handicapped as I'm a
> novice with ldap and am not an admin)
>=20
> According to nltest /dclist:
> Our environment has 6 London based DCs=20
>=20
> According to ldp.exe Live Enterprise Tree we have a tree structure for LD=
AP.
>=20
> 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.
>=20
> When running mkpasswd I see active sessions to all the nodes in the tree =
on
> port 389 (ldap)
>=20
> I have tried using Sysinternals ADInsight (with a 32bit cygwin) to see wh=
at
> requests are made with 'echo.exe'
>=20
> There are two searches shown:
>=20
> A) RootDSE:LDAP_SCOPE_BASE:(objectclass=3D*)  (1.113ms)
> B) <London DNS>:LDAP_SCOPE_SUBTREE:((objectClass=3DtrustedDomain) AND
> (name=3D<Australian DNS>))     (4.426s)
>=20
> I don't know why the second query is being made with the Australian DNS n=
ame
> 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

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

--RIYY1s2vRbPFwWeW
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU47OHAAoJEPU2Bp2uRE+gBLUP/2SQt+obOwotLjEMwQECiX2C
As31vTSIzox0Cepseh17oYd88Ok3ac8CGec4j39YXekr9svkiZYSk4RtW0lGtHDV
f8XwEF7HopgAbh0UvFkfNI7bH2J365xT1rV/9e+mDt3y1F77k96gNIjUqmjthYU/
5ZMXhyOyC8c6TFDX+YfO53ayrfljU9tz/nIhDIMTIp1ydr3EJ1wJfsr6itnYc37P
sBHCv+79tt3vFBdAvsyBeOxJqZbRH5aFLKdyVJgBVWVRV1aj8K5XpwlVKkYFaehs
Uf1fchZC+BAAOn7YPAmdPbnlkuKPAnp5Q6Dm23BZZy/6GCIZMpFje/I1iTUFSgth
I65wt/1g6KrSLJ8+9GMJAzR6CLv+AvV/gT79RutQfutHfPjQ63bKbzxQoQ7zQ9er
ElX7UNBRclBpFY1uQIKmW7ppOkKeL94FYqK5BEqkQdDxCg6ILHdyhDtml63rCElz
cpxE0gDFIVIAWsuDdpxYxSaRzL9fWXfc7SKM+XHcxLueLvFLAIM/DJk5vYLAJtaK
+gFWwXAnKB5SM3WVtsD6RgijotHOfo6b6Ja55uu9fXGAaXS8NBmcb4fvs4wjPzRM
lgODoYhwKdH+/Vs8Kxpn++L+Tv19H/81rG9QsNzz9agIdIXZSBNSkkCS24W2MMkV
OmMwepyctMcm4oxC7b4W
=eqMo
-----END PGP SIGNATURE-----

--RIYY1s2vRbPFwWeW--