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/