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

[hyc@symas.com]

Rodrigo Costa wrote:
> Howard,
>
> One more comment. If you take a longer time between the ldapsearches the
issue doesn't appear sometimes.
>
> So you need to start the first ldapsearh and like 15 seconds later start
> the
second one. With this scenario the problem will for sure appear.

I was finally able to reproduce this issue, by running two identical searches 
simultaneously on a server with more than 2 CPU cores. Given any delay between 
the two search invocation, the problem did not appear.

This is now fixed in HEAD. Thanks for your help in providing data for 
reproducing the issue.

> In this way we will see large chunks of memory being allocated and after
> it
stabilizes the query get stuck returning as the issue before 16 records per
minute, or very slow and getting stuck all the time.

I should point out - the memory use is stabilized now (as it should be) but 
the search performance of a configuration such as yours will be extremely poor 
due to the unavoidable thrashing that such a query pattern exerts on the 
cache. Setting a larger minfree can help reduce some of the contention but it 
will still be much slower than normal.

> Regards,
>
> Rodrigo.


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