[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Memory usage (ITS 6660): Is there a patch to 2.4.23 version to fix the problem ?
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
>>
>
>