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
--On Saturday, July 30, 2011 6:23 PM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Please don't top post.
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.
cachesize 4096
How many entries do you have in your database?
dbnosync dirtyread
These are *not* good values to set. You should remove them.
You have failed to provide some key pieces of information. Please provide your DB_CONFIG file. Please provide the total size of your BDB database (du -c -h *.bdb). Please provide the number of real cores your system has available. ITS6660 *only* affects systems with 4+ CPUs. All I've seen you say so far is that as slapd is used, it grows in size. That's typical of slapd loading entries from off of disk into memory. Unless we know how large your database itself *is*, there is no telling if what it is doing is wrong or not.
--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
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
openldap-technical@openldap.org
-
Friedrich Locke -
Quanah Gibson-Mount -
Wolfric