Re: slow startup after upgrade

["John Hein" <3fbmqnhaz4 at snkmail dot com>]

John Hein wrote at 11:15 -0700 on Feb 25, 2015:
 > Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015:
 >  > On Feb 24 16:03, John Hein wrote:
 >  > > Corinna Vinschen wrote at 22:13 +0100 on Feb 24, 2015:
 >  > >  > Hi Roger,
 >  > >  >
 >  > >  > On Feb 24 19:55, Roger Orr wrote:
 >  > >  > > Hello Corinna,
 >  > >  > > It seems slightly faster than the previous patch and I've not noticed a
 >  > >  > > downside yet.
 >  > >  > >
 >  > >  > >
 >  > >  > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 i686
 >  > >  > > Cygwin:
 >  > >  > >
 >  > >  > > ~37ms to run echo.exe from Windows command prompt
 >  > >  > > ~60ms to run .\id.exe -a from Windows command prompt
 >  > >  > >
 >  > >  > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 i686
 >  > >  > > Cygwin:
 >  > >  > >
 >  > >  > > ~35ms to run echo.exe from Windows command prompt
 >  > >  > > ~53ms to run .\id.exe -a from Windows command prompt
 >  > >  >
 >  > >  > That's a nice result.
 >  > >  >
 >  > >  > However, I don't quite understand this result for the older DLL.
 >  > >  > Weren't you reporting >4 secs as startup time from 1.7.35?!?
 >  > >  >
 >  > >  > On another note:
 >  > >  >
 >  > >  > I just uploaded a new developer snapshot (2015-02-24).  This snapshot
 >  > >  > should improve mkpasswd/mkgroup or, generally speaking, enumerating AD
 >  > >  > accounts, a lot.  Can you give it a try?
 >  > >  >
 >  > >  > While you're at it, does the new snapshot still stop after 3.5K accounts
 >  > >  > even though you think there are 8K accounts?  If so, I'd be interested
 >  > >  > to investigate this further.  The reason is, while testing my today's
 >  > >  > performance improvements, I stumbled over a bug in my code which also
 >  > >  > resulted in enumerating less accounts as desired.  So I'm not entirely
 >  > >  > sure your problem isn't related to a bug either.
 >  > >
 >  > > That mkpasswd symptom was reported by me
 >  >
 >  > Really?  This is the first time I see your email address on this ML, and
 >  > there's no name connected to it, so I don't even know if you're usually
 >  > writing under another email address.  At least a forename would be nice...
 >
 >
 > Bah... sorry, you should get the name in this response.
 >
 >
 >  > > (well, maybe others, too).
 >  > > I'm running it again, but it's still very slow, AFAICS.
 >  >
 >  > It shouldn't.  It performs only one LDAP call now per 100 accounts,
 >  > If that's still slow in your environment, I don't see any way to
 >  > speed this up any further.
 >  >
 >  > > I'll report
 >  > > how long it took when / if it finishes.
 >  > >
 >  > > New issue with recent snaps:
 >  > >
 >  > > Running the 20150224 (and *23) snapshot produces the following on Win
 >  > > XP (yes, I know) if cygserver is running:
 >  >
 >  > Sidenote: I'm contemplating to stop supporting XP end of this year.
 >
 > I'm thinking it's either related to XP or _something_ with the
 > particular XP box I'm using (when logged in on the domain, I can't
 > disable many group policy things or temporarily inhibit AV, so it's
 > harder to find/eliminate something to pin blame on - certainly may not
 > be something the latest cygwin is doing when running on XP in a
 > "large" AD domain).
 >
 > I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33
 > seconds and enumerates all 8016 entries.  37 seconds with the 2/25
 > snap.
 >
 > And win 7 doesn't get the 'wrong arg.type' error with the same 2/24
 > cygwin1.dll for whatever reason.
 >
 >
 >  > > $ /usr/sbin/syslog-ng -F
 >  > >       1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** fatal error - Fetching account info from cygserver with wrong arg.type 2
 >  >
 >  > Try the snapshot I just uploaded (2015-02-25).  I forgot a tiny, but
 >  > crucial statement in the code when I changed that code two days ago.
 >  > That should be fixed now.
 >  >
 >  > > tcsh still taking a long time here (also XP - 3+ minutes with
 >  > > cygserver running).  bash & dash much quicker.
 >  >
 >  > Works very quickly for me.  Problem is, I don't know anything about
 >  > your environment.  Are you working remote or in an office?  How many
 >  > groups are in your user token?  What is the result of this funny
 >  > little statement Dennis created:
 >  >
 >  >   cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo !TIME!"
 >
 > On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time stamp
 >
 > That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs
 > running including cygserver.
 >
 >
 > On problematic winxp box:
 >     [passwd, group, db_shell: 'files db', 'files db' & /bin/dash]
 >       16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec
 >
 >     [passwd, group, db_shell: db, db & /bin/dash]
 >       23.51, 27.91, 28.78 sec
 >
 >     Any trials using /bin/tcsh without disabling complete.tcsh take "a
 >     really long time" (TM)... from minutes with 2/25 snap to 10s of
 >     minutes with 1.7.34.  I mentioned this in another thread (and
 >     strace sometimes showed 5 minute gaps around forks).


One further test with the 'cmd ... mintty.exe' command.
I started cygserver on the 'problematic winxp' box.

Then immediately ran the mintty.exe test after starting
the cygserver service - it took .08 sec - then .15 and .14.

Would be interesting if there are other people who could report on
experiences using 1.7.34 and later on XP boxes in an AD environment.

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