Re: slapd stability problems with add/change operations

[Adrian Gschwend <adrian.gschwend@bfh.ch>]

Quanah Gibson-Mount wrote:

> 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

cu

Adrian


--
Adrian Gschwend
System Administrator
Berne University of Applied Sciences
Biel, Switzerland