[Date Prev][Date Next]
Re: slapd stability problems with add/change operations
--On Thursday, August 18, 2005 2:13 PM +0200 Adrian Gschwend
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
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: connection_input: conn=289 deferring operation: awaiting
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 :)
No, it makes little sense to me. I always build with "-O2 -g" so I have an
optimized build with debugging, and it functions no differently than as
Maybe you fixed something in your rebuild. ;)
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin