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

slapd take a long time to retrieve the entries



I have been adding about  42647 records to the slapd database and a
problem occurs when i do a ldapsearch :
when i do a search, slapd take a long time to retrieve the entries.

I have defined some index in slapd.conf and i do my search with a filter
(The filter is an index).
I work with openldap 2.0.4 on solaris 7 and I use Berkeley  ldbm
backends.
See what 's happen when i do my search:
*Firstly my slapd.conf:
include /usr/local/etc/openldap/schema/core.schema
....
pidfile         /usr/local/var/slapd.pid
argsfile        /usr/local/var/slapd.args
loglevel        256
sizelimit       5000
timelimit       3600
######################################################################
# ldbm database definitions
#######################################################################
database        ldbm
suffix          "o=alcatel,c=FR"
suffix          "dc=alcatel,dc=fr"
directory       /usr/local/var/openldap-ldbm
index commonName,uid,telephoneNumber eq
index
telephoneNumber2,telephoneNumber1,telephoneNumber3,telephoneNumber4 eq
index vpuSiteName,VoiceMailboxId,VPUNumber eq
dbcachesize     10000000
cachesize       100000
.........
* I run slapd with a debuglevel:
     /usr/local/libexec/slapd -d -1
* I do my search with

ldapsearch -D "cn=admin,o=alcatel,c=FR" -w secret -b "o=alcatel,c=FR"
"cn=548"


*slapd is running, and with the debug level we can see a problem
appears.

.................

search_candidates: base="O=ALCATEL,C=FR" s=2 d=0
=> filter_candidates
        AND
=> list_candidates 0xa0
=> filter_candidates
        DN SUBTREE
=> dn2idl( "@O=ALCATEL,C=FR" )
=> ldbm_cache_open( "/usr/local/var/openldap-ldbm/dn2id.dbb", 7, 600 )
<= ldbm_cache_open (cache 0)
<= filter_candidates 42647
=> filter_candidates
        OR
=> list_candidates 0xa1
=> filter_candidates
        EQUALITY
=> equality_candidates
<= equality_candidates: index_param failed (18)
<= filter_candidates 42647
=> filter_candidates
        EQUALITY
ber_get_next
sockbuf_read: want=1 error=Resource temporarily unavailable
ber_get_next on fd 7 failed errno=11 (Resource temporarily unavailable)

daemon: select: listen=6 active_threads=1 tvp=NULL
=> equality_candidates
=> ldbm_cache_open( "/usr/local/var/openldap-ldbm/cn.dbb", 16, 600 )
<= ldbm_cache_open (cache 3)
=> key_read
<= index_read 1 candidates
<= equality_candidates 1
<= index_read 1 candidates
<= equality_candidates 1
<= filter_candidates 1
<= list_candidates 42647
<= filter_candidates 42647
<= list_candidates 42647
<= filter_candidates 42647
entry_rdwr_runlock: ID: 1
====> cache_return_entry_r( 1 ): returned (0)
=> id2entry_r( 1 )
entry_rdwr_rtrylock: ID: 1
====> cache_find_entry_id( 1 ) "o=alcatel,c=FR" (found) (1 tries)
<= id2entry_r( 1 ) 0x105cc8 (cache)
=> test_filter
    EQUALITY
=> access_allowed: search access to "o=alcatel,c=FR" "cn" requested
<= root access granted
<= test_filter 5
candidate 1 does match filter
entry_rdwr_runlock: ID: 1
====> cache_return_entry_r( 1 ): returned (0)
=> id2entry_r( 2 )
entry_rdwr_rtrylock: ID: 2
====> cache_find_entry_id( 2 ) "cn=1,o=alcatel,c=FR" (found) (1 tries)
<= id2entry_r( 2 ) 0x105e28 (cache)
=> test_filter
    EQUALITY
=> access_allowed: search access to "cn=1,o=alcatel,c=FR" "cn" requested

....


* slapd retrieve the entry and continue the search



 Apparently there is a problem wih the index and with dn2id.dbb in the
directory /usr/local/var/openldap-ldbm/

i think that the slapd server don 't search the entrie with the help of
dn2id.dbb and the other index file

 my database:

# cd /usr/local/var/openldap-ldbm/
# ls -la
total 103324
drwx------   2 root     other        512 oct 27 18:09 .
drwxr-xr-x   5 root     other        512 oct 23 12:28 ..
-rw-------   1 root     other    2490368 oct 28 08:58 cn.dbb
-rw-------   1 root     other    7401472 oct 28 08:58 dn2id.dbb
-rw-------   1 root     other    35098624 oct 28 08:58 id2entry.dbb
-rw-------   1 root     other       8192 oct 28 08:58 nextid.dbb
-rw-------   1 root     other      69632 oct 27 21:50
telephoneNumber.dbb
-rw-------   1 root     other      69632 oct 27 21:50
telephoneNumber1.dbb
-rw-------   1 root     other      69632 oct 27 21:50
telephoneNumber2.dbb
-rw-------   1 root     other      69632 oct 27 21:50
telephoneNumber3.dbb
-rw-------   1 root     other    2473984 oct 28 08:58 uid.dbb
-rw-------   1 root     other    2465792 oct 28 08:58 VoiceMailboxId.dbb

-rw-------   1 root     other    2531328 oct 28 08:58 VPUNumber.dbb
-rw-------   1 root     other      69632 oct 27 21:50 vpuSiteName.dbb



thanks you for your help.