[Date Prev][Date Next]
Re: (ITS#5860) slapd memeory leak under openldap 2.4
Rodrigo Costa wrote:
> I saw sometimes the DN cache allocating a little more memory since it
sometimes pass a little the boundary, like seen below :
> olmBDBEntryCache: 1000
> olmBDBDNCache: 1000247
> olmBDBIDLCache: 1
> The maximum I saw was 1000268 but nothing considerable. In this way now
slapd is keeping memory allocation stable as it is supposed to behave.
The DN cache is hierarchical; it will only free leaf nodes (entries that have
no children). So depending on the structure of your tree, it's normal for the
Monitor to report more elements in the DN cache than you configured.
> The only comment is if dn cache is passed this memory allocated appears to
never be released. The maximum size slapd obtained was :
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 10195 ldap 18 0 385m 266m 68m S 0 2.2 20:54.16 slapd
> This is more than perfect !
> Thanks for all your quick solution of this problem. I believe many users
openLDAP will see their system more stable with this fix.
> Just some last questions. Is there any expectation for a new release, for
example 2.4.15, with this ITS included? Just to use a formal release.
> By the tests I was expecting the cachefree as the cache size bringing some
improvements, at least in a full query, since system would "cycle" pointer
memory and overwritten all cache at once. What is the purpose of cachefree?
cachefree applies only to the entry cache. The idea is to minimize the number
of times it must cycle through the cache trying to free entries. Typically
when we configure large servers with caches of 1 million entries or more, we
configure this to 1000 or so (0.1% of cache size).
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/