Re: 2.3.19 and memory usage

[David Hawes <dhawes@vt.edu>]

On Thursday 09 February 2006 12:15, Quanah Gibson-Mount wrote:
> --On Thursday, February 09, 2006 11:25 AM -0500 matthew sporleder
>
> <msporleder@gmail.com> wrote:
> >> > I've reproduced this behavior, it's due to the same reason as
> >> > ITS#4385. Now fixed in HEAD back-bdb/cache.c. A potential workaround
> >> > is to issue a few no-op requests to the slapd server while the large
> >> > search operation is in progress. (Basically the task that purges
> >> > excess entries from the entry cache isn't getting started right away;
> >> > it won't start until the current search finishes or any new request is
> >> > received.) You can use this patch:
> >
> > Is this 32bit linux specific, or will it affect all larger databases?
> > The patch looks very simple, but I was just wondering about the impact.
>
> It is not 32 bit linux specific.  However, as noted above by Howard, it
> only is going to affect a system that has a single search occurring on it.
> I.e., if your LDAP server is a busy one, then you won't notice this
> behavior.  As soon as a second operation (search, bind, mod, add, etc) is
> received, then the task that purges excess entries kicks in.  Which is
> likely why no one noticed this previously.
>

All of this seems true from my observations.  It should be noted that if you 
are searching for a large number of entries on a server that has no load, you 
will see all operations to that server hang when you initiate the second 
operation (as I assume the purge task is taking a fair amount of time to 
complete).  This is apparently what was happening on my 12MB BDB cachesize 
example.

As expected, there is no hang with the patch in place.

dave