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

Re: slapd leaking memory on i386?

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.


>> 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.


John Morrissey          _o            /\         ----  __o
jwm@horde.net        _-< \_          /  \       ----  <  \,
www.horde.net/    __(_)/_(_)________/    \_______(_) /_(_)__