I think this is incorrect. Any time you make changes to DB_CONFIG, the
BDB environment has to be updated. The quickest way to do that in 2.2
is to shut down slapd, run db_recover, and then restart slapd. OpenLDAP
2.3 takes care of DB_CONFIG changes for you.

thought about that as well after you posted that, that makes more sense
like this.

I seriously doubt you are running out of locks. It took me 88 indices
on a 400k entry DB to have to move from the default to 3k locks.

that's what I thought as well but I'm desperate ;)

Is this with syncRepl? If yes, see the bottom bit on this email.

yes we are using syncRepl

[SMP]

It might, although I don't have such a problem on my 4 CPU Solaris
boxes. There was a recent ITS#3456 about FreeBSD's threading setup, but
I don't know if it actually applies here. Are you using syncRepl?

correction to that: It is an SMP machine but I didn't install the SMP
kernel here, so forget the SMP statement, sorry. It was always running
as single CPU machine.

In any case, it may be worthwhile to build with debugging symbols, and
then when slapd locks up, run gdb on the process and get a back trace of
where all the threads are at.

ok, I will try to do that to make sure we can at least locate the
problem. I will also try to run the DB on another testserver I have to
see if I run into the same problems there. One testbox ist FreeBSD 4.9
but beside this the same setup (but different hardware too), the second
textbox I've just set up now is Debian 3.1 with OpenLDAP 2.2.23