Quanah, That's is exactly the point. My system is a 32 bits and with 64 bits if there are enough physical memory available even slapd cache grows without never release it will be difficult(or very long) to cache enough entrances before system consumes all memory.
With the 32 bits 3GB maximum, depend on OS too, this issue appears more often. My impression is if you ldapsearch all DB in a 32 bits HW/OS slapd will consume all possible memory unless to keep boundaries for its cache(erase and overwrite). In 64 bits with a lot of memory this will be more difficult to happen but eventually will happen if the logic is the same. I was wondering if in a sittuation where this cache memory issue would appear, like ldapsearch, if there is a feature in openldap where it would guarantee the cache boundaries and the reutilization of the space after the limits are reached. Looks like even with the slapd.conf configurations it doesn't keeps its limits. Regards, Rodrigo. --- On Wed, 1/21/09, Quanah Gibson-Mount <[email protected]> wrote: > From: Quanah Gibson-Mount <[email protected]> > Subject: Re: (ITS#5860) slapd memeory leak under openldap 2.4 > To: [email protected], [email protected] > Date: Wednesday, January 21, 2009, 6:41 PM > --On Wednesday, January 21, 2009 12:23 PM -0800 Rodrigo > Costa <[email protected]> wrote: > > > Quanah, > > > > My initial attempt was using openldap2.4.11 since this > is the stable > > version. At this version Berkeley DB 4.7 isn't > supported and then I used > > the BDB 4.6 with all patches. > > I hardly consider 2.4.11 stable, regardless of what the tag > is. I would advise trying something more current (such as > 2.4.13). And with BDB 4.7 + patches. > > > At this configuration, having the DB_CONFIG setup for > 50MB, and even > > having the idlcache and cache sizes defined I continue > to see the memory > > being allocated and never released by slapd. > > What about dncachesize as well? > > > 2.3.27-8.el5_2.4 where the CentOS5.4 uses a built-in > backend library for > > BDB4.4. > > If you are looking for stability, I would hardly go with > the crappy release CentOS ships. The final 2.3 release was > 2.3.43. Use it instead if you want to use 2.3. > > Also, are you on a 32 or 64-bit system? I certainly have > no problems going over 3GB on my 64-bit systems. > > For example: > [zim...@ldap openldap-data]$ du -c -h *.bdb > 1.1G cn.bdb > 564M displayName.bdb > 702M dn2id.bdb > 158M entryCSN.bdb > 122M entryUUID.bdb > 335M givenName.bdb > 6.5G id2entry.bdb > 1.1G mail.bdb > 5.5M objectClass.bdb > 855M sn.bdb > 121M uid.bdb > 8.0K zimbraDomainName.bdb > 122M zimbraId.bdb > 20K zimbraMailAlias.bdb > 1.1G zimbraMailDeliveryAddress.bdb > 2.1M zimbraMailForwardingAddress.bdb > 3.1M zimbraMailTransport.bdb > 8.0K zimbraVirtualHostname.bdb > 8.0K zimbraVirtualIPAddress.bdb > 13G total > > > DB is 13GB in size. > > [zim...@ldap openldap-data]$ cat DB_CONFIG > set_cachesize 8 0 2 > set_lg_regionmax 262144 > set_lg_bsize 2097152 > set_lk_max_locks 1500 > set_flags DB_LOG_AUTOREMOVE > set_lg_dir /var/log/zimbra-ldap-journals > > Process size: > > 8447 zimbra 17 0 9.9g 8.9g 8.1g S 34 57.5 39:20.57 > slapd > > > Using OpenLDAP 2.3.42. > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and > collaboration
