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 friedrich.locke@gmail.com 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 quanah@zimbra.com wrote:
--On Friday, July 29, 2011 12:51 PM -0300 Friedrich Locke friedrich.locke@gmail.com 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