[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldap] slapd eating CPU after query returning many matches


Thanks, I've forward it to the development list for discussion.


Tom Ivar Helbekkmo wrote:
> I wrote:
> > I'm thinking either a select() problem, or a bug related to the fact
> > that I'm running it on a system with no threads -- probably the
> > former.
> Gee, I'm good at this.  ;-)  It turned out to be select() returning
> immediately, because running without threads shows up a problem with
> the handling of the "active_threads" counter in slapd.
> In the function send_search_entry() in result.c, the call to
> ber_flush() fails many times in the course of the shipping out of a
> large number of matches, each time with an EAGAIN.  This causes
> active_threads to be decremented each time, so it ends up with a
> large, negative value.  Over in daemon.c, the non-zero value of
> active_threads causes select() to be called with a zero timeout.
> Unfortunately, just adding a test for > 0 to the decrementing did not
> fix it, because active_threads then ends up with the value 1 after the
> large transaction.  I haven't tried to figure out why, I've only done
> the following to daemon.c:
> Index: daemon.c
> ===================================================================
> RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/daemon.c,v
> retrieving revision 1.11
> diff -r1.11 daemon.c
> 222c222
> ---
> > #if defined(PTHREAD_PREEMPTIVE) || defined(NO_THREADS)
> This causes a NULL value to be used for the timeout parameter to
> select() every time, which is what we want when running without
> threads anyway.  Of course, this is not necessarily a real fix: the
> fact that the problem occurs may indicate that there is a flaw in the
> logic around active_threads that could cause problems even when the
> code is built with a threads library, given the right circumstances.
> Works for me, though.  :-)
> -tih
> --
> Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"