[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP Search bug?
I ran with debugging set to -1 (all debugging info) and to my horror, it
looks like OpenLDAP is searching EVERY ENTRY in the entire tree,
disregarding my search scope and start DN. It looks like it searched the
proper scope first (hence the first few chunks of bytes of data being
returned), and then proceeded to search the rest of the tree, then returning
the 14 bytes (some type of search close operation I'm guessing). Definitely
smells like some kind of bug to me. This only occurs at certain places in
the tree, and I haven't found any ryhme or reason as to where it happens.
Sometimes the exact same query runs perfectly in another tree branch. I'm
using the latest version (2.1.4) from the downloads page. I will look into
trying an alpha version as you suggested.
Andy
----- Original Message -----
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
To: "Banzaitron" <banzaitron@adelphia.net>
Cc: <openldap-software@OpenLDAP.org>
Sent: Friday, September 06, 2002 4:00 PM
Subject: Re: OpenLDAP Search bug?
> A couple of things to try:
>
> a) stop server, run slapindex, restart server
> b) more logging... to determine what slapd is doing
> for those 4-5 seconds
> c) try the latest release engineering version
> (OPENLDAP_REL_ENG_2_1 or OPENLDAP_REL_ENG_2) of
> OpenLDAP from CVS.
>
> Kurt
>
> At 09:13 AM 2002-09-06, Banzaitron wrote:
> >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
> >>
> >>
>