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

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



Rodrigo Costa wrote:
> Howard,
>
> I move back into OL 2.4 and collected again the monitor information. Now I could see the cache information.
>
> I just execute the ldapsearch in one existent DN so I can confirm the number of entraces. The result was :
>
> 1000000
>
> real    6m55.707s
> user    0m27.292s
> sys     0m8.525s
>
> Now that entrances are cached this reduce almost to half time if I run again.
>
> But at monitor I have :
>
> readOnly: FALSE
> olmBDBEntryCache: 1001
> olmBDBDNCache: 4000264
> olmBDBIDLCache: 1
> olmDbDirectory: /var/openldap-data/bdb2/
>
> Where the DNCache grew without limits and this memory is never released.
>
> My slapd.conf has :
>
> line 122 (cachesize       1000)
> line 123 (idlcachesize    1000)
> line 124 (dncachesize     2000)
>
> for my bdb2 DB.
>

> I beleive that in the worst case dncachesize is not defined it would be
> something like twice the cachesize.
>
> Other thing I do not understand well is the DNcache bigger than 1,000,000
> since this is the number of entrances I have in the DB.
>
> By what we talked previously the dncachesize was included exactly to
> control this memory consumption. But looks like for some reason it is not
> accepting this configuration.
>
> Without this limit, 32 bits or 64 bits machine, will soon or later have
> memory problems.
>
> Please let me know your comments.
>
> Thanks a lot !

Thanks for this information. Yes, there is a bug here - a single function is 
used to purge the entry and DN caches, but when the entry cache is already 
within its limits, it returns without doing any work, so the DN cache never 
gets purged. It will take some time to fix this.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/