Re: 2.3.19 and memory usage

[matthew sporleder <msporleder@gmail.com>]

On 2/9/06, David Hawes <dhawes@vt.edu> wrote:
> On Thursday 09 February 2006 01:00, Howard Chu wrote:
> > David Hawes wrote:
> > > On Wednesday 08 February 2006 18:45, Quanah Gibson-Mount wrote:
> > >> On Wednesday 08 February 2006 13:41, David Hawes wrote:
> > >>> I have been testing OpenLDAP 2.3.19 to finally move from 2.2.26 on my
> > >>> production environment and have run into some issues with memory use.
> > >>> Basically, the settings I use for 2.2.26 do not translate to 2.3.19
> > >>> (all tests were done on the same machine).  On my test, where I dump
> > >>> approximately 500k entries by uid, 2.3.19 uses all available system
> > >>> memory and then segfaults.  2.2.26 returns all entries without
> > >>> incident. Tweaking the BDB cachesize and the entry cachesize appear to
> > >>> have some effect, but the end results are similar.
> > >>
> > >> I've never found BDB to work under 32 bit linux with a 2GB cachesize.
> > >> Set it to 1.9GB.
> > >
> > > I should have been more specific when I wrote 2GB (I rounded up), as I
> > > was using 1.9GB all along.  That said, 1.9GB substituted for 2GB in my
> > > first email still yields the same results.
> >
> > 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:
> > Index: cache.c
> > ===================================================================
> > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v
> > retrieving revision 1.116
> > retrieving revision 1.117
> > diff -u -r1.116 -r1.117
> > --- cache.c     7 Jan 2006 10:06:32 -0000       1.116
> > +++ cache.c     9 Feb 2006 05:53:49 -0000       1.117
> > @@ -659,6 +659,7 @@
> >                                         bdb->bi_dbenv_home );
> >                         }
> >                         ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
> > +                       slap_wake_listener();
> >                 }
> >         }
> >  }
>
> I have tested this patch, and memory usage is back under control.  Thanks for
> the quick fix.
>
> dave
>


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.