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

OpenLDAP 2.0.15 slower than 1.2.11



Hi,

We have been using openldap 1.2.xx for some time.
We are now trying to migrate to openldap 2.0.15 but we are finding it
dificult.
Our searches on 1.2.xx take 0.007s on average with about 500 000
objects.
On a equivalent system using version 2.0.15 the same search lasts over
5m (5m21.239s according to time).

When debuging 2.0.15 (slapd -d 255) we get:

=> equality_candidates
=> ldbm_cache_open( "uid.dbb", 7, 600 )
ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
<= ldbm_cache_open (opened 3)
=> key_read
<= index_read 1 candidates
<= equality_candidates 1
<= filter_candidates 1
=> filter_candidates
        EQUALITY
=> equality_candidates
=> ldbm_cache_open( "s.dbb", 7, 600 )
ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
<= ldbm_cache_open (opened 4)
=> key_read
<= index_read 348908 candidates
<= equality_candidates 348908
<= filter_candidates 348908
<= list_candidates 1
<= filter_candidates 1
<= list_candidates 348908
<= filter_candidates 348908
<= list_candidates 348908
<= filter_candidates 348908
entry_rdwr_runlock: ID: 1

Which seems good (reading and parsing the indexes)

but then:

====> cache_return_entry_r( 1 ): returned (0)
=> id2entry_r( 2 )
=> ldbm_cache_open( "id2entry.dbb", 7, 600 )
<= ldbm_cache_open (cache 1)
=> str2entry
<= str2entry(o="Zurich Seguros", c=PT) -> -1 (0x80d5d28)
entry_rdwr_rlock: ID: 2
<= id2entry_r( 2 ) 0x80d5d28 (disk)
=> test_filter
    AND
=> test_filter_and
=> test_filter
    EQUALITY
=> access_allowed: search access to "o="Zurich Seguros", c=PT" "uid"
requested
=> access_allowed: backend default search access granted to ""
<= test_filter 5
<= test_filter_and 5
<= test_filter 5
ldbm_search: candidate 2 does not match filter
entry_rdwr_runlock: ID: 2


And goes on to test all entries in id2entry taking a very long time. It 
appears that all entries are candidates, regardless of their contents.
This should be a configuration bug, but I can't really understand where.
We have indexes for both (and some more) attributes with presence and
equality. I don't really understand what is going on here but appears
that slapd is ignoring the indexes.

Thanks in advance,
RJS
-- 
"Liberty is the Mother, not the Daughter of Order" - Proudhon
Sys. Adm.					eServices/Consultadoria
PGP Fingerprint: 5C 53 4B CC 90 6D 2E E7  60 54 6B 39 35 E9 28 C5
Key available in a pgp key server near you