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

Re: slapd stability problems with add/change operations



--On Tuesday, August 16, 2005 3:59 PM +0200 Adrian Gschwend <adrian.gschwend@bfh.ch> wrote:

Adrian Gschwend wrote:

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


ok now it's getting extremely weird:

- complete new HW
- debian 3.1
- openldap 2.2.23
- bdb 4.2.52 with latest patches
- slapcat on freebsd, slapadd on debian

Used to work for some hours, and now it locked twice, each time with an
add operation. We do not have any entries in the log that the cache or
the locks were on the limit. loglevel is 256



I'm not quite sure what you mean here.

Are you:

1) set up slapd configuration
  leave slapd off
  slapadd database

OR

2) set up slapd configuration
  start slapd
  slapadd database and it fails

OR

3) set up slapd configuration
  leave slapd off
  slapadd database
  do more adds via ldapmodify

Also I am not aware of any logging that exists that the cache reaches its limit.


Note that #2 is a valid way to build a database.
Note that for #1, it is entirely possible for it to *appear* that slapadd has locked up, when what really happens is that the DB Cache isn't large enough, so slapadd slows down drastically (but still continues, albeit very very slowly)
Note taht for #3, that would be an interesting problem.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html