Hi,
I have been working with 389 as a potential replacement for Sun DS and I have found it to
be an excellent choice in every aspect except the final tests I have been running.
I am running with the current version for RedHat 6, but not the latest from the rmeggins
repo:
Name : 389-ds
Arch : noarch
Version : 1.2.2
Name : 389-ds-base
Arch : x86_64
Version : 1.2.9.14
I have searched through all the release notes and part of the 389-users list archive for
clues as to the possible memory leaks and/or patches in the latest releases, but no
information has been forthcoming.
The behavior I am seeing is a total memory consumption occurring over a large quantity of
ldapmodify operations. To test this, I reduced the size of the directory from 10GB down
to about 1.7GB. Then I set up a loop that would run an ldapmodify that would delete of
most of those entries followed by an ldamodify that would add all those deleted back in
(and then repeat indefinitely).
The directory starts out by loading all the entries into the cache and using a few GB of
ram to hold everything. Eventually, this loop causes the entire 32GB of ram to be
consumed even though the total size of the directory does not change (e.g.
currententrycachesize: 1791096898).
Replication is enabled to a consumer and the change log is up to 7.4 GB, and it
doesn't seem to want to clean out the change log even with short purge times and short
entry lifetimes configured, so perhaps something is at issue here. The consumer has
processed all updates and also seems to exhibit overconsumption of memory.
Are there any pointers related to this?
If there is no information about this, is there a documentation page that might instruct
me in the correct way to attach valgrind to the ns-slapd process so I can see if there is
some kind of huge leak?
Thanks very much,
Russ.
==============================
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
beall(a)usc.edu
==============================