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
