> --On Wednesday, September 29, 2010 8:34 PM +0200
>>> --On Wednesday, September 29, 2010 12:38 AM +0000 quanah(a)zimbra.com
>>>> It appears to be a problem with the entry cache, which is set to
>>> Running with a fix from Howard, the entry cache behaves correctly.
>>> However, slapd still grows at the same rate.
>>> If I limit to only 10 paged results searches, slapd grows at a rate of
>>> 300MB Virtual and 300MB Resident for every set of 10 paged results
>>> I do concurrently, up until I run slapd out of memory. There's
>>> very wrong with paged results searches.
>> Could it be configuration-specific? I tested with a plain configuration
>> resulting from test003; maybe some player in the middle, say, is causing
>> entries to be duplicated and leaked, or read-locks on originals are not
>> released correctly? Can you post a configuration that shows the issue?
> Hi Pierangelo,
> My testing shows the issue is only really visible with large databases
> return giant result sets. I don't expect you to see it with a small
> database and test003, because the amount of "lost" memory will be a few
> bytes at best.
If it's something related to bdb's cache size I agree; if it's related to
paged results I'd expect to notice it anyway using valgrind or so.
There's no actual leak, so valgrind won't point anything out. It's
issue with the entry cache not running its purge in some cases where it needs
to. cn=monitor shows that the entry cache grows far beyond its configured
size. Still looking into a proper fix.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/