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

Re: slapd leaking memory on i386?

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. 


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.


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.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/