On 2/9/06, David Hawes <[EMAIL PROTECTED]> 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.