[Date Prev][Date Next]
Re: 2.3.19 and memory usage
On Thursday 09 February 2006 12:15, Quanah Gibson-Mount wrote:
> --On Thursday, February 09, 2006 11:25 AM -0500 matthew sporleder
> <firstname.lastname@example.org> 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
As expected, there is no hang with the patch in place.