[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Memory usage question
Hi,
I hope this isn't an FAQ, but a search on the list only yielded
one thread (see below).
Throughout the day my slapd process grows to about 350 megs
before I have to restart it. Granted, I have a slightly underpowered
machine as far as memory/swap, but there seems to be no limit
to how large the process will grow. It will eventually consume all
memory and swap until it dies on a failure to realloc memory. Use of
cachesize/dbcachesize in the config file seem to have no effect.
Specifics:
Openldap 1.2.9 on FreeBSD-3.4-stable (also happened with 1.2.8).
About 1400 entries in db.
slapd.conf:
include /usr/local/etc/openldap/slapd.at.conf
include /usr/local/etc/openldap/slapd.oc.conf
schemacheck on
pidfile /usr/local/var/slapd.pid
argsfile /usr/local/var/slapd.args
database ldbm
suffix "o=Foobar Publishers,c=US"
directory /usr/tmp
rootdn "uid=shoobydo,o=FoobarPublishers,c=US"
rootpw *****
updatedn "uid=shoobydo,o=Foobar Publishers,c=US"
index dn,mailhost,mail,mailalternateaddress eq
#loglevel 10
#cachesize 100 <-- tried these at various settings
#dbcachesize 1000 <--
-------- Previous Thread --------------
At 05:20 PM 10/13/99 -0500, Dave Brodin wrote:
>We are using OpenLDAP 1.2.7 and RedHat Linux 6.0. After putting three
>instances the directory server into production, we noticed that the
>memory usage of slapd on each climbs steadily throughout the day until
>it reaches a point where it will bring the servers to a standstill.
It's normal for slapd to grow it's cache as needed. You
may need to tune cachesize and dbcachesize. Slapd, of course,
grows as needed to handle higher client demands (concurrent
connections, operations, etc.). (Usage should stabilize under
max load).
>I saw postings on the openldap web site about memory leaks in 1.2.6,
but
>it said it was fixed in the release I have.
>From the feedback I've gotten, 1.2.7 appears to resolved
the memory leaks issues reported by users of 1.2.6. It should
be noted that some versions of BerkeleyDB leak, we recommend
2.7.5 (or later). GDBM 2.8 is also an option.
>Right now, we have to run a
>cron job to check when the memory usages gets too high and restart
>slapd. I'm wondering if anyone else has seen that kind of behavior.
>Any help would be appreciated.
This shouldn't be necessary. You should be able to tune slapd
to cachesize/dbcachesize such that reasonable headspace is available
for growth.
Kurt