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

OpenLDAP (using BDB) stalls adding 65,536th entry



I've been doing some testing using OpenLDAP with BDB on a couple of different platforms.  I noticed a similar situation.  When I sit in a loop doing adds, at the 65,536th added entry the process stalls for a short period of time.  After a minute or two, the add succeeds.  My first thought is that this is a BDB issue, so I posted this question to Oracle's BDB forum.  But I have yet to receive any answer. 

This situation seems to happen when I have around 43 10MB log files.  During the stall, I notice many log files are being written (another 25 or so), which is a much quicker rate than was being written prior to the stall.   

The stall only happens once. I added another 350,000 entries and no more stalls.  I ran a few other tests.  Added 65,535 entries.  All is fine.  As soon as the next entry is add, even if I recycle the server, I hit the condition.  I even tried deleting 1,000 entries.  I would then need to add 1,0001 to get to 65,536 entries in the database and then hit the delay.

I did try playing around with the number of indexes and it did seem to affect the size of the delay, but not the fact that the delay occurs.

I'm trying to understand what OpenLDAP or BDB is doing during the stall.  Is their a reorganizing of tables/indexes based on a threshold of 65,536 entries?  Is this a one time only event as my testing seems to show?  Again, my suspicion is that it's more of a BDB issue, but thought others here may have seen this situation.

Some values from my DB_CONFIG file:
set_cachesize 0  20971520 1
set_lg_regionmax  1048576
set_lg_max        10485760  
set_lg_bsize      2097152
set_lk_max_locks   2000
set_lk_max_objects 2000
set_open_flags db_private

Some values from my slapd.conf:
database bdb
suffix "dc=myco,dc=com"
rootdn "cn=Manager,dc=myco,dc=com"
rootpw secret
directory /usr/local/var/openldap-data
index objectClass eq
index cn eq,sub
index departmentNumber eq
index employeeNumber eq,sub
index uid eq,sub
index    entryCSN eq
index    entryUUID eq

cachesize      5000
idlcachesize   5000
dncachesize    30000
cachefree      100

searchstack 8
threads 4


Thanks for any help,
Mark