This is the mail archive of the
mailing list for the Cygwin project.
Re: slow startup after upgrade
- From: q2t2hzmwuk at snkmail dot com
- To: cygwin at cygwin dot com
- Date: Tue, 24 Feb 2015 16:03:57 -0700
- Subject: Re: slow startup after upgrade
- Authentication-results: sourceware.org; auth=none
- References: <3EA1D0B4CA4540DEB0782E6C1D038E3A at Tamar> <20150224211358 dot GO437 at calimero dot vinschen dot de>
Corinna Vinschen corinna-cygwin-at-cygwin.com |cygwin_ml_nodigest| 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 (well, maybe others, too).
I'm running it again, but it's still very slow, AFAICS. 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:
$ /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
.... and even if cygserver is not running:
$ getent group `id -G`
1 [main] getent 4120 C:\cygwin\bin\getent.exe: *** fatal error - Fetching account info from cygserver with wrong arg.type 2
The 1.7.35-0.3 cygwin dll didn't trigger those symptoms.
tcsh still taking a long time here (also XP - 3+ minutes with
cygserver running). bash & dash much quicker. Maybe something with
the tcsh hash table (tcsh -f is fast)? Doing 'env PATH=/bin tcsh'
helps some. strace shows lots of mount_info::conv_to_posix_path
calls when PATH is not trimmed.
Other times, I've seen stalls with 'db' in nsswitch.conf and no
cygserver like so every time a new child tcsh.exe is forked:
00:00:00 [main] tcsh 4388 child_info::sync: n 2, waiting for subproc_ready(0x6BC) and child process(0x680)
00:05:00 [main] tcsh 4388 child_info::sync: wait failed, pid 2556, Win32 error 0
Why it's forking a number of child tcsh's is not clear even after
looking through the .csh files in /etc/profile.d Ahh... it must be
complete.tcsh. Indeed - disabling that (by rename) helps a lot - lots
of back-tick commands in there.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple