Re: (ITS#5860) slapd memeory leak under openldap 2.4

[hyc@symas.com]

Rodrigo Costa wrote:
> Howard,

> 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
> of
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/