This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TEST RELEASE: Cygwin 1.7.35-0.3

Corinna Vinschen |cygwin_ml_nodigest| wrote at 12:17 +0100 on Feb 23, 2015:
 > On Feb 20 13:46, John Hein wrote:
 > > Corinna Vinschen wrote at 11:29 +0100 on Feb 20, 2015:
 > >  > So I just changed the order of the objectClass and objectCategory test.
 > >  > If that's really the culprit, you can easily test it:
 > >  >
 > >  > Revert to the Cygwin 1.7.34-6   DLL, run `time mkpasswd -d >/dev/null'
 > >  > Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null'
 > >  > Revert to the Cygwin 1.7.34-6   DLL, run `time mkpasswd -d >/dev/null'
 > >  > Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null'
 > >  >
 > >  > Does that clearly show that 1.7.34-6 is faster performing the enumeration?
 > >  > If so, and despite my total puzzlement, the order in the expression seem
 > >  > to have an effect.
 > >
 > >
 > > mkpasswd w/1.7.35-0.3 finally finished - took about 5+ hours and only
 > > returned ~1800 results instead of ~8000.
 > >
 > > mkpasswd w/1.7.33 took about 50 minutes.  This was mostly after peak
 > > business hours, however (not clear how much that matters).
 > >
 > > Trying 1.7.34-6 now.  Looks like it's going to be slow.  It's been
 > > two hours and only about 200 entries have trickled in.
 > >
 > > Slow going here.  Note this last run is under strace (see below), so
 > > not exactly what you suggested.  I'll try without strace and redirecting
 > > to /dev/null to see if it matters after this test finishes (if ever).
 > Come to think of it, it's probably really just slow.  The difference
 > between mkpasswd/mkgroup for domain accounts:
 > 1.7.33:
 >   Calls NetUserEnum/NetGroupEnum,NetLocalGroupEnum with maximum Buffer
 >   size.
 > 1.7.34+:
 >   Calls an LDAP enumerator fetching 100 SIDs per call.
 >   For each SID:
 >     Call LookupAccountSid.
 >     For each User:
 >       Depending on nsswitch.conf, call LDAP to fetch the extended passwd
 >       info (pw_shell, pw_home, pw_gecos).
 > I guess there's some room for improvement.
 > OTOH, keep in mind that you're not suppsoed to call mkpasswd/mkgroup
 > to enumerate your entire organization.  If you're using it at all, then
 > only to create the required entries in /etc/passwd and /etc/group for
 > your local acocunt to work, and then leave everything else to the "db"
 > setting.

Fair enough.  I'll stop stress testing mkpasswd and consider this
closed unless there's something we want to try.

But 1.7.33 seems much faster (if you can call 50 minutes fast) at it
than 1.7.34-6 or 1.7.35-0.3 in this large-ish AD.  Maybe a knob to
specify buffer size and/or some other knobs might help identifying the
slowest parts (and/or some stats).  Just a thought.

I'll add that the 1.7.34-6 'strace mkpasswd -d' that I had started
above finished in 20+ hours and spewed ~3500 of ~8000 entries.

Running 'time mkpasswd -d > /dev/null' under 1.7.35-0.3 is still
running 20 hours later.  No idea, of course, how much progress it has

p.s. Also seems to be some differences running things under strace or
not - seems like strace issues (time stamp oddness for one, strace -p
<pid> followed by ctrl-c of the strace seems to kill the running
proc).  That's a separate thread(s) for another time.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]