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

Re: slapd stability problems with add/change operations

Quanah Gibson-Mount wrote:

Once you are in gdb, then the easiest thing to do is to get a backtrace of where you are at:

thr apply all bt

will do a back trace of where all the existing threads are currently at.

thanks for the hint, I compiled the deamon with exactly the same options on FreeBSD, actually the only thing I added to the Makefile of the ports-collection is:

CFLAGS+=                -g

then I copied the binary I got to the original location, it's 5.4MB instead of about 800k before. I can attach to the process and I do get backtraces when I do that once it started.

So we started to stress the server (without gdb attached to it for sure), sync in loop and add/del operations on the server. And guess what, it doesn't hang! We did around 600 add operations within 5 seconds, something that locked the server very easily before. So we were a *bit* confused and checked the log, what we found is this:

slapd[1144]: connection_input: conn=289 deferring operation: awaiting write

we *never* saw this message in the release without debug information!? How is that possible? As I said the only thing I changed is the debug options, I didn't touch anything else.

So conclusion so far: With debug symbols we can't lock it, at least not so far. Does that make sense? It does confuse me at least :)


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