We are running a cluster of 2 ldap servers using the syncrepl overlay with mirror mode. After upgrading from SLES 10 SP2 (openldap 2.4.11) to SLES 11 SP1 (openldap 2.4.20), we have encountered a memory problem. The slapd process grows unbounded to the point that it uses all of the memory available to the ldap user on the server, currently 2.5GB, in a matter of hours. The database only contains around 30,000 records, so this amount of memory usage seems unusually high. No changes to the server configuration were made during the upgrade.
In an attempt to address the issue, we upgraded both instances further to openldap version 2.4.28, but this has not helped. Below is the slapd.conf (security related pieces have been redacted) that we are using.
~Paul
-------------------BEGIN 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/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/ppolicy.schema
pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args
# Load dynamic backend modules: modulepath /usr/lib/openldap/modules
TLSCipherSuite HIGH:MEDIUM:-SSLv2 TLSCertificateFile /etc/openldap/cert.pem TLSCertificateKeyFile /etc/openldap/cert.key
<ACLs go Here>
loglevel none
ServerID 1
####################################################################### # BDB database definitions #######################################################################
database bdb suffix "dc=redacted" checkpoint 1024 5 cachesize 10000 overlay ppolicy rootdn "cn=redacted" sizelimit -1 ppolicy_default "cn=redacted" ppolicy_use_lockout
directory /var/lib/ldap # Indices to maintain index cn,sn,uid eq index entryUUID eq index entryCSN eq index member eq index objectClass eq
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 limits dn.exact="uid=replica,ou=redacted" time=unlimited size=unlimited
syncrepl rid=501 provider=ldap://peerhost:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=redacted" attrs="*,+" scope=sub bindmethod=simple binddn="uid=redacted" credentials= interval=00:01:00:00
mirrormode on
database monitor -------------------END SLAPD.CONF--------------
--On Thursday, December 22, 2011 8:17 AM -0500 Paul DiSciascio thenut@gmail.com wrote:
We are running a cluster of 2 ldap servers using the syncrepl overlay with mirror mode. After upgrading from SLES 10 SP2 (openldap 2.4.11) to SLES 11 SP1 (openldap 2.4.20), we have encountered a memory problem. The slapd process grows unbounded to the point that it uses all of the memory available to the ldap user on the server, currently 2.5GB, in a matter of hours. The database only contains around 30,000 records, so this amount of memory usage seems unusually high. No changes to the server configuration were made during the upgrade.
In an attempt to address the issue, we upgraded both instances further to openldap version 2.4.28, but this has not helped. Below is the slapd.conf (security related pieces have been redacted) that we are using.
I haven't seen a memory leak in OpenLDAP in a very long time. What I have consistently seen is problematic fragmentation from glibc. Do you use an alternative memory allocator as is advised, such as tcmalloc from google perf tools, or hoard?
You also fail to note your DB_CONFIG configuration at all, or your entry cache/idl cache/dncache sizes.
--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