Stelios Grigoriadis wrote:

After running some test we observed that slapd is consuming a considerable amount of memory, why is that? We ran one client that retrieved the entire tree (it was pretty small anyway) and 10 other clients that searched for a particular item. Comparing version 2.3.39 with 2.3.32 the footprint increases. From top:

2.3.32: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA COMMAND 6049 root 18 0 221m 4904 2568 S 11.5 0.2 0:33.27 216m 2844 137m slapd

2.3.39: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA COMMAND 13062 ldap 18 0 268m 80m 77m S 14.3 16.2 0:42.27 188m 2892 185m slapd

Is this to be expected? By decreasing the cachesize we got:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP CODE DATA COMMAND 22492 ldap 18 0 255m 80m 77m S 14.5 16.1 0:39.01 175m 2892 172m slapd

which is still pretty big.

The whole ldap tree fits into a 14k large ldif file so the amount of data is notlarge. Is there any way we can influence the memory footprint (eg. by setting som parameter)?

/Stelios

I found out by looking at the code and running som tests that, the constants that have a major impact on the memory footprint are these (are the size of these correct?):

BDB_IDL_UM_SIZE, used in search_stack, using approx. 41 % of the memory SLAP_SLAB_SIZE, used in slap_sl_mem_create, using approx. 5 % of the memory LDAP_PVT_THREAD_STACK_SIZE, used when creating new threads, using approx. 20% of the memory

I couldn't figure out where the rest of the memory usage where, but restricting the max number of threads was the only thing that helped bring the memory size down. By reducing the number of threads to a total of 5 (instead of 14) the memory went down to approx. 130 Mb (which is still a respectable amount).

I've also tried with every possible value of the cache size (didn't affect the size much) and idl cache size.

/Stelios