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

Re: slapd high CPU usage

You mean to say that debug to the console is cheaper than debug to syslog()? That's quite likely, especially since many syslog implementations sync on each message (very expensive). Look into syslog()ing remotely, and/or using the "-" syslog.conf option if it is available (Linux in particular). And of course -1 is a REALLY expensive debug (almost certainly more than you need in this case); dumping out packet encoding takes a lot of time.

On Tue, 16 Oct 2007, Angie Cao wrote:

I had an eq index set on the entryCSN.
Weird part is since syslogd will be very busy at logging slapd (even
using more cpu than slapd itself) with "loglevel -1" in slapd.conf, so
I run "slapd -d127 -u ldap -h ldap:/// ldaps:///" trying to log more
info, it works like a charm!

Any ideas?

Angie

On 10/16/07, Aaron Richton <richton@nbcs.rutgers.edu> wrote: 
If you're not sure if those logs are related, perhaps you should run
"date" when things get slow and find the relevant debug logs that way?


I didn't see any smoking gun in what you posted, but since you're posting
about "slow" with a log describing filter processing I'd look into
unindexed searches. You're using syncrepl, so hopefully you read in the
slapo-syncprov man page

    On databases that support inequality indexing, it is helpful
    to set an eq index on the entryCSN attribute when using this
    overlay.


and followed that advice? If you added indices, did you run slapindex
after stopping slapd? Look for messages along the lines of

<= bdb_equality_candidates: (FOO) not indexed

in your logs.