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

Re: slapd dying, what next?



Quanah Gibson-Mount wrote:
--On Wednesday, January 20, 2010 8:39 AM -0600 "Bryan J. Maupin" 
<bmaupin@uta.edu> wrote:

  
We're running on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k,
Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), libunwind 0.99 (for Google
tcmalloc), Google tcmalloc 1.3.
    

libunwind is not required for tcmalloc, you must be building it incorrectly.
  
>From the "INSTALL" file that came with Google performance tools 1.3:

"if you use a 64-bit system, we strongly recommend you
install libunwind before trying to configure or install google
perftools.  libunwind can be found at

   http://download.savannah.gnu.org/releases/libunwind/libunwind-0.99-beta.tar.gz"
  
1. Is there any useful information that can be obtained from these log
entries, or do we simply need to change to a more verbose log level and
wait for slapd to die again?
2. If we need to change our log level, what is a suggested level?  Right
now we're using "loglevel sync stats".  Would it be wise to change the
log level to -1 (any)?  These are production servers, and I imagine
that'd be a huge performance hit.
3. Also, we're logging asynchronously at the moment.  Should we disable
this while debugging?
    

I would suggest you

(a) Upgrade to 2.4.21
(b) Fix your tcmalloc build
(c) If the problem still occurs, run slapd under gdb so you can get a 
backtrace of some kind.

Make sure your OpenLDAP build, etc, has debugging symbols.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration