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.