Rodrigo Costa wrote:

Howard,

I saw sometimes the DN cache allocating a little more memory since it

sometimes pass a little the boundary, like seen below :

olmBDBEntryCache: 1000 olmBDBDNCache: 1000247 olmBDBIDLCache: 1

The maximum I saw was 1000268 but nothing considerable. In this way now

slapd is keeping memory allocation stable as it is supposed to behave.

The DN cache is hierarchical; it will only free leaf nodes (entries that have no children). So depending on the structure of your tree, it's normal for the Monitor to report more elements in the DN cache than you configured.

The only comment is if dn cache is passed this memory allocated appears to

never be released. The maximum size slapd obtained was :

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10195 ldap 18 0 385m 266m 68m S 0 2.2 20:54.16 slapd

This is more than perfect !

Thanks for all your quick solution of this problem. I believe many users of

openLDAP will see their system more stable with this fix.

Just some last questions. Is there any expectation for a new release, for

example 2.4.15, with this ITS included? Just to use a formal release.

By the tests I was expecting the cachefree as the cache size bringing some

improvements, at least in a full query, since system would "cycle" pointer memory and overwritten all cache at once. What is the purpose of cachefree?

cachefree applies only to the entry cache. The idea is to minimize the number of times it must cycle through the cache trying to free entries. Typically when we configure large servers with caches of 1 million entries or more, we configure this to 1000 or so (0.1% of cache size).