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

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



Howard,

Thank you for your great knowledge in the OpenLDAP internals.

I will also give a try and check but looks like you could pinpoint the issue and solve it.

I would like to say this will greatly allow many users to control better memory usage and then have DBs bigger than available memory, what can be very common nowadays.

I normally will not have 2 process searching DB simultaneously, this was just a test. In this way performance, in average, will be reasonable.

Thanks a lot!

Rodrigo.


--- On Mon, 3/2/09, Howard Chu <hyc@symas.com> wrote:

> From: Howard Chu <hyc@symas.com>
> Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4
> To: rlvcosta@yahoo.com
> Cc: openldap-its@openldap.org
> Date: Monday, March 2, 2009, 4:36 AM
> 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/