On Fri, May 01, 2009 at 02:38:52PM -0700, Howard Chu wrote: > John Morrissey wrote: >> On Tue, Apr 21, 2009 at 10:33:23AM -0700, Howard Chu wrote: >>> John Morrissey wrote: >>>> Any response to this, Howard? slapd finally consumed enough memory on >>>> this machine that the kernel OOM killer terminated it, but this problem >>>> is trivial for us to reproduce (happens after a few days of slapd >>>> uptime). >>> >>> If it's so easily reproducible you should be able to recreate this while >>> running a heap profiler. Can you get hold of google's tcmalloc and run >>> with that? >> >> Ran 2.4.16+tcmalloc for about a week with heap profiling enabled. Memory >> size was stable. > > OK, then your issue is with the default libc malloc working poorly wrt > heap fragmentation; you should probably just use tcmalloc from now on.
nod. >> slapd caught a SIGABRT due to an assertion failure in >> connection_close() after about 7 days of uptime. Backtrace is >> log.assertion-failure. > > Separate issue, probably should submit to ITS. http://www.openldap.org/its/index.cgi/?findid=6089 >> Restarted slapd; it ran for two days before no longer responding to incoming >> connections (the connection would be accepted, but all LDAP operations would >> block). All worker threads seem to be blocking on mutex acquisition in >> bdb_cache_lru_link(). One thread was chewing lots of CPU. Backtrace is >> log.bdb-cache-locks. > > Also a separate issue. http://www.openldap.org/its/index.cgi/?findid=6090 john -- John Morrissey _o /\ ---- __o [email protected] _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
