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