[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
>>
>
>