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.