Hello Howard, Quanah

Thanks for your help,it seems the workaround to increase the values helped:

What i did was to modify file servers/slapd/back-bdb/idl.h

#define BDB_IDL_LOGN 16 /* DB_SIZE is 2^16, UM_SIZE is 2^17 */

#define BDB_IDL_DB_SIZE (1<<(BDB_IDL_LOGN+1)) /* 64k => 128K */ #define BDB_IDL_UM_SIZE (1<<(BDB_IDL_LOGN+2)) /* 128k => 256k */

and recompile....after that, i recreated the DB from ldif and added some extra entries using ldapadd. The search returned all entries within a reasonable time ( 23 - 50 seconds).

# search result search: 2 result: 0 Success

# numResponses: 84256 # numEntries: 84255

real 0m35.044s user 0m1.521s sys 0m1.654s

T.

On Fri, Sep 18, 2009 at 8:45 AM, Howard Chu hyc@symas.com wrote:

Tihomir Culjaga wrote:

...

the search:

ldapsearch -h localhost -x -b ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr -D cn=admin,dc=ot,dc=hr -w passwd objectClass=originatorPrefixID

This was essential information; previously you led us to believe you were doing a simple search with no filter (defaulting to "(objectclass=*)"). If you don't provide accurate descriptions of what you're doing, you cannot expect to get correct analysis of your situation.

You have run into an architectural limitation of the back-bdb/hdb indexing mechanism. This problem is described in ITS#3343

http://www.openldap.org/its/index.cgi?findid=3343

with some solutions discussed in

http://www.openldap.org/lists/openldap-devel/200503/msg00012.html

and http://www.openldap.org/lists/openldap-devel/200810/msg00095.html

but no final decisions have been made yet on the ultimate solution. Each approach has different limitations and tradeoffs to consider...

slapd.conf:

...

# Indices to maintain index objectClass eq index uniqueID eq index bestMatchPrefix eq index originatorPrefixID eq

according to schema i have

ou=ou=sipDirektor | --------- ou=bestMatchPrefixList | ----------- bestMatchPrefix=<PREFIX>

     |

     ------------------carrierPrefixID=<CARRIER_ID>

                                                  |


    ----------------originatorPrefixID=<ORIGIN_CARRIER_PREFIX>

here is an example of returned data:

# 041020, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=041020,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 041020 priority: 100 originator: 041020 originatorPrefixID: 041020 objectClass: top objectClass: originatorPrefixID

# 049010, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=049010,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 049010 priority: 100 originator: 049010 originatorPrefixID: 049010 objectClass: top objectClass: originatorPrefixID

# 046010, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=046010,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 046010 priority: 100 originator: 046010 originatorPrefixID: 046010 objectClass: top objectClass: originatorPrefixID

# 049020, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=049020,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 049020 priority: 100 originator: 049020 originatorPrefixID: 049020 objectClass: top objectClass: originatorPrefixID

# 078120, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=078120,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 078120 priority: 100 originator: 078120 originatorPrefixID: 078120 objectClass: top objectClass: originatorPrefixID

# 043010, 078120.100.10000.90, 1251, bestMatchPrefixList, sipDirektor, ot.hr http://ot.hr dn: originatorPrefixID=043010,carrierPrefixID=078120.100.10000.90,bestMatchPre fix=1251,ou=bestMatchPrefixList,ou=sipDirektor,dc=ot,dc=hr originatorPrefix: 043010 priority: 100 originator: 043010 originatorPrefixID: 043010 objectClass: top objectClass: originatorPrefixID

Tihomir.

On Fri, Sep 18, 2009 at 12:33 AM, Quanah Gibson-Mount <quanah@zimbra.com mailto:quanah@zimbra.com> wrote:

--On Thursday, September 17, 2009 12:26 PM -0700 Quanah Gibson-Mount <quanah@zimbra.com mailto:quanah@zimbra.com> wrote:

   --On Thursday, September 17, 2009 9:23 PM +0200 Tihomir Culjaga
   <tculjaga@gmail.com <mailto:tculjaga@gmail.com>> wrote:

       so, can anyone help here ?


       On Tue, Sep 15, 2009 at 8:34 PM, Tihomir Culjaga
       <tculjaga@gmail.com <mailto:tculjaga@gmail.com>>
       wrote:

       ok .. but the basic issue is still there ...

       i do a complete search and it hangs right on the 1st entry i
       added with
       LDAP search ... it watis for 1 minute ...and at the end
       returns all 4
       remaining entries...

Can you better define the search you are running? Is it a search for particular attr=value string? If so, is that attribute indexed?

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc

---

Zimbra :: the leader in open source messaging and collaboration

-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/