[Date Prev][Date Next]
Re: (ITS#5860) slapd memeory leak under openldap 2.4
Rodrigo Costa wrote:
> 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 :
> 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/