[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: restricting slapd memory consumption
--On Wednesday, April 02, 2008 10:41 AM +0200 Ralf Narozny
<rnarozny@web.de> wrote:
Yep, as I wrote in my initial mail, we are using 2.3.32 (for testing so
far).
The current release is 2.3.41. Why are you using such an old release?
There've been many known problems fixed since that release, including
security issues, and possibly some memory leaks.
What version of BDB are you using? Have you patched it with all the
relevant patches?
And I wrote that we are using BDB which is configured to use 4GB of
shared mem. The only problem I have is that with 1000000 entries
configured as entry cache, slapd uses 11GB out of 16 GB of RAM after the
insert with ldapadd. Which makes it use 7GB for entry cache (and whatever
else).
What's the contents of your DB_CONFIG file? What's the size du -c -h *.bdb
in your database directory? What is your idlcachesize setting? How many
file descriptors do you allocate to slapd?
Since you are using ldapadd to populate the database (rather than slapadd),
the entry cache is getting immediately allocated. As I described in a
previous email writeup I did on performant tuning of slapd, the DB_CONFIG
setting is the most important (to hold the size of your entire DB),
followed by the entry cache size.
The entry cache really only needs to be the size of your active set of
entries, rather than all entries. For example, at a previous position,
even though we had about 500,000 entries in our database, our entry cache
was only 20,000. And it was very performant.
Our entries have (in LDIF of course) an average size of below 200 Bytes.
So taking 6GB out of the 7GB used as size of the entry cache, it would
mean that each entry consumes about 6K of RAM. Is that correct?
If so, is there any documentation on how to configure the slapd for a
larger amount of entries like ours?
How many entries do you have?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration