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 <[EMAIL PROTECTED]> 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.
