X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=rhHFCOC/mtV9P8tFlYpDKlw838AS8
	paQx56NxwLc080gVeFAgNwHUcqDXuT+i87CaSSoY8Ud//1chrXwf3omr7NhEvot2
	62YRNATl6LYIWFv4Mijz9ugBssYNyEIXvaaYm9ZET2yUZ9k1kh6KS45C3a4jgegI
	YimPsmV6SPRQys=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=R/U3ZcPNkPKceBEaHfpdJ0kDMqc=; b=wUQ
	U54fYzuPbtaiQf1l8TSU4P80hVCqkAebVCc54YfWtzS4OgnPSS7oyPMvzkKYeFtx
	U46jH6F2Nx8uwaScIjZFiBkCdx2/iBCC4thR46mQAHa2EDYR2f/tKyaQU2HHl/PT
	oZH/7mMk0eT/+ycOZbBco0ZFOjmOJQS6Qlox94Vc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.0 required=5.0 tests=AWL,BAYES_05,KAM_COUK,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2
X-HELO:	smtp.demon.co.uk
From:	Roger Orr <rogero AT howzatt DOT demon DOT co DOT uk>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	RE: slow startup after upgrade
Date:	Thu, 19 Feb 2015 11:53:26 +0000
Message-ID:	<7011F01FD056AE4083D6B2DBB3F2DAFF280C9DD6@EXMBX16.thus.corp>
References:	<20150216210132 DOT GM8493 AT calimero DOT vinschen DOT de> <7C9A9F7AB74D423499279676D7FA905A AT Tamar> <20150217213255 DOT GC4340 AT calimero DOT vinschen DOT de>,<20150218111802 DOT GM8493 AT calimero DOT vinschen DOT de>,<7011F01FD056AE4083D6B2DBB3F2DAFF280C9A5E AT EXMBX16 DOT thus DOT corp>
In-Reply-To:	<7011F01FD056AE4083D6B2DBB3F2DAFF280C9A5E@EXMBX16.thus.corp>
MIME-Version:	1.0
X-MDF-HostID:	2
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id t1JBtO3p017220

I've tested again with the first patched cygwin1.dll:
CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35(0.286/5/3) 2015-02-16 13:18 i686 Cygwin

I can confirm the connections are occurring within the ldap_search_s call - here is one of the call stacks:

00ebc31c 76e5c451 00000278 0045dd28 00000010 WS2_32!connect (FPO: [Non-Fpo])
00ebc87c 76e5cad5 00462758 00ebc8a4 00000185 wldap32!LdapParallelConnect+0x2e3 (FPO: [Non-Fpo])
00ebca70 76e597a2 00462758 004568a0 00000000 wldap32!ConnectToSRVrecs+0x21b (FPO: [Non-Fpo])
00ebcac8 76e59688 00000000 00000000 00462758 wldap32!OpenLdapServer+0x612 (FPO: [Non-Fpo])
00ebcae8 76e62ca9 00462758 00000000 00000000 wldap32!LdapConnect+0x2cf (FPO: [Non-Fpo])
00ebcb58 76e63021 00432670 00000000 76e8e158 wldap32!LdapChaseReferral+0xb27 (FPO: [Non-Fpo])
00ebcb98 76e62e1d 0042ca00 004328b0 00432670 wldap32!HandleReferral+0x7ac (FPO: [Non-Fpo])
00ebcbd4 76e553e2 0042cab8 00ebcc04 00000000 wldap32!HandleReferrals+0x151 (FPO: [Non-Fpo])
00ebcc08 76e5b0f8 0042cab8 00000005 00000001 wldap32!ldap_result_with_error+0x30e (FPO: [Non-Fpo])
00ebcc3c 76e5e584 0042cce4 80039620 00000002 wldap32!ldap_search_ext_sW+0x87 (FPO: [Non-Fpo])
00ebcc80 76e5e783 0042cce4 80039620 00000002 wldap32!ldap_search_stW+0x45 (FPO: [Non-Fpo])
00ebcca8 610818e2 0042cce4 80039620 00000002 wldap32!ldap_search_sW+0x21 (FPO: [Non-Fpo])

I can see this occurring with "ldp.exe" (from Windows Server 2003 support tools; also works on newer version of windows) and "netstat.exe"

Connection->Connect (default server, default port 389)
(1 TCP/IP session to DC1:389)

Connection->Bind (enter username and password)
(no new sessions)

Browse->Search

Base Dn - first naming context
Filter: (&(objectClass=trustedDomain)(name=wibble))
Gets 0 entries, quickly, no extra sessions visible


Click 'Options'
Select 'Chase Referrals'
Click Ok

Search again.
Gets 0 entries, takes some seconds, and establishes nuermous TCP/IP connections.

(1) LDAP_OPT_REFERRALS is on by default
(2) The fix added CN=System to the Base Dn - this seems to turn off referrals

--
*aside*
Sysinternals "ADInsight" is a 32bit only tool and, in order to work on a 64bit Windows you seem to have to manually inject the DLL ADInsightDll.dll (which is extracted into %TEMP%) into the target (32-bit!) process.

Regards,
Roger.

________________________________________
From: Roger Orr
Sent: 18 February 2015 11:26
To: Corinna Vinschen
Cc: cygwin AT cygwin DOT com
Subject: RE: slow startup after upgrade

Hello Corinna,

I've just been trying out both the 2015-02-18 10:30:19/44 UTC and 2015-02-17 21:27:23/48 UTC patches.

Both are now down to the same timings as with a 'files' entry in /etc/nsswitch.cfg, (and there's no detectable speed difference between them.)

The scope restriction in the second query to \System reduces the query time to 1.1 - 1.3 ms (was 4 seconds) and also it no longer opens 14 TCP/IP sessions to various ldap servers around the planet (!)

I note that mkpasswd and mkgroup do still open many sessions to the ldap servers, but that may be inevitable. It's not an issue directly, of course, since I'll no longer need to make use of these, but it perhaps might indicate another place where the ldap queries are sub-optimal.

Thanks for your rapid response on this issue!
Regards,
Roger.
________________________________________
From: Corinna Vinschen [corinna-cygwin AT cygwin DOT com]
Sent: 18 February 2015 11:18
To: cygwin AT cygwin DOT com
Cc: Roger Orr
Subject: Re: slow startup after upgrade

Hi Roger,

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

I just release a new test release, 1.7.35-0.3, see
https://cygwin.com/ml/cygwin-announce/2015-02/msg00133.html

This should speed up the search for the trustedDomain info a lot.

Can you please give it a try and perform your fantastic timing test as
above?


Thanks in advance,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -