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