I don't want to be insulting here but i should probably mention this just in case you're not aware.
does echo 1 | sudo tee /proc/sys/vm/drop_caches do anything after you see this memory increase? On Sat, Jul 30, 2011 at 10:23 PM, Friedrich Locke <[email protected]> wrote: > It is not that's using 63MB. It is that is uses 63MB after performing > 4 lookup, i.e., its memory usage grows from 15MB to 63MB. > > If i try more ldap lookup (15 in total), it goes to 425 MB of usage. I > tried to limit data usage via unix resource control (/etc/login.conf, > yes, i am using openbsd). The process (slapd) die after reaching the > limit for data memory usage. > > Here is my configuration (/etc/openldap/slapd.conf) > > # > # See slapd.conf(5) for details on configuration options. > # This file should NOT be world readable. > # > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/nis.schema > include /etc/openldap/schema/qmail.schema > > # Define global ACLs to disable default read access. > > # Do not enable referrals until AFTER you have a working directory > # service AND an understanding of referrals. > #referral ldap://root.openldap.org > > pidfile /var/run/oldap/slapd.pid > argsfile /var/run/oldap/slapd.args > > database bdb > #suffix "dc=my-domain,dc=com" > suffix "dc=ufv,dc=br" > #rootdn "cn=Manager,dc=my-domain,dc=com" > rootdn "cn=oldap,dc=ufv,dc=br" > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > #rootpw secret > rootpw {SSHA}HBjSmSCbiE8J26EuDg3ULnSj2SmN1x5g > # The database directory MUST exist prior to running slapd AND > # should only be accessible by the slapd and slap tools. > # Mode 700 recommended. > directory /var/openldap-data > # Indices to maintain > index cn eq > index objectClass eq > index mail,mailalternateaddress,uid eq,sub > index accountstatus,mailhost,deliverymode eq > index default eq > > cachesize 4096 > checkpoint 128 15 > dbnosync > dirtyread > > sasl-host gustav.cpd.ufv.br > sasl-realm UFV.BR > sasl-regexp uid=([^,]+),cn=UFV.BR,cn=gssapi,cn=auth > uid=$1,ou=people,dc=ufv,dc=br > > limits dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" time=2048 size=16384 > limits dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" time=2048 size=16384 > limits dn.onelevel="ou=people,dc=ufv,dc=br" time=4 size=1 > > access to dn.one="ou=appsrv,dc=ufv,dc=br" attrs=userpassword > by self read > by anonymous auth > # by * none > > access to dn.one="ou=appsrv,dc=ufv,dc=br" > by self read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" attrs=userpassword > by self read > by anonymous auth > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" attrs=objectclass > by self read > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" search > by dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" attrs=homedirectory > by self read > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" attrs=entry,uid > by self read > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > by dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" > attrs=cn,uidnumber,gidnumber,loginshell,gecos,description > by self read > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" > attrs=mail,mailalternateaddress,qmailuid,qmailgid,mailmessagestore,mailquotasize,mailquotacount,mailsizemax,mailforwardingaddress,deliveryprogrampath,mailhost,deliverymode,mailreplytext,qmaildotmode,accountstatus,qmailaccountpurge > by self read > by dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=people,dc=ufv,dc=br" > by self read > # by * none > > access to dn.base="ou=people,dc=ufv,dc=br" attrs=entry > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > by dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.base="dc=ufv,dc=br" attrs=entry > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > by dn.base="cn=mail,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.one="ou=group,dc=ufv,dc=br" > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > # by * none > > access to dn.base="ou=group,dc=ufv,dc=br" attrs=entry > by dn.base="cn=ypldap,ou=appsrv,dc=ufv,dc=br" read > # by * none > > > ####################################################################### > # Monitor database definitions > ####################################################################### > > database monitor > > access to dn.subtree="cn=monitor" > by dn.base="cn=oldap,dc=ufv,dc=br" read > # by * none > > > =============== END OF CONFIGURATION ==================== > > > On Sat, Jul 30, 2011 at 4:10 PM, Quanah Gibson-Mount <[email protected]> > wrote: >> --On Friday, July 29, 2011 12:51 PM -0300 Friedrich Locke >> <[email protected]> wrote: >> >>> Dear list members, >>> >>> i am running openlda 2.4.23 and i am facing memory usage problems (ITS >>> 6660). I am not given the option to change to 2.4.23. >>> Is there a patch to fix this problem? >> >> Given your stated database size, I sincerely doubt you are hitting the issue >> in ITS6660. You also fail to note any of your configuration settings. I >> personally don't see a slapd size of 63MB particularly large. Does it >> continually grow, or does it stay steady at 63MB? >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Sr. Member of Technical Staff >> Zimbra, Inc >> A Division of VMware, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > >
