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:in-reply-to:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=GTjMm2EkoOx9YZcCXULi73qq3oerJbrWuqt0cmm7Pl7nMokTsHNti
	Z94jtZ1zK7YzUl8QOzYP17N/KZPxYA/jyJkyxSP9Kb5TVESGgsIOKXxn2XtGuedJ
	1PkGhWm84hEHgbWCQvHh5zjnAHAp1uL1afq0WcyJbeuC7Dm68GFJ+M=
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
From: "Roger Orr" <rogero AT howzatt DOT demon DOT co DOT uk>
To: <cygwin AT cygwin DOT com>
In-Reply-To: <20150216210132.GM8493@calimero.vinschen.de>
Subject: RE: slow startup after upgrade
Date: Tue, 17 Feb 2015 19:13:43 -0000
Message-ID: <7C9A9F7AB74D423499279676D7FA905A@Tamar>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 8bit

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.

Regards,
Roger.


--
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