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

OpenLDAP Search bug?



I have done a little more research on this problem (found in the email
below) and have found a few more interesting notes...

I tried rebuilding the entire database with the following indices:
index           ou,o            eq
index           uid,myorgdn,myorgroot,myorgsn              eq
index           objectclass             eq

I am still seeing a 4 second delay in the middle of receiving search result
data from the openldap, right before the last 14 bytes are sent (why is it
always 14 bytes?).

The interesting thing I found is when I move up one level in the tree and
try the same query over ALL users, I receive about 50 times as many entries
and the query is faster!!!  How could that possibly be?  Here are the two
queries:

This one searches below one user (which only has 10 entries below it) and
takes about 4-5 seconds:

conn=8 op=27 SRCH
base="uid=6225183,ou=People,o=myorg,myorgroot=top,o=myorg.com" scope=1
filter="(objectClass=myorgservice)"
ber_flush: 629 bytes to sd 28
ber_flush: 521 bytes to sd 28
ber_flush: 543 bytes to sd 28
ber_flush: 520 bytes to sd 28
ber_flush: 524 bytes to sd 28
ber_flush: 532 bytes to sd 28
ber_flush: 534 bytes to sd 28
ber_flush: 524 bytes to sd 28
ber_flush: 559 bytes to sd 28
ber_flush: 526 bytes to sd 28

<<4 second pause>>

ber_flush: 14 bytes to sd 28
conn=8 op=27 SEARCH RESULT tag=101 err=0 nentries=10 text=

This next one has the same filter, but searches through ALL users (one level
up in the tree) and runs instantaneously:

conn=5 op=51 SRCH base="ou=People,o=myorg,myorgroot=top,o=myorg.com" scope=2
filter="(objectClass=myorgservice)"
ber_flush: 117 bytes to sd 11
ber_flush: 129 bytes to sd 11
ber_flush: 128 bytes to sd 11
ber_flush: 145 bytes to sd 11
ber_flush: 119 bytes to sd 11
ber_flush: 123 bytes to sd 11
...
<<ommited hundreds of similar lines>>
...
ber_flush: 14 bytes to sd 11
conn=5 op=51 SEARCH RESULT tag=101 err=0 nentries=521 text=

I can't see how this could be anything other than a bug in the search
routines.  Has anyone else experienced this?  I can only reproduce it when
searching by (objectclass=somevalue).  If I do (objectclass=*) it runs
instantly and if I use a value for objectclass that doesn't exist, it is
also instantaneous.  I have also tried the same query at other levels of the
tree.  I only see this problem at this particular level, and then only when
i search by objectclass.

Please help me!!! I am about to pull out my hair!!

Thanks,
Andy Hofle

----- Original Message -----
From: "Banzaitron" <banzaitron@adelphia.net>
To: <openldap-software@OpenLDAP.org>
Sent: Thursday, September 05, 2002 10:20 AM
Subject: Very strange search performance problem...


> Hello,
> I have finally gotten to the point of migrating our iPlanet directory to
the
> openldap (thanks to help from this list) and being able to run our
> applications against the new LDAP.  I am seeing a very strange behavior
with
> searches.  For example, when I start a query, I see the following in the
> LDAP log output:
>
> conn=2 op=50 SRCH
> base="uid=6225183,ou=People,o=myorg,myorgroot=top,o=myorg.com" scope=1
> filter="(objectClass=myorgservice)"
> ber_flush: 629 bytes to sd 13
> ber_flush: 521 bytes to sd 13
> ber_flush: 543 bytes to sd 13
> ber_flush: 520 bytes to sd 13
> ber_flush: 524 bytes to sd 13
> ber_flush: 532 bytes to sd 13
> ber_flush: 534 bytes to sd 13
> ber_flush: 524 bytes to sd 13
> ber_flush: 559 bytes to sd 13
> ber_flush: 526 bytes to sd 13
>
> ****3-4 second pause****   <-----------------------
>
> ber_flush: 14 bytes to sd 13
> conn=2 op=50 SEARCH RESULT tag=101 err=0 nentries=10 text=
>
> There is ALWAYS a long delay before the last 14 bytes are flushed.
> Obviously, this is causing poor application performance due to the large
> number of queries of this type.  When I run the same query from a simple
> LDAP browser, it does the same thing (long pause).  However, when I change
> the filter from(objectClass=myorgservice) to (objectClass=*) it runs
> instantly.  I assume this is some indexing problem, but I have an
> objectClass index in my slapd.conf:
>
> # Indices to maintain
> index   objectClass     eq
>
> Also, there are very few entries under this DN so even if it was an
indexing
> problem, I can't imagine why it would be taking so long to search the 5 or
6
> entries under that UID.  Any idea how I can improve this situation?  I'm a
> little new to LDAP indices -- are there any others that I should
definitely
> have turned on by default?
>
> Thanks alot,
> Andy Hofle
>
>