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



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
>