[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: slapd high CPU usage
Hello everyone,
Thanks for the kind advice. I was able to find the failure msg which
seemed to trick this problem by turning on "stat" debugging level, it
appears one of the index that specified in slapd.conf was not created,
so i recreated it and restart slapd, everything works as expected
now!!
Thanks again for the help, I appreciate it!
Angie
On 10/17/07, Aaron Richton <richton@nbcs.rutgers.edu> wrote:
> Please keep replies on the list.
>
> On Tue, 16 Oct 2007, Angie Cao wrote:
>
> > The high CPU problem happens when log level was not turned on (means
> > "loglevel 0" being set in slapd.conf)
>
> OK, so it's not (exclusively?) OpenLDAP logging that's causing your system
> to go slow.
>
> > Although CPU is running low right now (with slapd -d127), the message I saw is :
> >
> > => test_filter
> > AND
> > => test_filter_and
> > => test_filter
> > EQUALITY
> > AND
> > <= test_filter 5
> > => test_filter
> > AND
> > => test_filter_and
> > AND
> > => test_filter_and
> > => test_filter
> > EQUALITY
> > <= test_filter 5
> > <= test_filter_and 5
> > <= test_filter 5
> > bdb_search: 18222 does not match filter
> >
> > are all over the place.... Wondering if this might be related with
> > the high CPU problem and what this indicates about. (googling around
> > at the moment and hopefully find the hints)
> >
> > Angie
> >
>
> As recommended, try and find a debug level that's more appropriate --
> "stats" might be good. These searches that you're concerned about will
> come up in a much easier to parse form:
>
> conn=2 op=1 SRCH base="ou=Dynamic Lists,dc=example,dc=com" scope=2 deref=0 filter="(cn=dynamic list)"
> conn=2 op=1 SRCH attr=*
> conn=2 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
>
> If you find one of these that's slow (and yes, this might be as low-tech
> as just noting that there's a large time between debug messages being
> printed), then that might be a good place to start looking. This data also
> gives you enough that you can (more or less) replicate the search with
> ldapsearch(1). If you can do that yourself (instead of waiting for clients
> to beat slapd up) and find options that gun the CPU, you're a lot closer
> to fixing the issue...
>