Hi,

caches where in autosizing mode, this seems not to work in our case (?)

grep nsslapd-cache-autosize /etc/dirsrv/slapd-ldap1/dse.ldif
nsslapd-cache-autosize: 10
nsslapd-cache-autosize-split: 40

Only when we set


nsslapd-cache-autosize: 0

and reduce all cashes by a factor of about 10 and 100 (see below):


@@ -1521,11 +1521,11 @@
 numSubordinates: 4
 nsslapd-suffix: cn=changelog
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/changelog
-nsslapd-dncachememsize: 134217728
+nsslapd-dncachememsize: 13421772
 
 dn: cn=config,cn=ldbm database,cn=plugins,cn=config
 objectClass: top
@@ -1539,7 +1539,7 @@
 nsslapd-mode: 600
 nsslapd-idlistscanlimit: 4000
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db
-nsslapd-dbcachesize: 1342657822
+nsslapd-dbcachesize: 13426578
 nsslapd-db-logdirectory: /var/lib/dirsrv/slapd-ldap1/db
 nsslapd-db-durable-transaction: on
 nsslapd-db-transaction-wait: off
@@ -1586,7 +1586,7 @@
 numSubordinates: 4
 nsslapd-suffix: o=netscaperoot
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/NetscapeRoot
@@ -1600,11 +1600,11 @@
 numSubordinates: 10
 nsslapd-suffix: dc=fhm,dc=edu
 nsslapd-cachesize: -1
-nsslapd-cachememsize: 671088640
+nsslapd-cachememsize: 67108864
 nsslapd-readonly: off
 nsslapd-require-index: off
 nsslapd-directory: /var/lib/dirsrv/slapd-ldap1/db/userRoot
-nsslapd-dncachememsize: 134217728
+nsslapd-dncachememsize: 13421772

the memory consumption keeps stable. The machine has 32 GB memory, so the values prefixed with a minus above should easyly fit.

On 13.11.23 13:22, Thierry Bordaz wrote:

Hi,

389 1.3.11-1-3 is the latest version on that branch and is quite widely installed. So far we are not informed of memory leaks on that release. If cache tuning are reasonable vs available memory and you suspect a leak, I would suggest to use valgrind and the suspected unindexed search.

best regards
thierry

-- 
Harald Strack
Geschäftsführer

ssystems GmbH
Kastanienallee 74
10435 Berlin