RE: Memory and CPU usage

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Timothy H Folks [mailto:Timothy.Folks@edgescape.com]
> > > As far as T.'s "(?=undefined)" goes, where are we at
> here? Where does
> > > the "(?=undefined)" come from? From your explanation, it
> could be easy
> > > to deduce why his configuration didn't work. Did the
> "(?=undefined)"
> > > have anything to do with it? It doesn't seem so, to me.
> >
> > This comes from trying to filter an attributeType that
> doesn't have a
> > matching rule defined. Thus, that element of the filter is
> undefined,
> and
> > doesn't contribute to the results of the search.
>
> That is not what was happening to my server. I have carefully
> rechecked my
> coded LDAP queries, and all search criteria are valid attributes. The
> "(?=undefined)" error would happen when slapd memory jumped
> to over 150 MB
> and CPU usage to 99-100%. The log would show that message
> repeating until
> I did a kill -9 on the process. Other queries would get
> through but much
> more slowly because the server kept looping on that
> "(?=undefined)" error.
>
> From what I can tell from your message, at worst, that message should only
> happen once for each query and not simply repeat forever like it did on
> mine. The message and the resource usage spike always happened
simulatanously.

OK, that is definitely suspicious. What log level do you normally run at?
What else do you see in the log right before this occurs? Copying us a
snippet from the log would probably be useful here. Attaching to the process
with gdb and getting the thread status (info threads) and back traces for
each thread would also be interesting. The first thing that really comes to
mind here is that you've received a malformed search request that has sent
the filter parser off into Never-Never land. Hard to imagine that triggering
a couple 100MB of mallocs though. The next thing that comes to mind is a
thread stack overwrite, which should never happen unless the pthread library
ignored the stack size we chose. (As I understand it, thread stack management
moved from glibc into the kernel in Linux 2.4, and I don't know what the new
limits are. It's a possibility, anyway.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support