[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.
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
jwm@horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__