[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Searches are slow *with* Indexes
Hi folks,
I hope one of you can help me with a problem I've been bashing my head
against the wall trying to solve.
I've build & installed OpenLDAP 2.0.7 w/ BerkeleyDB 3.1.17 on Solaris 2.6.
Everything appears to work fine, except that searches are always linear,
even when I've built indexes for the requested search attributes.
To test the server, I loaded it up with roughly 25,000 entries. Each entry
look similar to this (all of the indexed attributes are unique):
dn: cn=User Name + amid=811, o=alumni.sfu.ca
cn: User Name
cn: U Name
sn: Name
givenname: U
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: sfuPerson
maildrop: userid@alumni.sfu.ca
uid: userid
userPassword: {crypt}<blanked>
mail: u_name@alumni.sfu.ca
mail: user_name@alumni.sfu.ca
mail: userid@alumni.sfu.ca
The index lines from the slapd.conf file look like this:
index default pres,eq
index uid eq,sub
index mail eq,sub
index maildrop eq,sub
Index files are being built, and running slapd in debug mode shows it
reading the relevant index files.
A search of "(uid=userid)", when running slapd in debug mode, shows slapd
reading the uid.dbb file. After reading it, the following lines are written
to debug output:
=> ldbm_cache_open( "/tmp/sfu/uid.dbb", 16384, 600 )
<= ldbm_cache_open (cache 3)
=> key_read
<= index_read 1 candidates
<= equality_candidates 1
<= filter_candidates 1
<= list_candidates 25036
<= filter_candidates 25036
<= list_candidates 25036
<= filter_candidates 25036
====> cache_return_entry_r( 1 ): returned (0)
=> id2entry_r( 1 )
....
It then proceeds to iterate through every entry in the database looking for
matches.
So what am I doing wrong? Why are my index files being ignored? I've tried
deleting the database and recreating it from a fresh ldif file, with no
change. I've tried increasing the cachesize and dbcachesize parameters.
This, predictably, decreases search times, but not a lot, and chews up
100+mb of RAM - with a bigger cache, it's just iterating through every
entry in the database from RAM instead of from disk.
Any suggestions appreciated.
Steve Hillman hillman@sfu.ca
Senior Systems Administrator (604) 291-3960
Simon Fraser University