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

[hyc@symas.com]

Rodrigo Costa wrote:
> Howard,
>
> I do not think the ITS is completely solved. Let me try to explain better.
>
> I have the system respecting now the DN cachesize boundary. At the same time I wasn't sure about the cachefree idea and now I changed to 1, or equal the default value.
>
> In any case what happens is :
>
> 1) I have the system doing sequential search in a reasonable speed until the dncachesize is reached;
> 2) After dncchesize is reached the sequential search hangs, or the output from the search get stuck for a long time(I'm forwarding to a file so I do not have screen actualization delays);
> Ex:
> [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l
> Mon Jan 26 17:22:21 BRST 2009
> 250016
> [root@brtldp11 backup]# date; cat temp.ldif |grep -e '^pnnum*' |wc -l
> Mon Jan 26 17:23:00 BRST 2009
> 250016
> See above that even almost after 1 minute passed not new LDIF entrance was included.
> 3) Then query get stuck and looks like deterministic it time by time only dumps 16 entrances and get stuck. This behavior repeats and with these stuck that sometime gets minutes the query never ends.
>
> olmBDBEntryCache: 884
> olmBDBDNCache: 1000261
> olmBDBIDLCache: 1
>
> olmBDBEntryCache: 611
> olmBDBDNCache: 1000261
> olmBDBIDLCache: 1
>
>Even with cachesize as 1000 and cachefree as 1, the olmBDBEntryCache continues
to decrease, just slow now.
>
> I was expecting that a cachefree as 1000 would purge all entrances and then
> cache again all 1000 new with in sequence always answering the search. So
> the search would never hangs like it is happening now.

I see. OK, this is now fixed in HEAD.

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